[mythtv] conflict resolution

[David Engel]

On Sun, Nov 02, 2003 at 12:01:01PM -0800, Bruce Markey wrote:
> So it looks like this patch expects a recordoverride table to
> be created and populates manually for testing the concept. Is
> that correct?  

Yes.  I was only wanting to test the scheduler impact and also not
affect my production mythbackend.

> Could this be merged with the existing
> conflictresolutionoverride tables and code or is it better to
> keep this separate? 

No, they are really different things.  The recordoverrides are more
like hints to the scheduler on specific episodes.  Recording conflicts
can still occur which is where conflictresolutionoverride and the
various ranks come in.

> How would override record (1) compare with
> single record (record.type == 1)? Have you considered adding
> a new type for the 'record' table for "don't record" rather
> than adding a new table with essentially the same fields?

I haven't really given such an approach much consideration.  My gut
feel is that it would be more complicated.

> I could do this if I could mark either the 8:00 Nova or 9:00
> Joe Schmo as "don't record" so it would record the late night
> repeat instead. Note that I wouldn't want to spoof the Nova

This situtation is actually why I created the the override "do
record".  If you use a "don't record" on the early episode and a
conflict occurs on the late episode and you don't notice it, you might
not get either episode recorded.  However, if you use a "do record" on
the late episode, the scheduler will hopefully be smart enough to fall
back to the eariler episode if needed.

> If a showing is edited on an Options page that matches an
> existing 'record' entry and the type is changed it modifies the
> existing entry with it's original fields. What should happen is
> that if the type is changed to a single record, it should create
> a new entry in the record table and leave the recurring record
> entry in tact. If the type is changed to timeslot or weekslot

I understand what you are wanting, but I think this way is counter
intuitive.  It think it would also have the same complexitites as the
singel don't record type mentioned earlier.

> How ever you manage to make this work, I'd be very happy to
> have this feature. Good luck!

I want this feature too.  That's why I'm offering to work on it.  I
don't want to waste my time, however, on an approach that Isaac won't
accept.

David
-- 
David Engel
dlengel at attbi.com