[mythtv] Ticket #2194: Patch to randomise mythfilldatabase times
Michael T. Dean
mtdean at thirdcontact.com
Fri Sep 15 17:56:26 UTC 2006
On 09/15/06 03:34, William Uther wrote:
>I was after an effect that was something like "grab once per day, at
>a random time".
>
Why do we need a random time on a micro-scale (i.e. per user)? Why not
just ensure that it doesn't run at the same time every day for an
individual user, so that different users are much less likely to run it
at the same time? We could easily do this by just adding some value
greater than 10 minutes to the lastrun value for the tag MythFillDB.
Then, it will run the next time the housekeeper runs within 10 minutes
of that time + period. And, this doesn't lead to running more than once
per period or require significant amounts of new logic to determine
whether or not to run. And since wantToRun() is used for far more than
just running mythfilldatabase (i.e. for LogClean, JobQueueCleanup,
InUseProgramsCleanup, JobQueueRecover, and probably more in the future
(as some of mythfilldatabase's cleanup functionality is moved to
housekeeping)), we don't end up randomizing things that shouldn't be
randomized.
IIRC, that's basically what used to happend when we (in the US) used
tv_grab_na, but did so because tv_grab_na generally took more than 10
minutes to run. So, the lastrun was always later than the previous
run's lastrun + period. (Does your grabber really complete quickly
enough that there's no "walk" in the times? See
http://www.gossamer-threads.com/lists/mythtv/users/72805#72805 . The
post to which he's responding is irrelevant because it's discussing
development of the suggested run time capability for DataDirect, but the
description of how it worked at that time is applicable.)
This approach would be as easy as adding another updateLastrun() to
housekeeper.cpp that accepts a dbTag name and an offset. Then when
updating the time for MythFillDB, you could specify a random or
non-random offset (i.e. say that tomorrow it should run 15 minutes later
than today--perhaps only specifying an offset if the current time is
within 15 minutes of lastrun + period--i.e. if mythfilldatabase didn't
take more than 15 minutes to run). And, if you really wanted to get
fancy, when it got to the end of the allowable time (i.e. when the
offset would lead to the lastrun time being greater than maxhr), you
could "wrap" back to the minhr with a negative offset. (When it did the
"walking" for me, it would just result in skipping one day due to a
wrap, which wasn't that big a deal, but could easily be fixed with an
offset for updateLastrun().)
>Hrm, maybe between 2 and 5pm... ahh - I remember now: MaxHour is
>inclusive :). And that answers your followup mail :) Although that
>means that the 24 on lines 174 & 178 really should change to 23, as
>should the 24s in programs/mythfrontend/globalsettings.cpp
>
>Or you could fix it so that maxhr is non-inclusive (it was inclusive
>before my patch in the code, but not the preference comments).
>That's probably a better fix.
>
I think it should be left at 0-24. From a user's standpoint, to say
that it should only run between 23:00 and 00:00, it makes a lot more
sense to say 23-24 than to say 23-23 (which sounds like it won't run at
all) or 23-0 (if we make the end time exclusive--this can be confusing
because start is greater than end and the user tends to wonder if date
is taken into account), and it's just not worth telling the user about
inclusivity/exclusivity. Furthermore, it generally just "does the right
thing" since the time will never be 24:00-24:59.
If a user really needs to ensure it only runs between 11:00 and 15:00
(for example), and she specifies 11-15, she'll notice that it eventually
runs at/after 15:00 and either change the value to 11-14 (or ask about
it on the list). But, for as long as I've been using Myth, no one has
asked about it before.
A /very/ long time ago, I thought about making a patch for the
inclusivity of the end time or for the help text, but decided against it
because the help text is actually correct (see the text below) when you
realize that these times are "precise" to one hour increments (now if we
said anything about minutes, I'd agree it needs changed). And, most
importantly, it just doesn't matter to the average user. (And, telling
a user that 11-13 would run between 11 and 2 would just be confusing for
the user).
Mike
mythfilldatabase Execution Start
This setting and the following one define a time period when the
mythfilldatabase process is allowed to run. For example, setting Start
to 11 and End to 13 would mean that the process would only run between
11 AM and 1 PM.
mythfilldatabase Execution End
This setting and the preceding one define a time period when the
mythfilldatabase process is allowed to run. For example, setting Start
to 11 and End to 13 would mean that the process would only run between
11 AM and 1 PM.
More information about the mythtv-dev
mailing list