[mythtvnz] Pixellation Every ~ 20 minutes

Curtis Walker sultanoswing at gmail.com
Fri Oct 5 10:32:33 BST 2012


On 5 October 2012 22:10, Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:
> 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.
>
> _______________________________________________
> 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

My skip back is set to 15 seconds - no dice! Will do a bit more
research, wait for any further suggestions (including a few more log
files from those who sound like their similarly afflicted), and
consider either XFS or JFS (not sure which yet).



More information about the mythtvnz mailing list