[mythtv-users] Guide updates for CBS and TNT this evening

[Mike Perkins]

On 18/11/15 13:49, Michael T. Dean wrote:
> On 11/17/2015 02:55 PM, Robert Eden wrote:
>> On 11/17/2015 1:38 PM, R. G. Newbury wrote:
>>> The grabber time settings are on the last (eighth) sub-page of the GENERAL pages of mythtv-setup.
>>> The user enters the name of the grabber program or script, and can either set the start and end
>>> times for the grabber 'window', or select to let the system use the time suggested by mythtv.
>>>
>>> A screen-shot is annexed, but I think it will get stripped from the list publication.
>>
>> Geoff, I saw your pic.. it made it to the list.
>>
>> What happens if the suggested time is outside the 1 hour window you have configured?
>
> If "Run guide data program at time suggested by the grabber" is enabled, MythTV completely ignores
> the specified "Guide data program execution start" and "Guide data program execution end" (run
> window).  Ideally in the setup screen, the start/end window options would be grayed out or hidden
> when suggested time is enabled, but setup hasn't gotten much love for years.
>
>> The MythTV "bug" occurs when the download doesn't occur normally. The nightly cleanup code (at
>> 2am) says "hey I haven't downloaded data recently" and does it. *Everyone* has 2:00am for the
>> nightly cleanup job.
>
> The MythTV "housekeeper" is started immediately upon mythbackend startup and checks every 5 minutes
> whether jobs (including a run of mythfilldatabase) should be executed.  The mythfilldatabase run is
> set as a daily task (for the master backend, only), so if--at the time the check is performed--it
> has been at least 24 hours since the last successful run of the job, the housekeeper will run the
> job (if there was an unsuccessful attempt to run it, it's identical to it not having been run,
> however the housekeeper will not run the job again if the "unsuccessful--or not yet successful--job
> is still running--meaning if it takes longer than 5mins, MythTV won't start it again).  There is no
> code in MythTV for a 2am nightly cleanup job.  The closest thing is probably the fact that a daily
> job will be forced to run within 30 minutes before midnight if it has not yet run that day.
>
> Even a brand new install of MythTV with all default values should randomize mythfilldatabase runs
> sufficiently.  MythTV, by default, is set to automatically update program listings at the time
> suggested by the grabber.  Even if a user disables the option to run at the time suggested by the
> grabber, the default values for the guide data program execution start/end are 0/23 (meaning it is
> allowed to occur at any time during the day).  So, to get a 2am spike, the user would have to
> explicitly disable running at the time suggested by the grabber and explicitly set an execution
> window starting at 2--but even then, the spike wouldn't be exactly at 2:00, but would be "spread
> out" within a 5-minute window of 2:00-2:05. However, if the user disabled the option to
> automatically update program listings (i.e. disabled mythbackend's running mythfilldatabase), they
> could run it at whatever time they chose.
>
> So, I would say that the 2am spike is due to people/distros misconfiguring systems and disabling
> "Automatically update program listings" and scheduling a cron job to run at 2am.  I don't know if
> some (or most? or all?) distros tend to set up their crontabs so that /etc/cron.daily/ jobs are run
> at 2am, but if so, perhaps some distro(s) is throwing a script to run mythfilldatabase (or to run it
> if the script thinks it hasn't been run recently--meaning that the distro doesn't trust mythbackend
> to do the job right) in /etc/cron.daily/.  Regardless, since there's no magic 2am time in any of
> MythTV, whatever causes the spike is outside of MythTV--at least outside of
> https://github.com/MythTV/mythtv/tree/master/mythtv (meaning some distros may be putting in some 2am
> hard-coded time in a patch, but I don't know of any, and don't see any in
> https://github.com/MythTV/packaging ).
>
As an aside to this, I sometimes hit the reverse problem. I'm in the UK, and my window is set 14:00 
to 17:00. I have no cron job set. This slot is during the afternoon and when I often have time to do 
maintenance.

So I have taken the master backend down to do some reconfiguring, say a re-scan of the DVB 
multiplexes, and when I restart the backend in order to run mythfilldatabase I discover that the 
backend also schedules a MFDB run, even though one is already going.

Is there any logic which tests to see if MFDB is already running, before the backend starts one off?

-- 

Mike Perkins