[mythtv] Mythtv Show Verification Script (safe version)

[Nathan Langley]

By the way this script was tested on and is designed for 0.7.  When 8 comes
out if I update, I will update this if needed...


----- Original Message -----
From: "Cedar McKay" <cedarmckay at mac.com>
To: "Development of mythtv" <mythtv-dev at snowman.net>
Sent: Tuesday, January 14, 2003 8:40 PM
Subject: Re: [mythtv] Mythtv Show Verification Script (safe version)


> I should be smacked for suggesting a feature with no clue/intent to
> implement it, but how hard would it be to integrate something loosely
> based on Nathan's script into mythtv itself? The idea is that upon
> startup, or perhaps once a week the script would autorun and alert the
> user if there were any orphaned recordings, and ask the what to do with
> it. I suppose the answer is that when mythtv reaches 1.0 it won't ever
> lose files in the first place.
>
>
> cedar
>
>
>
> On Tuesday, January 14, 2003, at 06:13  PM, Bruce Markey wrote:
>
> > Nathan Langley wrote:
> >> Attached to this email is a non destructive version of the script I
> >> submitted earlier.  This one just prints a report and does not
> >> actually
> >> delete anything.
> >
> > Thanks.
> >
> > I've also seen the opposite case where a row is in the
> > recorded table but there is no file. The current behavior
> > is that the frontend will hang if you try to play it (but
> > this can be fixed) you may want to consider finding these
> > too. Also, did you consider doing once SELECT * and in the
> > beginning and storing the result in a hash? You could
> > sanity check that > 0 rows are returned and it would make
> > it easier the look for both files without entries and
> > entries without files.
> >
> >> I am not imposing it, I am offering it.
> >
> > Of course, no one had to use it but if someone chose to
> > trust your code, they would have been subject to the risk
> > you were willing to take. I tried to quickly think of
> > border cases but the first thought is that the tables do
> > change (mythweb doesn't work this week for example). There
> > is a possibility that in the future the queries could succeed
> > but nothing is matched in verify(). You are right to have
> > a disclaimer but I wouldn't feel comfortable offering
> > something where there is a plausible chance that it may
> > be destructive for others down the line.
> >
> > Overall, your code is careful about pattern matching file
> > names (maybe /\.nuv$/ in place of /nuv/) and checking return
> > status from DBI.
> >
> > --  bjm
> >
> >
> >
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at snowman.net
> > http://www.snowman.net/mailman/listinfo/mythtv-dev
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at snowman.net
> http://www.snowman.net/mailman/listinfo/mythtv-dev