[mythtv-users] Running mythfilldatabase while recording

Michael T. Dean mtdean at thirdcontact.com
Sun Apr 15 17:27:37 UTC 2007


On 04/15/2007 03:21 AM, f-myth-users at media.mit.edu wrote:
>     > 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.)
>   

At first, at least, "enough" is going to be a very conservative estimate 
of enough--even for people using dial-up with a screen scraper (which 
will be overkill for DD users).  I'm not planning to make a 
configuration setting (if someone really needs to modify it, they can 
always change the code, but I doubt it will ever be necessary) although 
I may store some of the settings in the DB.

> (Is there any sort of spec for the planned changes, or is it just in
> your head?

In my head, now.  In the not-too-distant future (I hope), in code.

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

So, this change won't affect you, anyway.  ;)

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

The critical piece you're missing is that the window I'm talking about 
is the user-defined window ("mythfilldatabase Execution Start" and 
"mythfilldatabase Execution End"), /not/ the DD "window" (they don't 
actually have a "window", they suggest a time and--as long as we update 
at some point after that time--I think they're happy).

In the case of NA users, however, this will never be an issue because of 
http://svn.mythtv.org/trac/ticket/3302 (looks like we'll be ignoring 
"mythfilldatabase Execution Start" and "mythfilldatabase Execution End" 
for users who enable the suggested next time feature.  That means that 
we'll be able to run mfdb at any time of day, so it will always run when 
there are no recordings occurring.

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

Again, it's the user's desires that I'm respecting, not DD's.

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

But, it shouldn't hurt--especially in light of the above.  :)

Mike


More information about the mythtv-users mailing list