[mythtv] [mythtv-commits] Ticket #3872: Zero-byte recordings should not exist

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

    > Date: Sat, 20 Sep 2008 11:05:38 -0000
    > From: "MythTV" <mythtv at cvs.mythtv.org>

    >  To go further, we should maybe even attempt to retry the recording a
    >  couple of times with increasing intervals, up to 120 seconds after the
    >  first failure, before giving up. Losing the first two minutes is better
    >  than losing the entire recording because of a temporary glitch.

I'd say do both---attempt to rerecord immediately, -and- schedule
another recording.  That way, there's a chance for a pristine
recording that has all its contents even if the user doesn't
discover everything until later.  (Many things on my schedule
tend to get repeated 4 hours later---that's nowhere near enough
time to discover a problem unless things mostly get watched in
near-real-time, which isn't the typical mode for a PVR.)
[The problem with "record later as well" is that systems which
run near capacity on their tuners might bumpb a lower-priority
show seemingly at the last minute, so presumably you'd want a
switch to enable/disable this behavior.]

A great addition would be some sort of hook that gets called to ask,
"Is this recording defective?"  I've been wishing for such a thing
for a long time.  That way, the zero-or-nearly-zero check could be
just one of a whole series of integrity checks that get applied to
a recording; users could come up with others that get distributed
in the contrib directory and used as-needed.  Presumably,  you'd call
the hook anytime a recording is deemed finished, for any reason; you
could specify it as a user job or something---the hard part is the
framework for enabling users to trivially say "this recording that
this user job is looking at is defective and needs to be rescheduled"
and having that built-in saves users from having to figure out how to
patch the scheduler or something.  [If such logic is in fact trivial,
someone should write the script and stick it in contrib and then any
user job could use it; I'd then create a page in the wiki asking for
contributions of such scripts & they could get packaged into contrib
at some point.]

For example:
o  Does this recording have Emergency Alert System tones embedded
   anywhere in it?  I've been repeatedly screwed by my cable provider,
   which seems to put these "monthly" tests in at random times on
   random channels and which seem to land on an inordinate number of
   my recordings.  (Perhaps because many are made after prime-time.)
   By the time I discover it, any possible repeats are long gone.
o  Is this recording totally silent?  If so, audio broke soemhow.
   Often this indicates a problem at the headend (some of my PBS
   channels will broadcast nothing but a screen-saver-like "No Signal"
   message and black or frozen video), but more than once it's because
   a line-in cable got bumped while doing something nearby.  Ditto
   with "is more than x% of this recording silent?"  This catches
   the cases where the broadcaster screwed the pooch halfway through
   (happens quite a bit to me on PBS and occasionally CSPAN).
o  Do too many frames of this video look like the rest?  That could
   indicate black or frozen video, as above. 
o  Is there a "No Signal" icon anywhere?  How about an "Unauthorized"
   logo from a malfunctioning cable box?  Both are discoverable by
   running the video through a tool like that black-frame-detector
   someone here wrote that ASCII-fies some frames and greps the
   resulting characters.
o  Is the recording abnormally short?  Not just zero bytes or only a
   few bytes, but, say, less than 90% of what we might compute it
   should be for the source & destination.  Obviously a heuristic,
   but catches the case where the signal degrades and the encoder
   gives up.

I'm sure there are many other random tests people could contribute.

(Some of these might be better integrated into the commflagger, simply
because it may have some of the logic already and it's already reading
the data & it'd make sense to minimize disk I/O, but that assumes that
the commflagger runs for everything (even comm-free programs) and it's
probably also a lot easier to integrate disparate checker-scripts if
they don't also have to interact with the complexity of the commflagger
[though some sort of hook there might be useful, too].  A hook that
user jobs could call seems conceptually simpler and might take someone
who knows what they're doing only a few minutes to bang out.)