United Kingdom
Hi
Ive created a patch that alleviates a problem with discontinuity errors in live/recorded TV streaming. The bug is generally triggered on HD channels/recordings (high bitrate) but can happen on SD with a lower probability . See this thread: https://forum.team-mediaportal.com/...ng-issue-seek-beyond-end-infinite-loop-79008/
The bug causes tsreader on connected clients to give discontinuity errors and a corrupted picture. The bug is triggered when a call to Read() on the ts buffer file returns less data than "m_lTSBufferItemSize". The resulting seeks and refreshes performed on the file seem to cause disk IOs to spike and the 100ms Sleep() seems to combine to cause the discontinuity errors. The combination also causes the process to keep repeating meaning the picture on clients doesnt recover until the user intervenes (eg skip stepping/changing channel). The bug then triggers again after a short period.
The patch changes the methodology to append to the buffer on any subsequent reads (when not initially filled). This is instead of seeking and re-reading the entire block. This is generally accepted as the standard way to handle IO operations. The sleep has also been reduced to 10ms as a 100ms delay seems to aggravate the problem. I dont think this completely fixes the problem (as I believe a design change would be needed), but it significantly reduces the probability of it triggering and continually repeating.
Testing: HD channels always triggered the bug within 15 minutes on my system before the patch. So far with the patch the bug has not triggered with over 6 hours of continuous playback.
Thanks I hope you will consider this patch for inclusion,
Ive created a patch that alleviates a problem with discontinuity errors in live/recorded TV streaming. The bug is generally triggered on HD channels/recordings (high bitrate) but can happen on SD with a lower probability . See this thread: https://forum.team-mediaportal.com/...ng-issue-seek-beyond-end-infinite-loop-79008/
The bug causes tsreader on connected clients to give discontinuity errors and a corrupted picture. The bug is triggered when a call to Read() on the ts buffer file returns less data than "m_lTSBufferItemSize". The resulting seeks and refreshes performed on the file seem to cause disk IOs to spike and the 100ms Sleep() seems to combine to cause the discontinuity errors. The combination also causes the process to keep repeating meaning the picture on clients doesnt recover until the user intervenes (eg skip stepping/changing channel). The bug then triggers again after a short period.
The patch changes the methodology to append to the buffer on any subsequent reads (when not initially filled). This is instead of seeking and re-reading the entire block. This is generally accepted as the standard way to handle IO operations. The sleep has also been reduced to 10ms as a 100ms delay seems to aggravate the problem. I dont think this completely fixes the problem (as I believe a design change would be needed), but it significantly reduces the probability of it triggering and continually repeating.
Testing: HD channels always triggered the bug within 15 minutes on my system before the patch. So far with the patch the bug has not triggered with over 6 hours of continuous playback.
Thanks I hope you will consider this patch for inclusion,
. More problematic when it comes to recordings: the bug crashes 90% of recordings! 
