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

Tony Lill ajlill at ajlc.waterloo.on.ca
Wed Jul 25 21:08:18 UTC 2007


f-myth-users at media.mit.edu writes:

>     > 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

They're a hack, but sure. I've added a function
Programinfo::RerecordProgram, but I think I'll probably just fix
Programinfo::ForgetHistory to do it all and use that. That would "fix"
the Previous Recordings menu button too.

> 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

Yes, after all, if it can detect blank frames, it can detect blank
recordings.

> 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's not wrong to run comflagging, it just may be wrong to believe the
map. It would be nice is it could skip the advertising that goes
before and after so-called commercial free recordings. 

Anyway, comflagging can already do non-commercial flagging stuff, like
re-building seek tables. Instead of run/don't run, it could be run
with different options to enable/disable creating the map, but still
do other things. 

The com-flag 2 stuff looks a bit more modular, and can possibly made
plugable.
>
> 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.])

There was talk about it, but I can't see any new files in the com
flagger that might hold audio stuff. Not only silence, but also big
changes in volume can indicate commercials. Also check for white noise
for bar recordings.

> (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.]

That is so cool. I'd love to see that.

> (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

You need to specifically tell the comflagger to copy the commercial
skip list to the cutlist. I think there's some option in the setup to
turn this on and off. And you don't need this to get the frontend to
skip the commercials, only if you want this automatically applied
before you transcode.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: com.patch
Type: application/octet-stream
Size: 6998 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070725/1387882b/attachment.obj 


More information about the mythtv-dev mailing list