[mythtv-users] Why modify mfdb start/end with MythFillGrabberSuggestsTime? (was Re: Filldatabase cron job necessary?)

Michael T. Dean mtdean at thirdcontact.com
Mon Apr 16 17:11:09 UTC 2007


On 04/11/2007 08:33 PM, Michael T. Dean wrote:
> On 04/11/2007 08:22 PM, aaron wrote:
>   
>> But anyway, it would be awesome if the housekeeper could figure out it
>> missed the run.
>>     
> The "did we miss a run" logic would be far more than I was suggesting 
...
> however, I can do that, too (or instead if there is some reason for the 
> 2-hour block).
>   

I'm now thinking that the "did we miss a run" logic is unnecessary and 
the simpler, "run mfdb as soon as I'm allowed" approach is better for 
everyone.

> I guess people outside of North America shut down their systems, too.  
> ;)  So, it probably makes sense to put a real fix in there, too.

If the user enables the grabber's suggested next run time option, we now 
allow updates at any time of day (i.e. we don't check min/max hours).  
Therefore, if a run was missed, we will be more than MythFillPeriod from 
last run time, so soon after startup, the housekeeper will run mfdb.

The same applies for users that do not enable the suggested next run 
time option, but who allow updates at any time (i.e. specify 
"mythfilldatabase Execution Start/End" of 0/24 or -1/<anything>).

If the user does not enable the grabber's suggested next run time option 
(i.e. the user is not in North America) and specifies execution 
start/end times (min/max), if a run was missed and we were to run mfdb 
shortly after startup, doing so would throw off the min/max settings the 
user has specified and could cause problems if there were some reason 
(other than convenience) that the user specified the execution times she 
specified.

For example if min/max are 2/4 and the user starts mythbackend at 23-ish 
on Monday, running mfdb immediately would mean that in 3 hours when we 
enter the appropriate mfdb run time for Tuesday, we'll be less than 
MythFillPeriod days from the last run, so mfdb won't run.  The following 
day, Wednesday, mfdb will run between 2:00 and 5:00.  So, that means we 
updated Tuesday (the day that started an hour after startup--mfdb always 
updates tomorrow), but did not update Wednesday.  When mfdb runs on 
Wednesday, it will update Thursday, so Wednesday was never updated.

Or, if the user specifies a min/max that aligns with a time period 
during which bandwidth usage is discounted, running upon startup would 
cost more.  Or, if the user is not allowed access to the Internet during 
specific periods of the day (network security policies or whatever), 
runnning mythfilldatabase and getting nothing would mean we would be 
skipping the next run (due to the issue described above) /and/ wouldn't 
get anything this run, either.

So, North American users who enable "Run mythfilldatabase at time 
suggested by the grabber" or anyone who sets "mythfilldatabase Execution 
Start/End" to 0/24 (or -1/<anything>) would never have to worry about 
missed updates.  We would run at startup and at the next suggested time 
(if enabled) or run just over 24 hours from startup (assuming a 
"mythfilldatabase Run Frequency (Days)" of 1).

Users who do not enable "Run mythfilldatabase at time suggested by the 
grabber" and who specify min/max values have two options.  The first is 
to allow Myth to just run at the allowed time (as it has in the past) 
and not worry about a missed day.  The second is to manually run 
"mythfilldatabase --refresh-second" (this will update tomorrow and the 
day after tomorrow) immediately upon startup (ideally before starting 
mythbackend--in which case the error contacting mythbackend for a 
reschedule should be ignored).  However, in doing this, they should 
temper their desire to have new listings with the bandwidth usage /and/ 
take into account days when they will restart the system multiple times 
(to prevent running and re-running updates of tomorrow and the day 
after).  Due to the complex logic involved in determining whether to 
re-run mythfilldatabase, I /highly/ recommend against this approach.

Probably the best solution, though, is to simply ensure--if you want to 
prevent missed updates--that the master backend is always booted at some 
point during the min/max hours timeframe.  For those using 
mythwelcome/mythshutdown to manage shutdown/reboots, these programs 
would have to be updated to check:

if master backend
    if ! MythFillGrabberSuggestsTime (or if MythFillGrabberSuggestsTime 
but grabber is not DataDirect)
       if MythFillMinHour != -1
          boot time should be between MythFillMinHour and MythFillMaxHour

However--and note I don't use mythshutdown, so this is just a guess--it 
seems that mythwelcome already takes this into account with the daily 
wakeup start and end periods:

Period 1 start time
Defines a period the master backend should be awake
Set both Start & End times to 00:00 to disable.

So, my suggestion is to leave things as they are and simply get the word 
out that if you're not using suggested next run and are using min/max 
hours for mythfilldatabase and shutting your system down, you should 
ensure it's booted during those hours, i.e. using mythwelcome's daily 
wakeup periods.

Mike


More information about the mythtv-users mailing list