[Common Man]

I call it the stutter of death because once it starts to play a streaming video skipping frames (no audio), it cannot come out of it even when the network conditions improve or the server slowdown stops. One of my machine even starts to heat up while in this mode and shuts down from overheating.

There are many stuttering issues and solutions so let me establish the context to the very specific issue I am talking about so as not to go chasing after the wrong solutions. This is NOT solved by changing buffer parameters.

If you are streaming video content over a network, typically the streaming is fast enough so the video plays without buffering or any other artifacts. If the stream gets slow or temporarily breaks and/or the buffered content gets low, the video in theory should pause with the buffering indication and start again as the buffer is filled. But there seems to be a certain condition under which the video play does not pause for buffering but goes into a "stutter" mode playing intermittent frames (with no audio). Most of the time it does not come out of this mode when the network improves (doesn't seem to do the required buffering to progress) unless you manually pause (at which point it starts to fill up the buffer) and then unpause to get out of that mode. This is a pain.

It has been documented by someone that it appears to be a bug in Kodi in calculating buffering fill and can be improved (if not fully solved) by the partial (proof-of-concept) code change posted there.

http://forum.kodi.tv/showthread.php?tid=249432

Is anyone in the core team aware of this and is there some unsolvable problem that is not fixed by a change like what is suggested in the above thread? I am not technically savvy enough to do my own build or submit a change to Kodi Git repository.

A pause for buffering is much more tolerable than this stutter of death because the pause comes back to normal video after the buffer is filled. It doesn't seem to be capable of coming out of the stutter.

Thanks for any response one way or the other as to this problem.

PS: I am staying out of streaming legal vs illegal content for this issue because the bug doesn't happen based on the legality of the content! It is a "slow or intermittent" network handling issue. I have seen this happen when I stream content from home while on the road through a VPN tunnel. Because the intervening network can have ups and downs, the stuttering is triggered often in such scenarios.

[Scott00007]

I have had this problem for some time as well. There is no way out of it other than stopping the stream and restarting it. Hopefully this can be fixed.

[nickr]

But neither of you has posted a debug log??

[Common Man]

But neither of you has posted a debug log??

I realize that this is a standard answer to most problem reports before anyone looks at it. If there is no log it didn't happen! :-) I understand why.

But did you read the the thread I linked to where a user did a lot more research into this?

There is a problem with getting a log when one needs it because it is intermittent (don't know how to simulate a slow network condition that triggers this), so will have to wait with debugging enabled for the condition to happen. I will post it when it happens again in the future.

I would think there is enough information in that linked thread to point to a potential program logic bug.

But if posting a debug log (whether it is needed or not) is a precursor to anyone even looking at it, so be it. Will be back soon.

[nickr]

I don't think the author of that previous fix ever submitted a pull request.

Where are you streaming from?

[beeswax]

I think the lack of support being thrown at this is probably down to the fact that anyone with more than a few brain cells to rub together knows exactly what sort of streams the users reporting this problem are using. The obtuseness with which requests for debug logs or stream specifics is met with speaks for itself.

If you're going to get anywhere with this, you need to come up with an example of a legitimate use case that exhibits the problem and provide a debug log.

Best of luck to you fully loaded guys.

[Common Man]

I already gave a legitimate use case. Streaming from my home servers via VPN tunnel when on the road. I will be happy to get a log the next time I am traveling. I just got back from a trip where this was encountered.

@beeswax, I think you need to get off the high horse on implications of illegal streaming on anyone who points out this problem. It seems to be a bug in the software logic as posted on the other thread. If Kodi team don't care to fix it just because it may be applicable to those that are streaming illegally, then that is not having enough brain cells in my opinion. Have a crippled system then.

There used to be a time when XBMC developers used to have pride in their work that couldn't stand to see a bug in it. Now there seems to be such an antipathy towards their own users ("You must be doing something illegal") that they seem to not care whether the bug is fixed or not. Obviously, that is your prerogative but that is the beginning of the end of Kodi in my opinion. I can live without it or commercial entities who steal Kodi will benefit instead.

@nickr, mentioned in that thread is the fact that the guy who posted that fix doesn't know how to work with git (nor do I). Also he mentioned that his solution solves the problem for the most part but not entirely, but the solution identifies the problem for anyone that is familiar with that part of the code to do a more robust fix. To me, not familiar with the code, it seems to be a problem in estimating the buffer size/content size which is a program logic bug.

Seems like a lot of excuses and rationalizations to not fix a bug in Kodi even when a proof-of-concept code change is provided that points out what the bug is. Obviously, that is the Kodi team prerogative because it is a volunteer open-source program. I am just sad it has come to this kind of paranoia and mud-slinging with "prove that you are innocent" comments. Sheesh.

Good luck with the future of Kodi. I don't see much there.

[kimkl]

Bee i don't like being put in that Group either, i do not watch illegal streams as you suggest, i have had problem with live stream "legal" since 15.2
exactly 14 days before 16 was released.

At the moment i have fixed the Video "stutter" but got Audio "stutter" instead
exactly the same problem as i had with my Video i now have with Audio

And i have read a lot on different fixes its an old problem some claim its leftover code because kodi never "cleaned" the code but just kept adding, i think that is a load of what a Bull will do after lunch

More likely in my case, i think an MS update made FUBAR out of my system, back when i used 15.2 because its the same problem on my 3 PC with different hardware but same os

[nickr]

@beeswax I agree, but there are also legit uses such as posted by @Commonman right after you.

@CommonMan, may I humbly suggest you try emby or plex as your home server which will enable transcoding to a lower bitrate for "on the road" use.

There are plenty of git howtos out there, but that may not be for everyone. I'll see if I can draw that code to the attention of devs, or perhaps learn more about git myself!

[Common Man]

@nickr, thanks for looking into this and getting dev attention if possible.

The thing is my home server keeps both SD and HD versions of media (in other words transcoded once rather than on the fly) because the uplink speed for my service is not that great. The SD version is what gets accessed on the road and it is already a low bit rate. So I am not sure servers that can transcode on the fly will do any better with this issue. Of course, the better solution is both client and server acting together using some kind of adaptive bit rate streaming protocol but I don't think this is where Kodi will ever go.

The problem in this case seems to be not so much the bit rate but rather its delivery isn't constant because of network characteristics. This is what the buffering is supposed to help with (up to a certain limit), but this bug seems to be tripped on handling exactly where that buffering should have helped (exactly under what conditions I don't know since one isn't monitoring the network performance all that time). It gets into that stuttering state that it never comes out of EVEN WHEN the network improves to make the bit rate a non-issue (why a manual pause and unpause works). Going into this state and not coming out of it is what needs to be fixed as a bug because this can potentially happen at any bit rate (albeit more often at higher bit rates).

[beeswax]

@beeswax, I think you need to get off the high horse on implications of illegal streaming on anyone who points out this problem.

Bee i don't like being put in that Group either, i do not watch illegal streams as you suggest

If you read my whole post, I do finish suggesting to come up with a legitimate use case and accompanying debug log so I am not and was not suggesting that all users with this issue are streaming illegal content.

The main guy in the other thread you point to is clearly dodging questions about what he's streaming and also unable to produce a debug log so when you open an additional thread and still don't provide any of that, you can't expect to get very far.

Unfortunately, you've posted at a time when sellers and users of illicit streaming solutions are a huge bone of contention so while I realise my first response might have been a little judgemental, the guy in that other thread hasn't done anyone any favours by so clearly avoiding questions about his source. In his case it's very obvious why he won't say what his streaming source is.

Hopefully a developer is willing to look past that and investigate the bug on its merits but I also hope you see why people might just stop reading when the question about whether this affects real users or not keeps coming up and keeps going unanswered.

[kimkl]

@Bee
Point taken, i was a bit hasty just tired of reading if you have problems with Video and do not provide a debug.log you must be doing something illegal.
So i wrote to hasty without choosing my words careful.
I apologize for accusing you of putting all the rotten eggs in one basket.

I was a bit frustrated about fixing my Video "stutter" and was able to watch 30 mins before the problem returned just with Audio instead, but as i Wrote i think it was an MS update to the sql server that made a mess of my live feeds, but since i hate loosing a fight i will keep on trying to fix it.

And i will succeed, i have the know how, just get distracted to easy but i will monitor this thread and see if nick finds a fix for commonman, i can use with my problem.

I hope i did not go to far of topic, but i needed to explain my self

[Common Man]

@beeswax, not going to belabor this point but I humbly suggest that you read other people's posts completely (see PS in my original post) as you suggest others do of yours. Otherwise, you just look like a troll that is thread-crapping without actually helping.

Someone who has gone into the trouble of looking at the code and testing out a patch and publishing a patch for the code has been much more helpful than anyone posting a debug log. Perhaps you are not technical enough to understand this (in which case sitting on your hands will be more useful). After all, what developers need to do with a debug log is to isolate the code that is causing this and then try to figure out a fix. The guy has already done that for them, so they should be thankful for that effort not call him out unnecessarily like you did because you have a brainless "process" to follow.

I understand the sensitivity to illegal streaming but that does not excuse this kind of dumb shotgun approach against people trying to help or pointing out the problems.

Let us see if the developers do anything about it given that there is a legitimate case and there is a proposed solution that is far more helpful than a debug log or knowing what the source of the streaming is (this bug has nothing to do with that).

If they don't then all these accusations have simply been rationalizations and excuses to hate on people for nothing. Suggest being more constructive and respectful of people in the future like @nickr.

[popcornmix]

Let us see if the developers do anything about it given that there is a legitimate case and there is a proposed solution that is far more helpful than a debug log or knowing what the source of the streaming is (this bug has nothing to do with that).

Realistically I don't see any developer doing anything based on the information presented.
Without a debug log or a description of how to reproduce, then it won't be fixed.

Again, the patch posted on the other thread isn't going to be picked up.
From the description it sounded like it wasn't quite right, although it was helping.
That is not something a developer is going to be able to pick up without being able to test.

If you want this fixed then find a legal addon that shows the problem. Post a debug log.

I suspect you need the network speed to be slightly inadequate to provoke the issue,
so you may be able to simulate that using youtube, or a similar legal add-on and restricting network bandwidth
(perhaps using wifi that's not quite good enough, or by downloading a large file from another PC in the house).

[Ned Scott]

and try a nightly build (wiki). A ton of that video stuff has been touched by and/or completely replaced by new code, so all of the old reports about these kinds of things are outdated.