[mythtv-users] Stutter/pause and pixel debris when the programme moves from one to the next (Live TV)

[Simon Hobson]

Ben Lancaster wrote:

>Now the problem I have is that when the programme changes when 
>watching live TV (and the backend starts writing to a new file), I 
>get a stutter or pause of a second or two, followed by pixel debris 
>for a few more seconds.

I've just upgraded, but I had something very similar on my old box - 
which ran as a Xen guest VM on a single core AMD with one disk for 
everything.

The audio/video breakup would last for 30s to a minute (typically) 
into the next program under certain circumstances - and I did pin it 
own to IO limitations. It manifested itself mostly if I was doing two 
recordings back-to-back and then commflagging. For a single tuner in 
use it could generally just cope, but if I had another recording 
going on, or was watching another recording, then the extra I/O from 
the commflagging firing up (not to mention the DB updates required) 
meant that the first bit of the new recording would be corrupted - by 
skipping back I could confirm that it was in the recording as the 
pauses/breakup would be identical on a second play through.

I see you are running RAID5. In I/O terms that's very similar to a 
single disk (at least for the purposes of this discussion) so whilst 
one process is trying to create a new (large) file, another has just 
closed one (filesystem metadata to update), another is doing lots of 
random I/O (DB updates), and you may have another (commflag) starting 
to read the previous file. And of course, if you've recently deleted 
anything, or the system needs to autoexpire to make room, then you've 
file deletion going on.

That's a lot of random I/O going on and all the limitations of a 
single disk apply to a raid5 array. The disk heads will be doing a 
lot of seeking, and that will drop available throughput very 
dramatically.

I'd be tempted to suggest you look at adding another drive (just 
temporarily) and test the system while recording to that.
Also, look at the output of "top" on the master backend - see how 
much time it spends in state "wio" (waiting on I/O*) while switching 
live recordings. I suspect you'll see it blip for a few seconds.

* This measures (IIRC) how much time the system spends with 
process(es) "ready to run" but blocked waiting for I/O AND with no 
other process(es) that can be run (they are all sleeping or waiting 
for I/O). If this is non-zero, then it's a good indication that your 
I/O can't keep up with everything else.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.