[mythtv] Scheduler needs table keys?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Sun Jan 28 06:02:15 UTC 2007


    Date: Sun, 28 Jan 2007 14:11:22 +1000
    From: Paul Andreassen <paulx at andreassen.com.au>

    I noticed Chris Pinkham mention it takes 19 seconds for a schedule run, mine 
    takes under a second.  Why is that?  Are some "Recording Schedules" more 
    complex with better guide information.  If so, are there extra keys we could 
    add to speed it up?

I'm geting times roughly equivalent to Chris':  typically 10-30
seconds per run.  Maximal ivtv buffering is around 15-20 -at most-,
so runs corrupt recordings to a greater or lesser extent maybe 20-40%
of the time.

I think Chris' later traffic shows part of what's going on; obviously
there are certain kinds of schedules that exacerbate the behavior.
But we can't simply ask people not to use those schedules lest they
push their system over the edge; the underlying unnecessary locking
of crucial tables should be avoided (or emptying the ivtv buffers and
writing into recordedmarkup (or its SVN equivalent) should be decoupled
so the former doesn't wait on the latter when the latter waits on the
scheduler).

I'm glad this is finally getting traction on the -dev list; I've been
complaining about this behavior for a year (as long as I've been
running Myth!), and it goes at least back to 0.18.1, since that's what
I'm (still) running.  At least now we seem to understand what's going
on, as opposed to "optimize! other spindle! tweak your config files!"
sorts of things, which have never helped sufficiently.

One other issue (which I've mentioned before, but which bears
repeating) is that this might hit ivtv users harder (or perhaps
-only-), since I'm not sure if other capture cards also write into
recorded markup the same way or handle their buffering in the same
way.  So people w/different hardware might never notice that their
scheduler queries are taking 15-30s because the delay isn't affecting
their recordings.  I sure never paid much attention until I realized
that every scheduler run had a pretty high chance of causing lots of
dropped frames in any in-progress recording, but once I noticed, I was
cooked---nothing I could do fixed it.  And any time a recording ends,
or a deletion happens, the scheduler runs...  And since I always have
hard rollin/out of a minute or two on every recording to compensate
for clock skew between stations, this means that almost -every-
recording has a chance of having a big glitch a minute or two into
it as some other recording ends at :01 or :02, etc.  Yuck.


More information about the mythtv-dev mailing list