[mythtv] Feature freeze vs contrib vs trac

[Joel Melohn]

Sent from my iPhone

On Aug 23, 2009, at 1:44 PM, f-myth-users at media.mit.edu wrote:

>> 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.
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev