[mythtv] Scheduler needs table keys?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sun Jan 28 10:10:33 UTC 2007


    > Date: Sun, 28 Jan 2007 09:20:56 +0000
    > 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.

OK.  I'm presuming that no matter what, there will occasionally be
full-blown reschedules that will hang emptying ivtv buffers, so here's
my understanding of what might be done (one or more of the below), all
to prevent the thread that's dumping ivtv data from blocking on the
scheduler.

(a) Stop writing recorded.filesize during the recording.
    (What will this break?)
(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.)
(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.)

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


More information about the mythtv-dev mailing list