[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