[mythtv] RFC: Better handling of time changes for a Single Recording

[f-myth-users at media.mit.edu]

    > Date: Thu, 10 Sep 2009 13:36:07 -0700
    > From: Rob Smith <kormoc at gmail.com>

    > On Thu, Sep 10, 2009 at 12:39 PM, Matthias Dahl
    > <ml_mythtv-devel at mortal-soul.de> wrote:
    > > All I wanted to say is, we should _always_ favor a partial or even partially
    > > corrupted recording over simply losing it totally. And naturally, we should
    > > try hard to record what the user scheduled and not bother him/her until really
    > > necessary like the show was replaced by something different on the EPG and we
    > > have no way of knowing what to do next.
    
    > This makes no sense to me. I'm about a month behind on my tv already,
    > and there's typically reruns a few hours later (4 hours offset or so)
    > or later the week/weekend. By the time I'd notice something is
    > corrupt, it's out of frequent play mode and onto a few weeks/months
    > until I can re-catch it.

    > So giving me a partial recording is way worse then just missing it imho

Or you could do as I've suggested before, which is:

(a) Keep trying to record, perhaps leading to a corrupt recording.
(b) Record in the DB that you believe this recording is corrupt, but
    keep it around just in case it turns out it's the best you can do.
(c) Reschedule it for rerecording, so you might get a good copy.

[For the sorts of damage I see, sometimes you need -both- copies,
because each one has damage inflicted in a different place!]

I have automation that does exactly this, but it does the reschedule-
it-for-later part by abusing the myth internals rather than using a
sanctioned interface.  In particular, I nuke the programid (but keep
it around elsewhere so I can put it back) so the scheduler believes
this recording never got recorded, and hence it will try again,
subject to all the usual rules about conflicts, priorities, and so
forth.  This isn't a great solution for a number of reasons, some of
which include:

(a) Unless I force an immediate reschedule (which I don't), the
    scheduler won't actually update things until something else
    stops recording; this means a back-to-back repeat won't be
    detected in time.  So far, this hasn't been annoying enough
    to fix.
(b) If you're tuner-constrained, it's possible that automatically
    rescheduling something will bump something else, which means
    you have to be good about telling Myth what you -really- want.
    (And there's no way to tell Myth how to interpret priorities
    when it comes to a partial/corrupt recording:  "Record this
    over that -unless- one is corrupt, in which case..."  Bah.
    Plus keeping the possibly-corrupt/incomplete copy can affect
    "record only n episodes" sorts of rules, which I don't use but
    some people do---although I'm guessing that nuking the seriesid
    too might finesse that.)
(c) Sometimes damage is in a part of a recording you don't care about,
    such as pre/postroll or a commercial.  In that case, autoscheduling 
    a replacement might needlessly busy a tuner/eat storage due to the
    false positive.  (In my case, I have enough manual input to the
    process that this isn't usually a big problem.)

Check out http://svn.mythtv.org/trac/ticket/6899, which demonstrates
one real-time damage-detector, but doesn't include any hooks for
automatically rescheduling or keeping track in the DB (but you can
grep the logs it creates).  If anyone would like to hook this into
the scheduler (via some aborted-recording logic), that'd be a nice
addition.