[mythtv] Scheduler needs table keys?

[Bruce Markey]

David Engel wrote:
> On Sun, Jan 28, 2007 at 04:59:47PM -0500, Chris Pinkham wrote:
>> different ways to run a background SQL command.  I was tossing around
>> the idea of a MSqlQuery::asyncexec() that would pass the SQL off to
>> the background thread, that way you could call MSqlQuery::exec() to
>> execute immedately/syncronously and MSqlQuery::asyncexec() to execute
>> in the background.  I do think that both of these should be put into
>> another thread as I've stated in other email threads. :)
> 
> We might also consider letting the recorder thread use real-time
> scheduling.  That would help make sure it runs ASAP after the kernel
> has data to be read.

But it isn't specific time sensitive in the same way that the
playback frame timing is and I wouldn't want the backend competing
and causing jitter. It may be a matter of higher priority to
be higher in the run queue and grab a time quantum sooner but
the frame timing needs first dibs as far as specific time at the
exact moment it need to update the frame buffer.

>> recording.  To accomplish this, filesize and basename would be moved
>> to a 'recordedfile' table.  This table wouldn't need to be accessed by
>> the scheduler so the contention would go away.  I don't think that this
> 
> Another way to remove contention would be to get rid of
> kDupsInRecorded so the scheduler wouldn't have to touch the recorded

For it. (Chris Petersen: See. I told ya!)

> table.  You've objected to this in the past on grounds that someone
> might want to record all duplicates but only if they're not currently
> recorded.  I doubt such a contrived case is important enough to worry
> about, but if it is, I wonder if it couldn't be handled some other way
> -- say an option to automatically allow re-record after delete.

Which... we... already have?

My take on this was that it was the poor man's maxepisodes=1
before we had maxepisodes. However, this only tripped me up
more than it helped me (like, a ratio of a bunch to zero).

If I record a show but see there is a problem, I may want to
record it again but want to keep what I have already until
the good recording. I'll remove it from oldrecorded but the
status of the next showing is rsCurrentRecording until I go
in and change the default dupin option.

I'd rather trust only the oldrecorded table for the dup status
but it would still be nice to flag that an episode is safely
in the recorded table somewhere and ready to be watched but
if they get flagged P rather than R, that's fine.

--  bjm