<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 24, 2013 at 3:04 PM, Mike Perkins <span dir="ltr"><<a href="mailto:mikep@randomtraveller.org.uk" target="_blank">mikep@randomtraveller.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 24/04/13 20:34, Thomas Mashos wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Why should we do ANY check? I think it's reasonable to expect that<br>
<br>
A) Users shouldn't be touching recording files outside of MythTV<br>
<br>
B) Recording drives are relatively static in their location.<br>
<br>
</blockquote></div>
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.<br>
<br>
Users aren't the only reason files can go missing.<span class=""><font color="#888888"><br>
<br>
-- <br>
<br>
Mike Perkins</font></span><div class=""><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
<a href="http://www.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://www.mythtv.org/mailman/<u></u>listinfo/mythtv-users</a><br>
</div></div></blockquote></div><br><br>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.<br><br><br>>Because 'bad stuff' happens. <br><br>>A drive can die. <br>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.<br><br>>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). <br>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. <br><br>>The drive in question might be on a slave tuner which is powered off. <br>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.<br><br>>Users might not touch the files outside of mythtv but other software might when it fails.<br>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.<br><br><br clear="all"><div>Thanks,<br><br>Thomas Mashos</div><br></div></div>