[mythtv] Scheduler needs table keys?
david at istwok.net
Tue Jan 30 02:20:47 UTC 2007
On Mon, Jan 29, 2007 at 04:49:35PM -0800, Bruce Markey wrote:
> So, what have we learned today:
> - The scheduler can and should run without querying the
> recorded table.
Attached is a partial patch I did this afternoon. It includes another
partly related change I'm working on. I'd like to hear from anyone
plagued with bad ivtv hiccups if it helps.
> - Much to my surprise, at least three people use '...current
> recordings only' to auto allow re-record. While this could
> be done by clicking the button that expresses their intent
> rather than the one that doesn't, because some people do use
> this, this current functionality should not go away.
> - Adding a 'current' flag to the oldrecorded table would allow
> '...current recordings only' to work without having to JOIN on
> the recorded table.
> - A 'current' flag would allow setting reclist items to have
> a status of rsCurrentRecording without querying the recorded
> table and without even having to choose 'current recordings'
> as a dupin option. This piece of information would be available
> even if it wasn't needed for dup checks. This would also allow
> the Previously Recorded page to show Current Recording status.
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
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.
david at istwok.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3848 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20070129/43c483cd/attachment.bin
More information about the mythtv-dev