[mythtv] Re: [mythtv-commits] mythtv commits

[Steve Davies]

David Engel said:
> On Wed, Jan 21, 2004 at 08:36:48PM +0000, Steve Davies wrote:
>> One is the scenario where A overlaps B, and B overlaps C. The scheduler
>> MIGHT disable A to allow B to record, and then disable B to allow C to
>> record. A can now be recorded, so I have added a pass to check for
>> auto-disabled programs which can be recorded after-all.
>>
>> There is also the case where conflict resolution fails, but there is an
>> "rsOtherShowing" available that the scheduler missed because it was
>> originally conflicting with something. The same pass finds these, and
>> uses
>> them if possible.
>
> OK, those are cases I've wanted to look at but haven't gotten to yet.
>
> Are you sure you can do it one pass?  My thinking was the algorithm
> would need to iterative, e.g. whenever the scheduler chose to disable
> one recording in favor of another, it should start over and re-evaluat
> all remaining candidates since the conflicts will have changed.

:-) I cheat, and only cover the very simplest cases. If a currently
conflicting program can be relocated to another showing, and not cause a
new conflict, it is moved, reducing the conflict count by at-least one.

If you would like, I could try and change this so that if priorities are
enabled, the candidates for repair are put into a temporary list, and
sorted by priority. This should satisfy the remainder of your requirement
(or not?).

The current patch does this using DoFixup() and findOtherShowing(). An
example of what is NOT done is that the above pass might free up a
"better" slot for an existing program, or allow a further improvement if
it were run a second time.

> It's unclear which conflicts should be resolved first.  Scheduling the
> highest ranked program first is straight forward and very
> determineistic.  However, as has been pointed out before, if the
> highest ranked program has other showings available, moving it could
> result in other programs with less flexibility to be recorded that
> otherwise wouldn't.

But surely the fact that priority has been increased implies the reduced
flexibility for the remainder of programs?

>
> David

You make some good points on how this could be improved. Would you like me
to look at it some more? I don;t want to overlap effort with you. I think
what I'm doing is "OK" just not yet "complete".

Regards,
Steve