[mythtv] Scheduler needs table keys?

[Bruce Markey]

David Engel wrote:
> On Mon, Jan 29, 2007 at 12:44:42PM -0500, Chris Pinkham wrote:
>> * On Sun Jan 28, 2007 at 11:01:57PM -0800, Bruce Markey wrote:
>>> "Yes, and allow re-record" would have the identical behavior.
>>> It would not duplicate an existing file but would allow the
>>> same episode to record again any time after it was deleted.
>> Allow Re-record doesn't prevent 5 copies of the same episode
>> from being recorded at different times.   If the Simpsons comes
> 
> Yes, it will.  When episode 101 is recorded, an entry gets added to
> oldrecorded.  Unless you do something to that oldrecorded entry,
> episode 101 won't get recorded again.  After you finishe watching
> episode 101 and go to delete it, you can choose to allow re-record.
> Then and only then, can episode 101 be recorded again.

Correct.

Chris, I just came out of 'the way-back machine' (I wonder
how many people will get that reference). There was a time
when things didn't get added to oldrecorded until the recording
finished successfully. This may be the origin of checking
both tables. However, this changed years ago and there is
an oldrecorded entry added at the same time as the recording
starts and the recorded entry is added. The fact that there is
an entry in recorded merely duplicates what we know from the
oldrecorded table.

In fact, oldrecorded now tracks a ton of info like the record
status and includes items that didn't record for logging. There
is a "duplicate" flag to mark if something is to be used for
dup checking or not. It used to be that ForgetHistory would
blow away the oldrecorded entry but now it leave the row in
place and toggles the duplicate flag. The history of the show
being recorded is still on the Previously Recorded page and
the status is "Re-Record". You can even un-ForgetHistory.

Details aside, the fact that something is in recorded doesn't
tell us anything significant that we don't already know from
oldrecorded. When Simpsons 101 starts it is added to recorded
and oldrecorded and will not be scheduled to record again either
because of the oldrecorded entry or the redundant check of the
recorded table. When it is deleted and allowed to re-record, the
recorded entry is blown away, the dup flag is cleared and it
is now allowed to record again.

For all the redundant overhead of checking recorded by default,
there is a nasty side-effect. Say I record MythBusters one cold
and stormy night. The next day I start to watch it but just as
they are about to stick the gun power wrapped in tinfoil into
the microwave, the audio goes out. A sever weather warning scrolls
across the screen with intermittent tones for about two minutes.
I want to get a clean recording on Friday but I still want to
see what happened to that microwave. I chose to clear the old-
recorded entry but, surprise, it is now marked Currently Recorded
and will not be scheduled to record even though I explicitly
requested that it re-record.

The next step is to go into the rule and change the dupin to
check oldrecorded only. However, there is a more annoying
variation with FindOne. Here you can't (easily) 'keep and
re-record' because the dup options are grayed out for rectype
FindOne. This has bitten me several times.

I think that oldrecorded should be authoritative for dup
checking. However, a thought right now is that if we do want
to know if something is currently recorded, we could add another
flag like oldrecorded.current to track if an episode is currently
recorded while never querying 'recorded' from within the
scheduler. I think I'd like this.

--  bjm