[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 

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).


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