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

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Fri Jul 27 07:10:26 UTC 2007


    > Date: Wed, 25 Jul 2007 17:08:18 -0400
    > From: Tony Lill <ajlill at ajlc.waterloo.on.ca>

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

Ok.

    > It's not wrong to run comflagging, it just may be wrong to believe the
    > map.

Yes.  (I viewed it as "wrong" because for a comm-free program, why
burn the I/O and CPU time?  But if doing bad-recording analysis, it
should surely run.) 

    >       It would be nice is it could skip the advertising that goes
    > before and after so-called commercial free recordings. 

That's a really good point!  It might have to be slightly clever to
deal with pre-/post-roll, e.g., I usually record a minute early on
PBS because their timing jitters a bit, which conceivably means the
sequence is [prev prog tail][ad][start of wanted program], and you'd
want the first two []'s to be a "commercial".  Certainly you'd want
the last 3-5 min of any PBS recording to have a high probability of
"commercial" since they typically seem to air 56-58m of program and
then 3-4m of promos, in that order.  [I guess ideally you'd want to
also detect the sponsor ads, which are always 1-3m after the
ostensible start of the program.]

Really, the above paragraph might not be a bad idea to put in its own
thread as suggestions for commflagging, although my impression is that
purely algorithmic suggestions for commflagging (without patches :)
aren't well-received because lots of people suggest the same ideas
over and over.  [But I'm thinking of being able to give the
commflagger hints about particular programs, e.g., "things on this
channel [PBS] are of the form [promo][1-3m program][sponsors][50+m
program][promo]" or "this particular program [Colbert Report] has a
30-90s snippet at the end that isn't a commercial" or "this is a movie
channel, so it's like PBS but w/o the sponsor stuff once the movie
really gets rolling".  Maybe the right thing to do is to be able to
specify a probability distribution function (X-axis from 0 to 1 which
gets normalized to the actual length of the program) which is user-
contributed hints about the probability of a commercial being at any
given segment.  I can see a -relatively- easy UI for that.  But we're
wandering afield here...]

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

Yes.  Simple conceptually; might require some tweaks to the UI to
explain to users why the "commflagger" is running when they said a
source was comm-free, etc.

    > The com-flag 2 stuff looks a bit more modular, and can possibly made
    > plugable.

That's not in mainline yet, is it?  I confess I haven't kept track of
it carefully in a while.

    > 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 [bad?] recordings.

Ok.  Sounds like the audio-analysis-for-bad-recordings I was thinking
about will probably have to be a separate process until/unless the
commflagger listens.  (Though if not using it for -comm- flagging but
only -bad- flagging, maybe it's easy to at least pipe the stream to an
external process so it only has to be read off the disk once, to keep
from increasing the I/O load the analysis places on machines w/many
streams going.)

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

I'll post about it in a separate message (probably tomorrow); this
one's getting long.  [Alternate application that's kinda handy---
automatically doing the equivalent of "diff -iwBu | wc -w | sort -n"
between all pairs of episodes of something which isn't airing with
descriptions or episode numbers, etc; the first few lines will be
repeats that match things you've already recorded & can therefore
be discarded as dups.  And it's screamingly fast 'cause it's just
20-40K text files.]

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

Oops---I was careless and have used "cutlist" when I meant "skiplist".
E.g., it'd be bad to enable skiplist creation on noncommercial video
if the user also has autoskip set, because the commflagger is likely
to spuriously find "ads" that aren't there and skip, etc.  But the
point is just being able to turn it off while abusing the commflagger
to look for bad video, and it sounds like that should be easy enough.

The patch you sent makes sense to me; thanks!  I assume you'll send
out your how-to-actually-schedule-the-rerecord patch once it's nailed
down how to do this correctly; I've been following the discussion.


More information about the mythtv-dev mailing list