[mythtvnz] Pixellation Every ~ 20 minutes

[Stephen Worthington]

On Fri, 5 Oct 2012 12:15:07 +1300, you wrote:

>ThreadedFileWriter.cpp:499 (DiskLoop) -
>TFW(/mnt/media/mythtv/4301_20120926082000.mpg:56): write(61100) cnt 15
>total 818552 -- took a long time, 1663 ms

I would say this is the likely culprit - 1.6 seconds is way too long
for a disk write operation, so it is likely some data was lost at this
point.  But just what caused it does not seem to be shown in the log.
You seem to have only been doing the one recording at the time, so
there should not have been any issues with too much disk access.

However, your recordings drive is ext4, which is not actually
recommended for a recording drive.  It is so long now since I set up
my system that I can not remember why ext partitions are not
recommended, but I do know that ext3 and ext4 were not.  I think you
should try using JFS, which is what I use and works well.  IIRC, the
other recommended recording partition type was XFS, but I have never
tried that.  You will need to install the jfsutils package to use JFS,
and of course you will need another drive to copy the existing
recordings to so that you can reformat.

When I was getting this sort of problem, way back (caused by low
signal levels), I discovered that if I wanted to see more at the point
of damage, if I waited until a few seconds had passed after the
pixellation started, then went back 5 seconds using my back arrow
button, the pixellation usually cleared.  I expect the reason for this
is how the recordings work - every so often, a key frame is written to
the recording file that contains full information for displaying a
frame of video, then between that key frame and the next key frame,
only the changed data gets written for each frame.  So when damage
occurs, there will be missing data until the next key frame, and
calculation of the next frame from the existing bad data in the
current frame makes the pixellation get progressively worse until the
next key frame.  But when you skip backwards, I think there must be
special code to reconstruct a key frame so that a valid frame can be
displayed, and that reconstruction manages to recover from the bad
data somehow - maybe it works backwards from the next key frame, if
that is possible.