(2014-11-08, 20:40)popcornmix Wrote: (2014-11-08, 06:34)gendo Wrote: @popcornmix here is a longer sample. here i waited till audio and video actually resume even though they stutter/seem slow
https://dl.dropboxusercontent.com/u/5174...ample3.rar
EDIT: Hmm actually i played these files in kodi and they work fine as in glitch and resume immediately! could there be something different in the path used by livetv? as during live playback this sample frooze for circa a minute..
All three of your longer samples seem to have correct timestamps and play without pausing or out-of-sync issues for me.
S2.rar is the only file that has behaved badly for me (but based on the information available in the file, I don't know how it can be fixed).
There are many differences between watching live and playing the same file from a recording.
One obvious one is that a live source can only be read from in real time. A file can be read much quicker.
E.g. if the player's concept of time is ten seconds ahead of the demuxer, a live stream will pause for ten seconds. A file will be able to catch up much more quickly.
There are other differences in behavior between live and file playback (e.g. in decisions made about buffering), and there's no guarantee that the PVR backend writes
the same data to the file when recording as it does when playing live.
Thanks for you answer. I tried a different backend box with different software and get exactly the same issue. Also i am playing live streams,no timeshift etc.
I made a further experiment, I placed two kodi + 1 vlc next to each other playing the same livetv stream Kodi 1 has the openelec build of the 18th (with commit) and kodi 2 is last nights build. I glitch the live stream and kodi 1 recovers within a couple of seconds, vlc does the same whilst kodi 2 remains stuck for over a minute.
Maybe you can add an optional parameter to add the commit of the 18th, or even better just use it for livetv since there should not be the timestamp issue found on the disc you were trying to address with the original fix, and anyway cannot jump on a live stream..
I also notice that there is a slight difference between raspberry pi and windows on the windows version it behaves exactly the same, but displays buffering 0% whilst the video is jammed on pi the video is jammed but buffering does not show on screen. In reality since this is a live stream do we need to resync (i.e. it is not like we can go back or forward in time like in a file)
I also downloaded a glitching stream straight from backend to to disk via chrome browser
https://dl.dropboxusercontent.com/u/5174...-0-0-.mpeg as per your tests, this file works perfectly with and without the commit what i think is happening is that being a file, kodi can jump on resync, while for a live stream (not a stream like youtube where one can seek) after a glitch, kodi make a request to seek another portion of stream and that is not available and so gets stuck at buffering 0%