[mythtv-users] Livetv stutter

[Stephen Worthington]

On Wed, 18 Oct 2017 11:45:13 +0000, you wrote:

>Hi, i'm running myth 0.28 on ubuntu 16.04 and am having trouble with pal
>1080i live tv streams stutter. If i pause for just a second the stream then
>plays stutter free, prev recordings play fine too. I've tried adjusting
>decoders & deinterlace, ssd for live recordings & ringbuffer sizes but they
>don't seem to help, it also happens with vdpau on one frontend and vaapi on
>another. When i watch the playback data i see the a/v sync going wild
>between 0 to -1.5, after the pause & resume it then sits pretty much rock
>steady on -0.25. Any other settings to try??
>
>Thanks in advance, i've had many happy years from myth, i just can't seem
>to get this sorted & its more prevalent on a new bigger tv.
>
>Dave

What is normally happening is that mythfrontend has started playing
too soon, and does not have enough data buffered from one or other of
the streams for the channel.  When that stream becomes empty in the
buffers, it has to pause until some more arrives in the buffers.  But
as it starts up again before enough of that stream is in the buffers,
a bit later it runs out again and another pause happens.  So by
manually pausing for a short time, you make mythfrontend wait until
there is enough of that stream buffered, and the problem is resolved.

As far as I can tell, this normally happens only on certain channels,
where there is a wider than normal interleave between the packets for
one stream and another.  So it might happen when there are say 20
video packets between audio packets, and not when there are only 16
video packets between audio packets.  I am not sure if the muxes
transmitting the channels that cause this are actually set up
incorrectly or not, but it could be solved at the transmitter end by
reducing the interleave time.

A solution would be to have mythfrontend pause for a bit longer every
time it pauses, to let more of the problem stream arrive before it
starts playing again.  So after a pause or two the problem would be
solved.  Or it could actually analyse the interleave and calculate the
buffering required, but that might mean that it has to wait a bit
longer to start playing than it otherwise needs to, which means that
live TV would be even further behind "live".