[mythtv] conflict resolution

[Edward Wildgoose]

> Hmmm... along these lines, what if a 'fuzzy timeslot' was based more on 
> time-of-day, instead of actual time?  By this I mean have a standard 
> day divided into periods like 'morning', 'mid-day', 'afternoon', 
> 'evening', 'prime-time' and 'late-night'.  The relevant start/end times 
> for each period could be configurable.  Then, if I specify a 
> timeslot/weekslot recording, the scheduler would know that if the 
> instance I scheduled is on at 21:00, then what I really want is a 
> 'prime-time' timeslot/weekslot for this program.  So if the show gets 
> moved around by the network, as long as it's still on in 'prime-time', 
> it will get recorded, but it will know enough not to record the 
> syndicated re-runs that are on at 18:00.

It's a good idea, and it makes the sql simpler because you can go back to exact date/time matching, ie program name="blah" and starttime>=StartofPrimeTime and EndTime<=EndOfPrimeTime

However, there will be some interesting discussions as to what defines primetime...  Probably you need overlapping periods for a start, eg daytime is up to 6pm, but primetime is 5pm onwards.  Use some heuristics to decide which slot you want the program. 

The point is there will suddenly be a problem when you want to record a program which is on at the very begining of prime time which is then moved back by 10 mins...  

I think that the fuzzy, give or take 1 hour strategy will work better, or perhaps even just skip the whole time thing and the match becomes "on this channel, on this day"?  Would make it difficult to record the "News" though... (or something else very generic)

It would be nice to get something which works quite nicely for most people though, *rather* than introduce yet more "record types".

Anyone else got a better idea than the fuzzy match to the nearest hour?