[mythtv-users] Odd behaviour when a program is scheduled to record by two schedules at once

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

    > Date: Fri, 20 Jun 2008 17:32:41 +0100
    > From: nick at craig-wood.com (Nick Craig-Wood)

    > It isn't a very common problem because it is hard to make schedules
    > that cause trouble like this without using the power search, and most
    > people don't run multiple schedules for the same show.

I was caught out in a similar way, because I assumed that Myth
would OR the results of various rules, hence -any- rule which fired
and matched a showing would cause that showing to be recorded.  This
seemed a perfectly normal thing to expect, since that's how most
rule-based expert systems perform, and it's also how the TiVo's
scheduling algorithm works.  But after having been burned, and asking
about it on the list, I discovered that that's not how the Myth
scheduler works.  It certainly complicates the logic of some of the
rules I'd like to write, because it means that I have to write rules
to -exclude- certain showings so that some -other- rule will match,
to avoid having two rules that both match the same thing.  This is
hard to write and hard to debug in general (and very unmodular if
you look at the rules as an RBES).  [Note that my case wasn't using
priorities at all; it was merely "should this be recorded at all?"]

It also makes it very difficult to use non-power-search rules to do
certain things, because using two built-in rules (or whatever the
terminology is for the sort of non-SQL-exposing rules you get from the
normal frontend/mythweb interface) to accomplish the task can conflict.

I'd certainly rather they OR'ed; this seems the easiest to explain to
people, and it makes it easier to figure out -which- rule to rewrite if
something got recorded that wasn't supposed to be or vice versa.  It's
also the safer failure mode (e.g., something got recorded redundantly)
compared to the current mechanism (something -didn't- get recorded
because of interference from some other rule you weren't even looking
at).  [Yeah, yeah, "not that safe 'cause it may conflict with something
else you also wanted to record!"---I'm not going to include every case
here to satisfy the pedants or this would be three times as long.]

I can think of several options here:
(a) Change the myth scheduler to OR rules.  I'm guessing that this
    would be unpopular, either because (1) the devos want it to work
    this way and it's somehow considered a feature, (2) it's a bug,
    but too risky to change (or too much work, or not in demand
    enough, etc).
(b) Write a checker to notice clashing rules and at least warn about
    them.  Might be difficult or actually impossible without having it
    -also- have access to the actual listings data, which would mean
    that you couldn't just run it once and forget it---you'd have to
    have it run every time new listings data arrived, or something.
(c) Write a compiler that can take rules written as OR'ed single rules
    and combine them into a single more-complicated rule that covers
    all the bases.  If you know -which- rules to OR, you could write
    them this way yourself (though they might get unwieldy); the
    problem is unexpected clashes---that's where such a compiler might
    be most helpful.
(d) Live with it and have people get caught out occasionally, as you
    and I have, and no doubt others whom I've forgotten or who never
    posted about it.

Unfortunately, I expect that any of the top three options are more
work than anyone wants to put into it, so we're probably stuck with
(d) unless someone gets inspired.