mythfilldatabase running on suggested time even though disabled

[jan@…]

I have setup mythtv to not use the time suggested by the grabber to run mythfilldatabase. mythfilldatabase is still updating MythFillSuggestedRunTime? with the last start time of the script. That behavior alone is at least debateable if I disabled suggested run times. I know this is not a time suggested by the grabber, but still. And even more important, this time might outside of MythFillMinHour? and MythFillMaxHour? which is clearly a bug.

[stuartm]

If the time is outside the min/max then it won't run, it waits until the window opens to run. Running once every 24 hours is the normal behavior and we're just using MythFillSuggestedRunTime? to indicate to other code when the next run will occur.

[jan@…]

But this behavior breaks the use case where you start the backend daily at the time you scheduled mythfilldatabase. If this doesn't run then, the backend will go back into sleep and you won't get progam updates for at least 24 hours. If you happen to have the backend running when the updates starts, the program updates may interfere running recordings (due to changed programs, massive IO during rescheduling, or not picking up last-minute updates for prime time).

[stuartm]

No, in fact it does the opposite. The change was made so that the backend will automatically wake up at the time the grabber is configured to next run so that you _will_ get guide data updated daily. You just have to configure the backend to shutdown/wakeup properly using the internal settings and not third party scripts.

[jan@…]

I haven't see this configuration change, I'll look for it. But this change still makes it impossible now to force the program update into a certain timespan. I always get drops now during prime time recordings because the grabber decided to run too late, and I don't catch changes for prime time either. Sometimes humans are luckily still smarter in picking the right time to do the right thing than scripts :)

[stuartm]

The grabber will always run on a predictable 24 hour cycle. The first run determines when it will be run in future. You can also use the min/max window to constrain the execution to a particular time of day.

[Jan Schneider <jan@…>]

Only that those contraints do not work. Or maybe they don't work as expected. Here are my relevant settings:

MythFillDatabaseArgs?: -v xmltv --syslog local7 -- --days 20 mythfilldatabaseLastRunEnd: 2014-12-11T19:50:34Z mythfilldatabaseLastRunStart: 2014-12-11T18:50:26Z MythFillGrabberSuggestsTime?: 0 MythFillMaxHour?: 19 MythFillMinHour?: 17

Now, reviewing these settings again, I think I may have found the culprit: any chance that the contraints now have to be specified in UTC instead of local time? Besides that the settings should have been converted when switching to all-things-UTC a while ago, I still thing using UTC doesn't make any sense here. IMO the setting only makes sense to schedule the update for less crowded times. Be it crowded times on the EPG providers backends or crowded times in front of the TV when you don't want to lose WAF or CAF from EPG update interruptions. And then there's of course still the reasoning from above, having the schedule updated before prime time starts. But for any of those scenarios, UTC doesn't make any sense, only local time makes sense. And local time will change due to DST if these values are specified in UTC.