[mythtv] Scheduler needs table keys?

[Chris Pinkham]

* On Sun Jan 28, 2007 at 05:10:33AM -0500, f-myth-users at media.mit.edu wrote:
>> From: Stuart Morgan <stuart at tase.co.uk>
>> On Sunday 28 January 2007 07:58, f-myth-users at media.mit.edu wrote:
>>> What sort of reschedule happens when recording ends or a deletion
>>> occurs?  (I'm assuming it's the same in 0.18.1 and SVN, but my
>>> experience is only 18.)  It looks to me (judging from my "-v all"
>>> logs) that the scheduler does everything it can:
> 
>> There is only one sort of reschedule, but I've started work to change that.

There are differences, that's why ScheduledRecording::signalChange()
takes a recordid as an argument.

> (a) Stop writing recorded.filesize during the recording.
>     (What will this break?)

I don't think this will be an issue in the future. (read on)

> (b) Put the length-writer (recorded.filesize) and the buffer-dumper in
>     separate threads.  (Presumably the length-writer won't get really
>     unhappy if it doesn't run for 30 seconds?  Presumably the
>     buffer-dumper will continue emptying ivtv no matter what.)

There is already a ticket and patch for recorded.filesize and the
seektable writing as well, but I'm debating whether that exact
implementation of the patch is the best way.  I'm wondering
if we can just pass a MSqlQuery to the thread so that there aren't
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. :)

> (c) Perhaps put recorded.filesize into another table entirely, or a
>     brand-new table, that isn't involved when the scheduler runs &
>     hence won't get locked.  (This might be the simplest fix, since it
>     doesn't involve threads, mutexes, or not writing data we used to
>     write---though it involves fixing all consumers of recorded.filesize
>     to look somewhere else.)

This is probably going to happen anyway.  One of the high-up things on
my TODO list is to add the ability to support mulitple files per
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
is a reason _not_ to do the above-mentioned background SQL thread,
there are other reasons why we don't want to be wasting time dumping
data to the database inside the main capture loops in the recorders.

> Maybe?    
> (d) Put the GOP-writer in a separate thread.  (E.g., just because we
>     might not write to "recorded" doesn't mean we won't try to write
>     to "recordedmarkup" & if that's hung, emptying the buffers will
>     hang.  [But will this hang during scheduling?  I'm no longer sure.])

Think I covered this in letter 'b' above.

--
Chris