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

[evade.]

On 21/07/17 00:40, Mark Perkins wrote:
> 
> 
>> -----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?


Thanks Mark and Mike!

It's very helpful to know that what I'm seeing is fairly normal.

Subjectively playback seems quite good now.  I didn't notice any audio 
glitches this time, but none of the content was as demanding high as 
that 8Mb/s 1080i Tour de France coverage I came across when testing earlier.

I only had the 'playback' debug option turned on to reduce log size.  I 
thought the other errors you were looking for came from different debug 
options?

I can check the backend logs too.  I suspect like your other discussion 
most of the time if I rewind the audio glitch or visual stutter wouldn't 
occur - this is all due to trying to "channel surf".

Now things are looking solid and I have a coaxial antenna cable splitter 
I'll set up all my recording schedules and watch some on playback as a test.

He, do you know if the CPU measure is for mythtv's use of the CPU or 
just system CPU usage?  If the latter is true, my results will be 
tainted by the backend also being on the same system and two small 
(currently idle placeholder) VMs.

evade.