[mythtv-users] Detecting programs damaged by their broadcasters (or your receiver)

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Wed Aug 26 05:10:40 UTC 2009


A couple recent complaints about cable boxes being in the wrong mode &
thus missing recordings etc reminded me that I never mentioned this on
the -users list:

I recently created a ticket [1] that consists of a C program and some
scripts that look for common misbehaviors and can notify you in real
time if it seems like a recording has been ruined by the broadcaster.
It works by listening to the audio track and detecting (a) US EAS
tonebursts [and could easily be modified to detect other tonebursts
from other countries' systems] and (b) silences---whether it's your
broadcaster transmitting black video for a while, or frozen video, or
your cable box or DISH receiver being in some sort of "Press Enter to
Continue" mode, or ivtv didn't detect your audio standard and muted
itself, or your RCA cables fell out---whatever.

Even on a slow backend (an Athlon XP 2800+) this takes less than 1% of
the CPU per stream, most of which is actually mplayer stripping out
the audio. Because it's following along just behind the filesystem,
it's generally reading from your filesystem cache & not moving the
disk heads.

Since this works just by watching files written by your backend(s), it
should work for any version of Myth.  It should even work if something
other than Myth is creating the files, or if you have a big archive of
prior recordings you'd like to check for problems.

I'd be interested in feedback.  I'd also be interested in having
someone build on this sort of thing to have Myth mark such damaged
recordings as aborted so they'd get rescheduled.  (Note that you'd
want to keep recording the current one and not delete it because it
could be a false positive---or the EAS toneburst might land in a
commercial or before/after the actual content, in which case the
damage is avoidable.  Or it could be the only airing of the program
and so you're stuck anyway.)  My current code only notifies you; it
doesn't actually tell Myth about it.

My intent is to either have this wind up in contrib, or get merged
into Myth itself in some way.  (The commflagger is the obvious thing
that looks at the data, but the last time I looked at it, it didn't
use audio at all, and also didn't necessarily run in real time, and
running close to real time might be necessary to reschedule in cases
where, e.g., the broadcaster runs the repeat immediately after the
original airing, as FX tends to do and no doubt others.  People might
not want to force the load of realtime commflagging just to run this
very lightweight detector.  And then there are otherwise-commfree
sources...)

Lots of information on how it works & how to tweak it is in the files
in the tarfile in the ticket.  The code is copiously commented.

Enjoy!

[1] http://svn.mythtv.org/trac/ticket/6899

P.S.  Yes, my broadcaster (Comcast) really -is- this awful.  I get
multiple true positives on EAS's per week, and about one true positive
on silences per week, although the latter are often commercial
insertions gone awry.  I get no false positives with the default
values and no (known) false negatives.  (And there used to be a time
when all three of my PBS affiliates frequently aired totally black
video or completely frozen video by accident for hours at a time in
the early morning---except for the promo video that surrounded the
actual programming, which obviously got dropped in from a different
source in the studio and was fine.  One of them did this better than
once a week for -months-, until they [presumably] fired whoever it was
who was sleeping instead of watching the feed.  This was back in the
days of an analog feed, so I knew it wasn't Comcast's fault in that
case.)


More information about the mythtv-users mailing list