[mythtvnz] Pixellation Every ~ 20 minutes

[Nick Rout]

On Fri, Oct 5, 2012 at 2:56 PM, Stephen Worthington
<stephen_agent at jsw.gen.nz> wrote:
> 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 it is the high disk usage and long time taken deleting a large
file (mythtv recordings are large files in this context, and the
system could suffer from the delays.

Come to think of it look for a file delete (auto expiry?) happening at
the same time as the glitch - maybe your drive is real full and at
about 20 mins into a recording myth decides to delete an old recording
and disk usage goes thru the roof?

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

I use XFS, it's one of the recommended ones.

>
> 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.
>
> _______________________________________________
> mythtvnz mailing list
> mythtvnz at lists.linuxnut.co.nz
> http://lists.ourshack.com/mailman/listinfo/mythtvnz
> Archives http://www.gossamer-threads.com/lists/mythtv/mythtvnz/