[mythtv] Scheduler needs table keys?

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

    > Date: Sun, 28 Jan 2007 17:12:12 -0500
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > * On Sat Jan 27, 2007 at 11:34:26PM -0800, Bruce Markey wrote:
    > > I'd always favored All for simplicity but checking a few
    > > hundred programs on a channel is much quicker that searching
    > > thirty or forty thousand programs.

    > Yeah, after running those tests on my system, it made me want
    > to go back and change a bunch of them to only record on the
    > original channel.  Most shows we record are never going to
    > switch networks, they'd get cancelled first. :)

One thing that would be handy for this purpose---but introduce too
much complexity for the benefits, I'd imagine---is a way of saying
"any of -these- channels" without simply having to write the same rule
n times, one per channel.  This comes up mostly with PBS---I get three
different PBS channels (and I'd get way more if I was doing digital),
and something might show up on any of them.  I typically say "any
channel" even though Nova will never show up on MTV simply because
it's much easier from a UI perspective.  (And because I expect the
scheduler to cope without damaging recordings, of course... :)

[Yes, I could use a Power Search or whatever and write my own SQL,
I suppose.  Too much work, especially in this release where I have
to use the frontend and not MythWeb to do so.]

There are certainly other cases where "any channel" is the right thing
(stuff in syndication that unexpectedly pops up on another channel
when it get renewed or a season changes or whatever)---and until it
became obvious the scheduler was screwing me, it always seemed most
logical to simply say "record this no matter how you find it" and
maybe be pleasantly surprised that it found something on an unexpected
channel, rather than missing something because I was too restrictive
(which has burned me in the past, causing me to change several "single
channel" rules to "any channel" rules for precisely this reason.)
And I'm betting that I don't have enough of them to help enough w/the
scheduler issue, so I'll probably leave mine alone.  I don't care how
long a reschedule takes (within reason---like under a minute) as long
as it doesn't cause dropped data.  (Granted, faster reschedules would
be nice in general---especially since deleting a number of things in a
row gets slow 'cause after the first 2-3 deletions, the UI freezes and
won't let me delete any more until the scheduler has finished catching
up on the 2-3 reschedules queued one right after another from those
deletions.  I'd think there's gotta be a better way of handling this.
One way might be to delay reschedules for a few seconds, or to simply
drop any pending reschedule if one is already in progress, but
remember to do a final one "soon" if that happened---sort of the way
TCP tries to do tiny-packet optimization.)