[mythtv] Ticket #2194: Patch to randomise mythfilldatabase times

Bruce Markey bjm at lvcm.com
Fri Sep 15 20:32:17 UTC 2006


Chris Pinkham wrote:
> We don't want to take the chance on doubling the amount of data
> downloaded each day though, and if you set longEnough to 12 hours
> then we could be downloading every 12-24 hours so we're somewhere
> between 1-2 times per day average.  I think this is easily resolved
> though, so it's not a big issue.  If period is 1 then we just need
> to check to see if we've already downloaded on today's calendar day,
> otherwise we don't 'want to run'.  Your mod to wantToRun affects all
> jobs that the housekeeper runs, so any job we want to only run once
> a day could have the potential of running twice a day with your
> current changes.  This probably isn't a big deal with the other current
> things the housekeeper does, but it negates the effect of setting
> period = 1 and could have negative impacts for future additions to
> the housekeeper.
> 
> The current code works fine in your case where you limit the hours a
> task can run, but there are other builtin tasks where you can't edit
> the min/max.  They are hardcoded at 0/24 and some users may have their
> mythfilldatabase min/max set to 0/24 as well.

It seems to me that, regardless of the min/max hours, it should
grab once during the period specified by the user. TMS has said
they only do one big update per day so it wouldn't necessarily
be wise for the user to set 0-23.

A "day" for a user may not be the same as a "day" for TMS in
Chicago (CST/CDT) and it is unclear exactly when they do their
daily update. One thing we could do is to not allow the automatic
mfdb between 12am-4am Central regardless of the user's min or
timezone (Oh, DD only. not xmltv =).

Also, I believe that TMS suffers from the 'Cinderella effect'
(if all your cron jobs are set to 0 0, you're computer will turn
into a pumpkin at the stroke of midnight). They are bombarded at
the top of each hour. During the Olympic fiasco, it appeared that
they were looking only at hourly stats and didn't see that they
were screwed in the first few minutes of their peak hours. You can
verify this by staying up late some night and doing grabs a few
minutes before the hour than again a few minutes after.

If we are going to generate random times, they should exclude :55
through :10. Better for the user and better for TMS.

Also, it might be nice for just mfdb to not run while the master is
recording. If so, postpone until the system is quiet. If the system
is scheduled to be busy for the remainder of the interval, then run
mfdb anyway.

Just my $.02.

--  bjm




More information about the mythtv-dev mailing list