[mythtv-users] everyday i have to make sure myth worked the day before

[Michael T. Dean]

On 04/03/2011 09:27 AM, Brian J. Murrell wrote:
> On 11-04-03 08:57 AM, Michael T. Dean wrote:
>> Please make sure you add the script you're using to
>> http://www.mythtv.org/wiki/Category:MythTV_System_Event_Scripts so
>> others can try it (and improve it).
> There is no script because there is no (failed to record) Event (the
> last time I looked, anyway) to trigger it.

Oh, I assumed you had a script triggering on Recording started, then 
watching to see if <insert criteria that indicates a failure on your 
system> occurs, then using the Python bindings to interact with the 
backend to do whatever you feel is appropriate--i.e. (force) delete and 
allow re-record or just allow re-record (and if allowing re-record, to 
do so at the appropriate time--either during the current showing or 
after it completes) or ...

Since, generally, the only time MythTV does the wrong thing when a 
recording fails is when MythTV doesn't know that the recording failed, a 
Recording failed event probably wouldn't help, anyway.  :)

And, it's easy enough to use the Python bindings to detect when a 
recording is starting after the scheduled start time, and you could 
attempt to detect when you get a Recording started event but never 
receive the matching Recording finished event.  I'd think there are 
several options available, even with the current list of MythTV System 
Events ( http://www.mythtv.org/wiki/MythTV_System_Events ).

>> Note that it's only recorded /iff/ it does not appear again in the
>> current listings.  So, if you start the master backend host while the
>> show is in progress /and/ the show appears as a re-run in current
>> listings, MythTV will not record the partial showing, but will wait for
>> the future (complete) showing.
> Ahhh.  Very nice.  Once again the scheduler is smarter than I give it
> credit for.  That only works though if it's in the next two weeks worth
> of listings.  I still think it would be useful to (perhaps optionally)
> not add a partial recording to the recorded table, or add it and mark it
> as "should re-record" or something so that if it does get partially
> recorded and is shown again 4 weeks later it gets re-recorded and
> replaces the existing partial recording.

We'll have some more data available with a change to the schema that's 
in the works (but that probably won't be complete until at least 
0.26.).  That would make it easier to do what you ask.

>> Which you can do by selecting the recording, MENU, Recording
>> Options|Allow this episode to re-record (or something to that effect...
> Sure, as long as I continue to check things daily and take these
> remedial actions.  I'm not sure why all of that can't be automatic though
>> Then, if it re-airs, it will
>> re-record, regardless of the fact that you have a partial recording in
>> current recordings.
> So it's almost there.  Just needs that requirement for manual
> intervention taken out.

And then we need to finish the code to read minds.  :)

That said, it wouldn't be difficult to create a power recording rule 
that checks to see if you have any "second-half" recordings (i.e. 
recordings that start at some time after the program start time) and, if 
so, to re-record them.  Then, you would just disable duplicate matching 
on that one rule (and can even set the priority independently--therefore 
allowing you to decide how important the re-records are).  You can do 
the rule regardless of title (for a generic/catch-all case) with a 
low(er-than-default) priority, but then you can also create a separate 
Fringe-only re-record partials rule so that you can set the priority on 
that (very important) one to the same priority as your Fringe recording 
rule.

I have power rules for similar stuff.  One re-records episodes of Nova 
in HDTV if an SDTV recording exists in current recordings (therefore, 
ignoring duplicate matching).  I have another one that re-records any 
standard-definition recording (regardless of title) that exists in 
current recordings and is in the Movies recording group if it re-airs in 
HDTV.

Even though I only get partial recordings when power goes out during a 
recording (so, maybe once per year--yeah, Fate, I know I just tempted 
you...), I may just have to make one that re-records partial recordings, 
as described.  If no one gets around to it before me, I'll post the 
SQL.  (Regardless of who gets around to it first, I'll likely add it as 
an example in the custom/power recording rule editor.)  With this 
approach--where users specify exactly what should happen, and at what 
priority, etc.--we don't need the mind-reading code.  Unfortunately, 
users will find it hard to find the capability (and even when they do, 
they will likely find it hard to understand the flexibility of the 
capability).

In addition, it might be possible to identify recordings that start on 
time, but don't finish recording (in case mythbackend is shut down 
during a recording, but gets restarted after the recording finishes).  
I'll have to test what happens in those cases--unfortunately, I don't 
have any such recordings, so I'll have to fake one to see how to 
identify it.  (Funny enough, I lost power at the house midway through 
The Tonight Show on Friday night, and the backend shut down until power 
was returned, so I actually had a 2-part recording that would have shown 
exactly what data we have.  Unfortunately, I've already watched and 
deleted it, so I don't have the data to check if there are any good 
indicators.)

I think detecting the not-finished recordings will be much easier with 
some post-0.24 changes that were made, and even easier after the 
above-mentioned changes we're making to the schema.  (Using only the 
post-0.24 changes could cause false positives, but with the schema 
changes, we may not see those false positives.)

Anyway, just some ideas that may help.

Mike