[mythtv] Proposed workaround for scheduling problem with overlapped recording rules (bug #3242)

Bruce Markey bjm at lvcm.com
Fri Mar 30 20:24:36 UTC 2007


David Engel wrote:
...
> identical to what you posted.  I tried a few, very targeted tests, but
> mainly what I've done so far is to look for anomalies in my normal
> scheduling.

I've been using it in production too but that's just smoke
test that it didn't do some terrible damage (it didn't).
However, overlapping rules are rare enough that it really
needs test cases to look for specific potential pitfalls.

>> In the real world, If the 13:30 showing recorded to completion,
>> I don't think it needs to be recorded by another rule. This is
>> a contrived test case and this scenerio shouldn't matter in any
>> real situations (I don't think). A possible solution would be to
>> reconsider which rule after MarkOtherShowings but that would be
>> messy and probably unnecessary.
> 
> The fact the program gets re-recorded doesn't bother me at all.  The

Agreed.

> same would happen if the the C rule didn't exist and the A rule
> covered all matches.  In this case, the user might want to consider
> matchning duplicates in currentl recordings only.

The "user" in this case is trying to see if I can break things =).
Backing off this tree to look at a bit of woods, 'don't match
dups' would be for something where the programids were wrong,
misleading or the show should always record like kids cartoons
or something. The channel rule does match dups and these rules
both match the same episodes. This episode is shown twice in
24hrs so does it need to record both? Lacking an RS232 port in
the neck, there is no way of knowing the users expectation. Even
if the user had an opinion, whether there are one or two copies
of this episode isn't life or death either way.


> What does bother me, is the scheduler indicates the second showing
> won't record until the first one ends, then suddenly, the second

I agree.

> showing will be recorded.  It reminds me of a max episodes case I've
> fretted over off and on.  It all boils down to the fact we schedule
> programs in order of priority and can't easily account for some of the
> state changes that occur as things actually get recorded
> chronologically.  Everytime I considered solutions, I always came to
> the same "messy and probably unnecessary" conclusion.

This is why I wanted to re-frame the objective to eligible beats
known to be ineligible. I just don't think it is practical to
recursively reconsider things after placing each rsWillRecord.
I'm fine with rs(Earlier|Other|Later)Showing being eligible
and beating states that are known to be unrecordable.

>> Even though there may be odd results when doing stupid things,
>> this should cover the more general cases where a rule that is
>> ineligible to record will lose to one that is still eligible.
> 
> Agreed, but I still want to run it for a few more days myself.

"Don't change sh|t on Friday." -- a wise man

--  bjm


More information about the mythtv-dev mailing list