[mythtv] Scheduler needs table keys?

[Chris Pinkham]

* On Sun Jan 28, 2007 at 09:05:02PM -0600, 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. :)

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

Personally, I think that if there isn't a locking issue then it doesn't
matter if it takes 10-20 seconds to run at low priority.  I do think
we need to do something about it running repetitively like when you're
going through Watch Recordings and cleaning up stuff.  It would be nice
if the first signal triggered an immediate resched.  If another signal
was received within X seconds of the first resched finishing, then we'd
wait for a few seconds before doing another resched.  Perhaps this would
only be done on rescheds triggered by deletes.

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

I don't see it as that farfetched, but it's not even something I use so
I wouldn't fight for it. :)  I think my main case for this is if someone
wants duplicates on a show that is one that comes on 5 times a day, 30
times a week, they could end up with 5 copies of the same 6 recordings.
I can see this being a little contrived and it probably goes along with
my "any time any channel" recording mentality. :)  If the user wants to
shoot themselves in the foot and have 30 copies of the same episode of
Gilligan's Island where the Professor makes a radio out of a coconut,
then let them do it. :)

I think the best short-term solution is to make the DB updates in the
recorders happen outside of the main recording thread.  If there are
other issues after that they can be addressed separately, but there
are several things that could cause contention using the current
in-line method.

--
Chris