[mythtv-users] Intel i965 video buffers errors on frontend

[Mark Perkins]

> -----Original Message-----
> From: mythtv-users [mailto:mythtv-users-bounces at mythtv.org] On Behalf
> Of evade.
> Sent: Thursday, 20 July 2017 8:42 PM
> To: mythtv-users at mythtv.org
> Subject: Re: [mythtv-users] Intel i965 video buffers errors on frontend
> 
> On 20/07/17 13:39, Mark Perkins wrote:
> > On 20/07/17 12:13, evade. wrote:
> >>>> Does anybody please have any advice on troubleshooting these
> >>>> buffers specifically when watching live(*) TV?
> >>>>
> >>>> Thanks,
> >>>> evade.
> 
> <snip>
> 
> > Please correct me if I am wrong, but if I understand the thread
> > history correctly the video issue was solved by increasing the GPU
> > allocated memory from 128MiB to 256MiB. But there is still occasional
> audio glitching?
> >
> > If this is correct, I would be interested in seeing a full inclusive
> > log file from startup of mythfrontend with -v playback, through entry
> > into LiveTV, maybe 30sec of viewing, a channel change, another 30sec
> > of viewing, then exit.
> >
> 
> Thanks again Mark,
> 
> I've got 3 x 30 seconds of channel viewing with changes in between.  I
chose
> the HD channels to try to solve this in a worst-case scenario.
> 
> Please see:
> https://paste.fedoraproject.org/paste/cMNYLi2jJghzkr93z8BswQ
> 
> 
> I notice there are some decoding errors, a few "discontinuous" messages in
> addition to buffer errors, so if there's any way I can resolve some of
these
> problems watching live TV will be even better!
> 
> evade.
> 
> _______________________________________________
To be honest everything there looked more-or-less normal to me (compared to
what I see in my logs). The decoding errors were all at the channel change
boundaries which (as I understand it (I have been wrong before)) are not
unexpected as the first stream is essentially cut off and the second stream
is synced, keyframe found etc. The first channel change took 2.73sec (chan
1050 to 1020) and the second channel change took 1.17sec (chan 1020 to 1030)
which seems reasonable to me (full disclosure - I don't use a lot of LiveTV
so my view of reasonable may be distorted).

CPU usage was nice and low across all cores (mostly sub 10%). VAAPI looked
to be working.

In particular I didn't see any messages like "video is x frames behind
audio, dropping frame" which can result in a video glitch. I also didn't see
any audio buffer underrun messages which I think caused you audio glitches
previously. Did you see or hear glitches (audio or video) during this
capture?

In my LiveTV viewing I get some (although perhaps not as many) of the
"waiting for video buffers" informational messages but do not seem to see
any ill effects / noticeable effects from them although my main FE does have
nvidia / vdpau graphics.

I also get some of the "Player(0): Waited Xms for video buffers" messages
which might be causing me some very slight stutters in the first few seconds
of a channel change. My highest figure is around 600ms and is more commonly
around 100ms - 200ms whereas yours does get to 1100ms. But these messages
don't seem to persist for me more than a few seconds and didn't seem to
persist for you either.

My understanding of the discontinuous messages is that it is associated with
the implementation of the LiveTV chain which allows you to skip back /
forward over LiveTV channel changes. For the specifics of how it works would
probably need input from the code author JYA but my understanding is that it
is essentially informational messages only and should not be an indication
of a problem or a glitch.

If you are still seeing video / audio glitches we might need to try and
match them more precisely to where they are occurring in the log file and /
or enable additional logging. Or possibly there might be something in the
backend log?