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

[Andre]

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. :-(

Andre