[mythtvnz] Pixellation Every ~ 20 minutes

[Stephen Worthington]

On Fri, 5 Oct 2012 21:47:57 +1300, you wrote:


>I did "ext"ensive reading around which FS to use prior to setting up
>my current myth install, and the general consensus was that yes, ext3
>had trouble due to slow large file deletes (hence the option to adjust
>that in fronend setup), but that this wasn't a problem with ext4.
>(ref: http://mythtv.livejournal.com/9740.html).
>
>Happy to give it a go if nothing else turns up as a possibility, since
>it's not a major job to move stuff and format to XFS or JFS. I assume
>the database wouldn't break if I set the paths to be the same.

Correct.  Recording files can be put on any of the paths in the
storage group and moved around between them at will - MythTV will look
for a file in all those paths before deciding it can not find it.

>Drive has lots of free space - 470GB out of 1TB, with a minimum set of
>100GB before deletion is forced to occur - so it shouldn't be a space
>issue.
>
>And sadly, skipping back doesn't resolve the pixellation problem - it
>seems to be part of the recording. As mentioned, the exact same mess
>occurs whether watching on my desktop or laptop.

Skipping back only works if you do not skip back into (or past) the
area of corrupt data.  It helps because there is usually an area of
good data in the file between the corruption and the next key frame,
which can be several seconds away.  But when just playing the file
without skipping, data for one frame is calculated from the data of
the previous frame, and if the previous frame was corrupt, the newly
calculated frame is usually even more corrupt.  So skipping back into
good data gets MythTV to recalculate the data to display that frame
from good data - probably by starting at the next key frame and
calculating backwards to the frame it is skipping to.  If all the data
between the next key frame and the one you are skipping to is good,
then it can calculate a good frame to display and then play from
there.  So for a skip back of 5 seconds (which is what I use), you
need to let it play on for 5 seconds plus whatever time the actual
corrupt data lasted for, then do a skip back.

>Finally, I *think* this problem only occurred since 0.25 - although
>there have been lots of other software updates (graphics driver,
>Hauppage drivers, kernel etc) over the last few months I've been
>having this issue. I used ext3 and ext4 previously without this issue.