On 04/11/2007 05:58 PM, aaron wrote:
> On 11/04/07, Michael T. Dean <mtdean@thirdcontact.com> wrote:
>
>> In North America, though, you should not use a cron job so you can take
>> advantage of the recommended next run time.
> The only issue here is if using the nvram wakeup stuff (or however you
> want to call it... where the backend shuts off and turns itself back
> on in time for the next recording). It doesn't take the recommended
> filldb time into account, so I've had occasion where the run gets
> missed several days in a row and I have to run it manually.
>
> Perhaps I have something screwed up in my configuration, but to
> compensate I recently added a cron job that fires once an hour and
> compares the current time to the "recommened next run" time and if it
> has passed it forces a filldb run.
Yeah. For some reason, when you enable "Run mythfilldatabase at time
suggested by the grabber," mythfilldatabase sets the "mythfilldatabase
Execution Start" to the hour during which the suggested next run time
occurs and the "mythfilldatabase Execution End" to a time 2 hours after
the new "mythfilldatabase Execution Start". So, for those several days,
you had your system shut down during that 2 hour period...
I have no idea why it does this. Even in Robert Kulagowski's original
code ( http://svn.mythtv.org/trac/changeset/8105 and
http://svn.mythtv.org/trac/changeset/8218 ), the housekeeper checked to
see if the suggested time was before now, so we wouldn't accidentally
run it twice in one day even with start/end of 0/24.
For example, my current next suggested run time is "2007-04-12 17:30".
So let's say mfdb runs tomorrow (the 12th) at 17:30-ish and gets a new
suggested run time of "2007-04-13 19:30". If after mfdb updates the
start/end times, I change my MythFillMinHour to -1 (start/end of 0/24),
then when the housekeeper does its checks around 19:30 on the 12th, it
will see that the grabber supports next time, will get the suggested run
time, and will not try to run mythfilldatabase because nextRun > now.
On the 13th, though, it would successfully run mfdb sometime after
19:30. And, if we leave the start/end times (for 0/24), users who shut
down during that time period will get updates shortly after a restart.
I'm thinking modifying the start/end times may have been an "initial
implementation" that should have been removed once Robert put the
nextRun < now check in the housekeeper (and it would be easy to forget
to remove something small like that--that generally works--because there
was a /lot/ of code required to add the suggested next run functionality).
So, any input Robert or Chris Pinkham (who committed the changes)? I'll
gladly make a patch to allow people who shut down their boxes to receive
updates soon after startup if a run was missed.
I had noticed this before, but since I run my box 24/7/52 (there are
only 52 weeks in a year--one day I'll convince the world I'm right ;),
it doesn't affect me. So, I didn't think it was worth asking about.
However, now that someone else has brought it up... ;)
Thanks,
Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
> On 11/04/07, Michael T. Dean <mtdean@thirdcontact.com> wrote:
>
>> In North America, though, you should not use a cron job so you can take
>> advantage of the recommended next run time.
> The only issue here is if using the nvram wakeup stuff (or however you
> want to call it... where the backend shuts off and turns itself back
> on in time for the next recording). It doesn't take the recommended
> filldb time into account, so I've had occasion where the run gets
> missed several days in a row and I have to run it manually.
>
> Perhaps I have something screwed up in my configuration, but to
> compensate I recently added a cron job that fires once an hour and
> compares the current time to the "recommened next run" time and if it
> has passed it forces a filldb run.
Yeah. For some reason, when you enable "Run mythfilldatabase at time
suggested by the grabber," mythfilldatabase sets the "mythfilldatabase
Execution Start" to the hour during which the suggested next run time
occurs and the "mythfilldatabase Execution End" to a time 2 hours after
the new "mythfilldatabase Execution Start". So, for those several days,
you had your system shut down during that 2 hour period...
I have no idea why it does this. Even in Robert Kulagowski's original
code ( http://svn.mythtv.org/trac/changeset/8105 and
http://svn.mythtv.org/trac/changeset/8218 ), the housekeeper checked to
see if the suggested time was before now, so we wouldn't accidentally
run it twice in one day even with start/end of 0/24.
For example, my current next suggested run time is "2007-04-12 17:30".
So let's say mfdb runs tomorrow (the 12th) at 17:30-ish and gets a new
suggested run time of "2007-04-13 19:30". If after mfdb updates the
start/end times, I change my MythFillMinHour to -1 (start/end of 0/24),
then when the housekeeper does its checks around 19:30 on the 12th, it
will see that the grabber supports next time, will get the suggested run
time, and will not try to run mythfilldatabase because nextRun > now.
On the 13th, though, it would successfully run mfdb sometime after
19:30. And, if we leave the start/end times (for 0/24), users who shut
down during that time period will get updates shortly after a restart.
I'm thinking modifying the start/end times may have been an "initial
implementation" that should have been removed once Robert put the
nextRun < now check in the housekeeper (and it would be easy to forget
to remove something small like that--that generally works--because there
was a /lot/ of code required to add the suggested next run functionality).
So, any input Robert or Chris Pinkham (who committed the changes)? I'll
gladly make a patch to allow people who shut down their boxes to receive
updates soon after startup if a run was missed.
I had noticed this before, but since I run my box 24/7/52 (there are
only 52 weeks in a year--one day I'll convince the world I'm right ;),
it doesn't affect me. So, I didn't think it was worth asking about.
However, now that someone else has brought it up... ;)
Thanks,
Mike
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users