[mythtv] Scheduler needs table keys?

[Bruce Markey]

David Engel wrote:
> On Mon, Jan 29, 2007 at 04:49:35PM -0800, Bruce Markey wrote:
>> So, what have we learned today:
...
>> - The option for '...current and previous recordings' serves
>> no purpose, is redundant and can go against the users intent
>> yet this is the default. This should go away.
...
>> - Adding a 'current' flag to the oldrecorded table would allow
...
> 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.

--  bjm