[mythtv-users] Stutter playback 720 60fps

[Stephen Worthington]

On Mon, 7 Nov 2016 20:22:07 -0800, you wrote:

>On Mon, Nov 7, 2016 at 8:15 PM, Kevin Johnson <iitywygms at gmail.com> wrote:
>
>> Hi All:
>>
>> Still chasing bugs.
>>
>> Recently upgraded from 14.04 to 16.04
>> Myth went from .27 to .28
>>
>> Im running the latest from the mythbuntu repos.
>>
>> Sometimes, but not always, when I start live tv the video will stagger.
>> The audio is fine.
>> If I pause everything is fine afterwards.  This only happens on 720 p
>> channels from what I have seen.
>>
>> This is what I get in the frontend log.
>>
>> Nov  7 20:08:14 g430 mythfrontend.real: mythfrontend[11510]: I CoreContext
>> jitterometer.cpp:120 (RecordEndTime) Player(1): FPS:   58.98 Mean: 16955
>> Std.Dev: 16741 CPUs: 6% 31% 8% 2%
>>
>> Once I hit pause the above message stops repeating.
>>
>> Anyone else see this?  Suggestions for a fix?
>>
>> Thanks.
>>
>
>Please disregard the above message from logs.  I had the playback info
>screen up and that was kicking out that message.
>
>So I really dont see anything in the logs.
>
>What the playback info screen showed is A/V sync:-3.5
>Until I hit pause then play.  Then it goes to less that 1

It is likely that this is just that the playback is starting too early
and there is not enough data in the buffers for either the audio or
the video stream that is being played.  So mythfrontend has to wait
for more data to arrive for the stream that has run out of data in its
buffers.  Different broadcasters use different offsets between the
start of audio and the start of video in their transmissions, and also
the interleaving size - how much audio or video is transmitted at once
before switching to transmitting the other stream.  The MythTV
developers have adjusted how mythfrontend starts to delay the start of
playing until there is supposed to be enough of both streams in the
buffers that neither will run out before more data arrives from the
programme being received.  But they can only work from the data they
have about what settings the broadcasters are using, and they seem to
have got it wrong for your part of the world.  Or more likely, your
broadcasters have got it wrong.  The solution is simple, as you have
discovered: just pause the playback for a moment.  That lets
mythbackend buffer more of the data, so mythfrontend will not run out
of data again.  The devs could adjust the standard setting for how
long MythTV waits to let the buffers build up before starting
playback, but increasing that number means that in places where a
bigger number is not needed, there is more delay between the playback
of live TV and real time.  There is already a second or two of delay.

The reason that it is happening to you now when it did not on 0.27 is
likely that the devs have changed the startup delay to be a little
smaller, for some reason.  But it could be coincidental - maybe your
broadcasters have just recently typoed one of the settings they use
for 720p broadcasts.  Or upgraded their broadcast equipment to
something new that uses different settings.  Or maybe they have added
extra audio streams (for example, 5.1 audio as well as stereo audio).
Adding an extra stream means that there is more data to be received
between arrivals of packets of data for the other streams, so it
delays other streams a little.

I used to see this problem when I first started using MythTV with
DVB-T instead of analogue PAL TV transmissions, but it went away after
the devs changed the startup delay, and has not been back since.  So
the setting used seems fine for DVB-T and DVB-S/S2 transmissions here
in New Zealand.