[mythtv-users] Stutter playback 720 60fps

Kevin Johnson iitywygms at gmail.com
Wed Nov 9 16:34:41 UTC 2016


On Tue, Nov 8, 2016 at 7:17 AM, Kevin Johnson <iitywygms at gmail.com> wrote:

>
>
> On Mon, Nov 7, 2016 at 10:39 PM, Stephen Worthington <
> stephen_agent at jsw.gen.nz> wrote:
>
>> 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.
>>
>
> Thank you for the info.
> It must be a change with mythtv because it happens on multiple frontends.
> I do not see this if using Kodi.
>
> It would be nice, (says the guy who know nothing about coding) if this
> variable could be adjusted.
> I tried adjusting the ringbuffer on the backend, but that made no
> difference as I think it is not really used anymore?
>
> Sometimes it will clear itself up after 5 or 10 seconds.  Sometimes it
> never stops.
> Pausing the playback works, but that is not great when channel surfing.
>
> I tried the extra audiobuffer and that did not make a difference.
>
> Any other suggestions?
> Can I delay the playback startup?
>


Seems like I may be the only one with this issue.

Is there a way to test the setup/configuration of my backend?
I dont think this is hardware as Kodi live tv works fine, but if no one
else is seeing this, then I would like to explore other options.


>
>
>
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20161109/6219e61f/attachment.html>


More information about the mythtv-users mailing list