[mythtv-users] Playback problem -- random short pauses

[Christopher Kerr]

On Tue, May 31, 2011 at 10:40 PM, Andre <mythtv-list at dinkum.org.uk> wrote:
>
> On 23 May 2011, at 20:51, Michael T. Dean wrote:
>
>> On 05/23/2011 03:20 PM, Steven Adeff wrote:
>>> On Mon, May 23, 2011 at 3:06 PM, Daniel Kristjansson wrote:
>>>> Removing the fsync() call can lead to pauses, in the unlikely event that
>>>> it is being called on a Linux system. The fdatasync() and range syncs
>>>> are mostly no-ops since we're appending to a file, so removing those
>>>> will have no effect. The main reason the fsync() was added was to
>>>> prevent pauses on when the disk I/O scheduler decided to finally write
>>>> hundreds of megabytes of data to disk in one long write and consequently
>>>> starve all readers and so stop video playback. This was accidentally
>>>> subverted when the fdatasync() code was added. But that change happened
>>>> over five years ago so if you are seeing a regression with 0.24, fsync()
>>>> changes are not to blame.
>>> That's what I figured.
>>>
>>> It sounds like, from what Mike says, the issue has to do with VDPAU
>>> decoding and the interaction with ffmpeg (Mike, am I understanding
>>> that correctly?).
>>
>> Yes.  (That's right for issue #2.)
>>
>>>  So I don't think chasing i/o is the way to attack
>>> this. It sounds like Mike and the other dev's looking at the issue
>>> have an understanding of what's causing VDPAU to do this. Hopefully a
>>> solution can be found that still lets users take advantage of using
>>> VDPAU with ATOM-like systems.
>>
>> Though this not so much--the other devs are looking into this, not me.
>> I'm only relaying what info I've learned from them (and from my own
>> testing that I've done, in part, for them).  :)
>
> Any tests that we can do to expand the data set? I'm assuming that not every hardware configuration exhibits these problems.
>
> I'm primarily concerned with problem #2, the others I can tolerate more easily and they can be mostly avoided (I don't watch live TV), for me #2 is the nasty one. I'm almost at the stage of burning BD-RE's to be able to watch important stuff properly. :-(

Issue #2 is exhibited on every machine I have using VDPAU decoding  -
2 Ion's and an 8500GT. I understand from Michael T. Dean's post that
it affects most (all?) machines using VDPAU decoding.

In my case, the pauses are very brief, but my TV loses it's grasp on
the HDMI audio stream and takes a further 5 seconds to pick it up
again, resulting in annoying missed punchlines - sure, two button taps
and I'm back 10 seconds and it's all fine, but it's starting to bug me
a bit.

- Chris