[mythtv-users] Recent "pixelation" or "glitches" in recordings (HDHR related?)

[Thomas Mashos]

On Wed, Apr 24, 2013 at 3:04 PM, Mike Perkins
<mikep at randomtraveller.org.uk>wrote:

> On 24/04/13 20:34, Thomas Mashos wrote:
>
>>
>> Why should we do ANY check? I think it's reasonable to expect that
>>
>> A) Users shouldn't be touching recording files outside of MythTV
>>
>> B) Recording drives are relatively static in their location.
>>
>>  Because 'bad stuff' happens. A drive can die. Chunks of a file can
> vanish due to bit rot. A *single bit* on a sector can die, meaning the
> whole file is unreadable (depending on which bit, of course). The drive in
> question might be on a slave tuner which is powered off. Users might not
> touch the files outside of mythtv but other software might when it fails.
>
> Users aren't the only reason files can go missing.
>
> --
>
> Mike Perkins
>
>
> ______________________________**_________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/**listinfo/mythtv-users<http://www.mythtv.org/mailman/listinfo/mythtv-users>
>


None of those reasons explain why we need a complete scan when entering
watch recordings. The only time such a scan would ever make sense is either
A) If mythbackend had the ability to reschedule known bad recordings
(AFAIK, it does not), or B) mythbackend had the ability to send an early
warning to the frontend/user (marking a recording with an X that a user
won't see unless they go into that particular show group doesn't count).
Displaying an unavailable message when attempting to access the recording
seems sufficient.


>Because 'bad stuff' happens.

>A drive can die.
Meh. Have the backend check when it's trying to write to or read from a
file on that drive. IMO It makes more sense to check the drive once than to
check every recording on the drive.

>Chunks of a file can vanish due to bit rot. A *single bit* on a sector can
die, meaning the whole file is unreadable (depending on which bit, of
course).
worthless. When going into the frontend it isn't doing a complete scan of
every file (would take way too long on multi-terabyte backends). It's
probably just checking if each file exists. Further, even if it was doing a
scan and could identify files that existed but were bad, it doesn't notify
the user nor attempt to schedule a rebroadcast of it.

>The drive in question might be on a slave tuner which is powered off.
Almost worthless. The backend knows the slave backend isn't available, so
should mark the recording as not available without needing to scan for it.
This is slightly more complicated as you can have shared storage between
backends, but this shouldn't really be an issue as 95+% of people use a
single combined Backend/Frontend.

>Users might not touch the files outside of mythtv but other software might
when it fails.
I've never seen a single case where any of the MythTV devs were OK with any
third party application touching the recordings directly, so why is it up
to mythtv to verify that some third party app didn't screw with the
recordings? If a user sets up something that screws with mythtv recordings,
I think it is perfectly reasonable that mythtv would just throw an error
when attempting to playback that recording.


Thanks,

Thomas Mashos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130424/cd903bdd/attachment.html>