[mythtv] (How) does allow re-record work?

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

    > Date: Tue, 24 Jul 2007 21:57:38 -0400
    > From: Tony Lill <ajlill at ajlc.waterloo.on.ca>

    > I was thinking progamatically. I've modified the commercial flagger to
    > recognize recordings with long blank stretches (tested and working) or
    > long frozen stretches and do "something". Just working on the
    > something bit.

Can you post your patches?  I've been (slowly) working on similar
automation and in fact posted a list of several ideas for how to do
this quite some time ago.  I'd be happy to contribute other approaches
(e.g., there's code to do silence-detection [*], which can also be a
good way to find defective stuff---especially since I had a string of
recordings with perfect video but no audio at all due to some sort of
ivtv weirdness that has hopefully been banished; others may trip over
this by, e.g., having a connection come loose from an STB, or because
the wrong audio track was somehow selected for a program with
several).

I'm guessing that you're using the commflagger because you can
piggyback on its image-analysis code, and also because you can
piggyback on the file I/O it has to do---correct?  The sort of
stuff I've been playing with bypasses the commflagger, because
not everything -gets- commflagged (some of the worst issues have
been with the local PBS outlets, for which running the commflagger
is surely wrong).  (It also means I can experiment with automation
that can run standalone, e.g., software that can analyze files but
wasn't written with Myth in mind---and that such code, which I had
assumed wouldn't get committed to the Myth mainline, wouldn't have
to be continually re-merged with new versions.)

It seems that the perfect architecture for this might be some sort of
mechanism that has the following pieces:
(a) The work you're doing now to get rerecording to happen without
    having to delete the first try.
(b) Your commflagger modifications.
(c) Silence detection.  (Does the commflagger do anything with audio?
    It would be efficient to roll such detection into it just to save
    on having to make multiple read passes over the recorded program
    and save the I/O, but I don't know how easy it might be to make
    the modifications.  Perhaps just some way to tee the I/O it's
    already doing to an auxilliary program like mp3cut? [See below.])
(d) Ideally, some easy modularization that allows adding other
    criteria (standalone or in the commflagger) that says "bad
    recording".  Static is one; I'm sure there are others.  Once
    there's the ability to say "rerecord this" with an easy API,
    of course, others could just write standalone programs and run
    them as user jobs.  [For example, one thing I've been
    experimenting with involves grepping the closed-captioning data
    for non-stopwords that also appear in the description, and
    complaining if not enough do; this has been handy on various big
    documentary series such as How It's Made where my local station
    occasionally aired completely the wrong episode & it finds such a
    screwup immediately, whereas the actual episode might not get
    watched for a while---too late to pick up the -correct- repeat
    later in the day.  This clearly shouldn't be part of the
    commflagger (for one thing, most people don't have the CC-dumping
    code!) but would absolutely benefit from the API you're trying to
    get working.]
(e) Some way of saying, "Run the commflagger to determine whether this
    is a bad recording, but DO NOT actually produce a commercial
    cutlist"---the idea here would be to allow running the code that
    determines whether this was a bad recording without also trying to
    cut commercials, since noncommercial stations don't want that.
    (It seems like the most trivial mod would be to simply inhibit the
    actual cutlist-writing; something more efficient might also
    inhibit any of the non-analysis work that would go into making
    that cutlist.)  One problem with this is UI issues---in the best
    of all possible worlds, all this code will eventually wind up
    inside Myth itself, but there needs to be a clean way of
    explaining to users "don't analyze" vs "analyze but don't
    commflag" vs "commflag"; I can see several ways of doing this,
    but others may have different ideas.  The actual non-UI guts
    seem quite simple, though, since presumably you'd have a DB flag
    that just says "do analysis & rerecord if it looks bad" and, if
    set, would -always- run the commflagger, but the running
    commflagger would inhibit generating a cutlist if the UI element
    for "find commercials" is turned off for this particular
    recording.  (You could presumably hair it up by having a flag
    to enable each individual analysis strategy, but that's a detail.)

[In fact, I just today caught a situation where half a dozen channels
were completely black for almost two hours due to some screwup at the
headend, and had I not caught it by hand fast enough, the repeats for
shows on those channels would have vanished before I told Myth to
rerecord.]

[*] For example, transcode has the detectsilence plugin, but I've also
got a script (courtesy of someone on that list) which uses cutmp3
(version 1.9.2 or later) and some other logic around something like
     echo pppppppppp1111111111PPPPPPPPPPq | cutmp3 -s 0 -i $F
to get a list of silences (default 1 second, but configurable) and
then postprocesses the resulting output to figure out where the holes
are; a big-enough hole means "recording bad" and you try to get another.