[mythtv] Ticket #2194: Patch to randomise mythfilldatabase times
mythtv-dev at hyperbole-software.com
Sat Sep 16 20:37:44 UTC 2006
William Uther wrote:
>On 15/09/2006, at 2:55 PM, MythTV wrote:
>>#2194: Patch to randomise mythfilldatabase times
>> Reporter: willu.mailingLists at cse.unsw.edu.au | Owner:
>> Type: enhancement | Status: new
>> Priority: minor | Milestone: 0.21
>>Component: mythtv | Version: head
>> Severity: medium | Resolution:
>>Comment (by cpinkham):
>> Doesn't this patch have the adverse side effect that jobs we want
>> once a day could potentially run every 12 hours because of the
>> longEnough = ((period * oneday) - oneday/2);
>Yes. It does have that side-effect. This is because the old logic
>was "don't run more frequently than every 24 hours", NOT "run once
>per calendar day".
>I was after an effect that was something like "grab once per day, at
>a random time". If I left the old logic, then when the system
>grabbed late one day it would be forced to grab late the next day too
>(else it would have grabbed more than once in 24 contiguous hours).
>The only way it could get back to grabbing early would be to ratchet
>back in 5 minute intervals, or skip a day entirely.
>I decided that I did't want to fill the database too frequently, so I
>allow it to ratchet back in 12 hour increments rather than 5 minute
>increments. You could adjust that 6 hour increments if you want.
>I'd suggest leaving it as 12 hours - it isn't going to ratchet back
>easily because of the random delays.
>There is another issue that I thought about after submitting the
>patch... the patch currently assumes that your machine is running all
>the time. I haven't played with the auto shutdown-startup stuff in
>myth. It might not play nice with this patch.
>> That alone would be a bad thing, but is probably prevented by what
>> to be flawed logic in the random time check:
>> ((random()%((maxhour-minhour+1)*6)) == 0)
>> So if maxhour is 24 and minhour is 0, then you're checking if the
>> number is evenly divisible by (24 - 0 + 1) * 6 which works out to
>> Those would seem to be very very low odds which would mean we'd
>> running in the last half hour of our window when the "(hour ==
>> minute > 30)" check kicked in. Doesn't seem very randomized.
>Myth is making that check every 5 minutes. So in your example you
>have 24*12 = 288 chances to succeed, each of which, individually, has
>probability 1/150. The probability you don't run at all is (149/150)
>^288 = 0.15. So you are right in that it is slightly biased.
>Exactly how biased depends upon the range of time you give it to run.
>The probability currently isn't uniform because I didn't think it was
>worth the hassle. If you want to make it uniform then you need to
>make the probability 1/(# remaining chances to run today) as opposed
>to the current probability of 2/(# total chances to run today).
>I think this does it:
>((random()%((maxhour-hour)*12 + (60-minute)/5 - 6) == 0))
>(maxhour-hour)*12 = the number of attempts in the remaining full hours
>(60-minute)/5 = the number of attempts in the remaining partial hour
>- 6 = we don't want to include the last 30 minutes where a run is forced
>Of course, I've tested the other code, whereas I haven't tested
>this. Although the new formula plays more nicely with the auto-
>shutdown/wakeup stuff, in that if you wake up half-way through the
>"ok period" then you have boosted chance of running.
>> Can you check the logs to see when your mythfilldatabase runs were
>> actually occuring to show this is really random and not semi-
>> mostly in the last 30 minutes of the window?
>I checked this before posting the patch. But here is the data from
>my current logs. I set my grabber to run between 2 and 4 pm daily.
>% grep "mythbackend: Running mythfilldatabase" *
>mythbackend.log:2006-09-15 15:00:36.423 mythbackend: Running
>mythbackend.log.1:2006-09-14 16:04:14.974 mythbackend: Running
>mythbackend.log.10:2006-09-05 16:34:44.054 mythbackend: Running
>mythbackend.log.11:2006-09-04 16:32:59.660 mythbackend: Running
>mythbackend.log.12:2006-09-03 15:44:55.887 mythbackend: Running
>mythbackend.log.13:2006-09-02 14:42:09.719 mythbackend: Running
>mythbackend.log.14:2006-09-01 14:05:05.174 mythbackend: Running
>mythbackend.log.2:2006-09-13 14:56:30.569 mythbackend: Running
>mythbackend.log.3:2006-09-12 14:13:42.043 mythbackend: Running
>mythbackend.log.4:2006-09-11 14:31:46.024 mythbackend: Running
>mythbackend.log.5:2006-09-10 15:22:02.131 mythbackend: Running
>mythbackend.log.6:2006-09-09 14:04:50.952 mythbackend: Running
>mythbackend.log.7:2006-09-08 15:19:28.773 mythbackend: Running
>mythbackend.log.8:2006-09-07 14:26:42.468 mythbackend: Running
>mythbackend.log.9:2006-09-06 15:10:30.554 mythbackend: Running
>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.
>So here is the complete set of fixes - same as before but with a
>uniform distribution and non-inclusive max hour.
>--- housekeeper.cpp (revision 10995)
>+++ housekeeper.cpp (working copy)
>@@ -48,7 +48,7 @@
> unsigned int longEnough = 0;
> if (period)
>- longEnough = ((period * oneday) - 600);
>+ longEnough = ((period * oneday) - oneday/2);
> longEnough = oneday / 8;
>@@ -70,8 +70,13 @@
> if ((now.toTime_t() - lastrun.toTime_t()) > longEnough)
> int hour = now.toString(QString("h")).toInt();
>- if ((hour >= minhour) && (hour <= maxhour))
>- runOK = true;
>+ if ((hour >= minhour) && (hour < maxhour))
>+ int minute = now.toString(QString("m")).toInt();
>+ if ((hour == maxhour-1 && minute > 30)
>+ || ((random()%((maxhour-hour-1)*12+(60-
>minute)/5 - 6) == 0))
>+ runOK = true;
>@@ -202,7 +207,7 @@
> if ((nextRun < now) &&
> (lastRun.secsTo(now) > (3 * 60 * 60)) &&
>- ((minhr <= hour) && (hour <= maxhr)))
>+ ((minhr <= hour) && (hour < maxhr)))
> runMythFill = true;
> else if (wantToRun("MythFillDB", period, minhr,
>@@ -241,7 +246,7 @@
>+ sleep(300 + (random()%8));
>But that is totally untested.
>Dr William Uther National ICT Australia
>Phone: +61 2 8306 0424 Computer Science and Engineering
>Email: william.uther at nicta.com.au University of New South Wales
>Email: willu at cse.unsw.edu.au Sydney, Australia
>Web: http://www.cse.unsw.edu.au/~willu/ or http://www.nicta.com.au/
>NICTA email Disclaimer:
>UNSW email Disclaimer:
>mythtv-dev mailing list
>mythtv-dev at mythtv.org
I thought randomization of the request was taken care of by use of the
acknowledge function which requests from DataDirect a time to make the
Am I wrong about that?
More information about the mythtv-dev