[mythtv-users] Running mythfilldatabase while recording

[f-myth-users at media.mit.edu]

    > Date: Sun, 8 Apr 2007 12:23:24 -0400
    > From: Chris Pinkham <cpinkham at bc2va.org>

    > * On Sun Apr 08, 2007 at 08:52:47AM -0400, Michael T. Dean wrote:
    > > On 04/08/2007 01:45 AM, Bruce Markey wrote:
    > > > Writing recordings should only take a small fraction of the
    > > > I/O throughput. However, data is arriving at a steady pace
    > > > and it can not afford to fall too far behind due to latency.
    > > 
    > > Again, this will be fixed by the housekeeper changes Chris Pinkham and I 
    > > have discussed.  The housekeeper will be modified to run mfdb only when 
    > > there's "enough" time before the next recording,

I'm guessing that "enough" is defined as a value somewhere in the
database?  Even if there's no UI for adjusting this, I can certainly
see that individual setups would could probably need very different
times for this.  (A -really- fancy method would be adaptive---keep
track of today's elapsed time, then assume tomorrow's might take up to
20% longer.  This might be adaptive enough, while also being simple enough.)

(Is there any sort of spec for the planned changes, or is it just in
your head?  A spec might answer questions without having to guess and
guessing wrong... :)

    > >						       unless it would mean 
    > > missing the window during which mfdb is allowed to run.

I'm a little uncomfortable about this.  I currently run mfdb from a
cronjob, (a) because I'm running a release that's too old to take DD's
hints, and (b) because that way I can be very sure it won't run during
a recording.  (I have a window for a few hours after local dawn when
the chances of a recording are quite slim, and since I know when mfdb
will run, I can manually schedule around it if necessary---which I
haven't had to do yet.)  OTOH, if DD's suggestions are evenly spread
across the clock (are they?), there's at least a 75% chance that I'll
try to run mfdb during a recording unless the "window" of allowed
runtimes is almost a whole day.  That's problematic:  I would disable
any such functionality and continue with a cronjob to avoid it.

Unfortunately, the solution I see is a more-complicated algorithm.
A first stab might be:
o  If our DD hint wants us to run now, and there isn't a recording
   "soon", just run now.
o  If there's a recording "soon" or currently in progress, then every
   time a recording ends, check to see if we're currently in a gap
   with no recordings scheduled for "long enough" (see the "enough"
   stuff above).  If we're not in a gap, punt & wait for the next
   recording to end.  If we -are- in a gap, pad the "enough" value by
   20% (see adaptive "enough" above), compute the interval between
   "now" and the latest we could start running mfdb without running
   into the next recording, pick a random time in that interval, and
   (try to) run then.  (The idea is not to force runs to all start
   exactly at the top of the hour.)  By "(try to) run then" what I
   -really- mean is "check that we're not currently recording and do
   mfdb", as we do at top of the loop---if we don't check, we could
   still screw up because the user might have used the UI to add a
   brand-new scheduled recording (which we didn't know about when the
   previous one ended) which falls into our gap---we wouldn't want to
   run then.  This is hopefully rare, but last-minute scheduling
   -does- happen and it would be a shame for mfdb to ruin it if it
   could avoid it with another line of code.

This sounds complicated, but my guess is it's half a dozen extra LOC.

Note that it's somewhat less deferential to DD's wishes than your
method -per user- (e.g., mfdb might wind up running hours after the
recommended window), but integrated -across all users- it's probably
pretty good.  It will tend to keep mfdb from running during primetime
in any given timezone, but you have to avoid that anyway if mfdb can
glitch recordings---and it still might run anytime there's a half-hour
window when the user isn't recording...

    > I made another note on my TODO about nicing mfdb in the housekeeper, so
    > if you want to put that in the patch you (are working|will work) on,
    > then that would be good also. :)

I'm not sure, but I think we've seen reports that even nicing mfdb
still leads to disruptions in ongoing recordings, so it may be
important that it never run during one.  (Even ionice, if available
in that particular OS, may not be enough---I'm not sure if the issue
might be sheer disk I/O, or locked tables which can (still?) hang some
types of captures (even if they don't necessarily hang ivtv).)