[mythtv] Feature freeze vs contrib vs trac

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

    > Date: Sun, 23 Aug 2009 09:12:04 -0400
    > From: Craig Treleaven <ctreleaven at cogeco.ca>

    > At 4:39 AM -0400 8/23/09, f-myth-users at media.mit.edu wrote:
    > >implements various
    > >signal-processing tricks to detect recordings ruined in certain ways
    > >by the broadcaster so the user can be told in enough time to schedule
    > >a repeat, if available.

    > Sound very interesting.  What kind of ruined recordings are detected?

EAS alerts and silences.

Emergency Alert System notifications are those things with the
tonebursts and a placard of text (usually) that people in the US often
see late at night.  Comcast, my provider, emits them on -every-
channel simultaneously, more frequently than once a week, as part of
so-called "required weekly tests", and they destroy 1-2m of the
recording.  There are several random times between around midnight and
3am that they tend to do this, and there's little regularity--- this
week, they were only 72 hours apart!  And they managed to step on the
-same piece- of the same movie I was trying to record, and which only
aired twice---even though the movie actually aired at different times
of day.  Usually, though, it's possible to rerecord something which
airs more than once and miss the alert the second time around---but
only if you know about the alert promptly, so you can catch a repeat
that might be only a couple hours later, and not next week when you
finally sit down to watch and find something crucial is missing and
there's no repeat to be found.  [EAS tonebursts are also used for
weather alerts, such as nearby tornados, so they're not -just- useless
tests for a nuclear attack that has never happened.  But you still
probably don't want to have a weather alert stuck in your recording
if you can get one that doesn't have it.]

Silences generally indicate problems at the broadcaster---my local PBS
affiliates (all three of them) often have issues where the feed will
just freeze for a few minutes or an entire hour, or they'll put up a
little screensaver-esque bouncing blue rectangle saying "No Signal"
---obviously generated from something in the broadcaster's signal
chain.  Less frequently, I've also seen issues where other channels
will freeze during the program until the end of the showing, or will
freeze during a commercial break and then return to the program a few
minutes later, in-progress.  Once again, if there's a repeat available,
I can reschedule, but only if I know promptly.  The scripts that run
the silence detector currently use two different thresholds for how
long is too long, since some movies may have silent pieces (during
credits, for example, or even during normal action) that can be 3-4
minutes long, but you'll never, ever find more than a few seconds of
deliberate dead air on the Discovery Channel, etc, but do occasionally
find 3-minute-long frozen segments.

Detecting silence obviously might also help people whose cable boxes
or DISH receivers claim to be tuned to a signal, but are actually in
"Press Select To Continue", turned off, or other useless modes.

Both of these detectors together take about 1% or less of a slow
CPU, per stream, to run in real time.  They can be run on any file,
generated by MythTV or not, which mplayer can play.  You can get
the notification seconds after the problem---long before the current
showing even ends---or you can scan the entire file looking for any
other problems it may have.

The obvious next step is to have Myth reschedule automatically in such
cases.  That might be somewhat tricky, but later Myth versions might
make this feasible.