[mythtvnz] Pixellation Every ~ 20 minutes

[Curtis Walker]

On 5 October 2012 19:18, Nick Rout <nick.rout at gmail.com> wrote:
>
> 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/
>
> _______________________________________________
> 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/

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.

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.

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.