[mythtv] Scheduler needs table keys?

[Paul Andreassen]

On Tue, 30 Jan 2007 01:42 pm, Bruce Markey wrote:
> David Engel wrote:
> > This would proably work, but I'll need think about it more overnight.
> > Part of me would rather add a new value to oldrecorded.duplicate
>
> Fine, it's just another bool.
>
> > instead of a new column.  E.g. 2 = current recording, 1 = past
> > recording (or never record) and 0 = not recorded or allow re-record.
> > Deleting a recording would change or.duplicate to 0 or 1
> > appropriately.  The scheduler could check for or.duplicate > 0 or > 1
> > as specified by the rule.
>
> This doesn't fix the "keep but re-record" issue I'd mentioned.
> I'd rather it only check & 0x01 by default but if '...current
> recordings only' is selected, test & 0x02. ForgetHistory but
> then having it blocked as rsCurrentRecording is evil.
>
> To flesh out my thought about marking "R" even though "current"
> isn't selected. The default would be '...previous only' and
> this would be true for 'new episodes', 'exclude generics' etc.
> They all check for & 0x01 except '...current recordings only'
> which checks for & 0x02.
>
> If it finds 0x01 it is marked as rsPreviousRecording then
> takes a quick peek to see if 0x02 is set and if so, change
> the status to rsCurrentRecording. Stated differently, if it's
> 1 the status is P. If it's 3 the status is R. If it's 2, the
> duplicate flag was cleared and it should be allowed to record.

If its true Indexes can't be used for <>, <, > and & tests then using a bit 
flags are terribly slow.  But maybe how this field is used makes this 
erelevant. 

Paul
--