[mythtv-users] ProgramInfo, Error: - should be local, but it can not be found

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

Another (horribly brute-force) idea (which might not require that
scte65scan work, which I'm guessing from recent traffic on this
list might be defeated when they start encrypting the info) is:

(a) Interlock w/Myth about which tuner(s) are in use (maybe reuse some
    code from EIT scanning?) and also which are going to be in use "soon".
(b) Record a few seconds of video and feed it to the logo detector in
    the commflagger (or maybe in mplayer, depending on how integrated
    you're trying to be with Myth itself).
(c) Compare any logo found with a library of existing logos.  Start
    with the logo you expect to find; if you don't see it with
    sufficient confidence, expand the search.  This library is
    initially built from your own channels on your own hardware,
    of course, so you expect good matches.
(d) If you find no logo or no match, try again in a few minutes---you
    might have recorded during a commercial, which of course are just
    too precious to have a logo superimposed on them---we know who's
    really calling the shots... :)
(e) Iterate over all channels.  (The efficient way would be to be
    recording on one while checking for logos on the previous one;
    anything that fails to find a match gets added to the list to
    be checked again "soon"; things that -never- have logos maybe get
    added to an exceptions list.  Lots of ways of spiffing this up.)

Each step of this is a fair chunk of code, but they're all basically
independent pieces, and you might be able to reuse stuff from elsewhere
(in myth or not).  You could basically have it slowly scan all tuners
forever as a background task, reporting anomalies.  This might be an
interesting project for a motivated individual or two.  One nice thing
about the design is that, with the exception of (a) above, you don't
-have- to be part of myth at all (and could perhaps just talk to its
status port to do (a)), which means you could be relatively independent
of tracking myth versions, etc, and don't have to patch the main app
or run in its address space (making things safer wrt crashes).

This has some bugs:
(a) Assumes that the mere act of tuning isn't likely to cause a
    problem.  (But if you're getting crashes just from tuning,
    you've got other reliability problems.)
(b) Assumes you have logos avalable, and can find & compare them.
(c) Assumes that things are merely swapped around, rather than
    having parameters actually change such that you can't even tune
    them without the information available from scte65scan etc.  This
    is strongly hardware-dependent; for example, someone who gets
    channels via an IR blaster and an STB merely needs to iterate over
    all possible channel selections and if the frequencies change, the
    STB knows about it.  More-direct connections may be another story.
    Also assumes you can't get "stuck" if you tune to something that's
    encrypted or to which you aren't subscribed.
(d) Some channels have a rotating library of logos; there'd have to be
    provisions for having a many-to-one mapping of logos to channels.
    Animated logos are another headache.

P.S.  If you're very very lucky and you've got the right format data
coming in, maybe the channel callsign is in the info area that carries
closed-captioning data (e.g., line 21/22, etc).  But I suspect that
this will only work for a very small minority of formats and sources.
I've seen it myself, but that's NTSC SD (can't recall if it was from
a cable directly or via an STB), but I don't know how prevalent it is.