[mythtv] Scheduler needs table keys?

[David Engel]

On Sun, Jan 28, 2007 at 07:54:21PM -0800, Bruce Markey wrote:
> David Engel wrote:
> > 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.

For a combined FE/BE, I would expect the recorder thread priority to
be lower than the frame timimg, but higher than nearly everything
else.

> > -- say an option to automatically allow re-record after delete.
> 
> Which... we... already have?

Right! :)

> 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.

Since not touching the the recorded table during the scheduling
process is one of the goals, keeping rsCurrentRecording during the
actual scheduling could be difficult.  I suppose it could be done
after the fact in getAllPending(), or it could be left to just the
details screen.

On Mon, Jan 29, 2007 at 12:05:43AM -0500, Chris Pinkham wrote:
> That's probably the best real-world example I could come up
> with for why I'd want to check for dups in the recorded table.
> I still don't use it though, so if it makes sense to get rid
> of it then I'm for it.

It sounds like we're all in agreement, then.

On Sun, Jan 28, 2007 at 11:55:36PM -0500, Chris Pinkham wrote:
> Well, I was looking into this a little and it's not as easy as I thought
> to do it this way.  Because MSqlQuery inits QSqlQuery, we can't just pass
> in a null MSqlQueryInfo and init the db connection when the thread gets
> around to processing the query.  I wanted to keep from having to rewrite
> queries the way the current async thread does, so I'm going to keep
> looking at this trying to figure out a solution.

Could you pass the DB connection and query objects together for later
execution?

David
-- 
David Engel
david at istwok.net