[mythtv-users] scheduler doesn't run ?

[Per Jessen]

Michael T. Dean wrote:

> On 01/14/2016 03:04 AM, Per Jessen wrote:
>> Michael T. Dean wrote:
>>
>>> On 01/13/2016 02:30 PM, Jonatan Lindblad wrote:
>>>> Den 2016-01-13 kl. 14:24, skrev Per Jessen:
>>>>> Michael T. Dean wrote:
>>>>>
>>>>>> Usually if the scheduler isn't scheduling properly, it means
>>>>>> there's a problem with one or more of your (almost definitely
>>>>>> custom) recording
>>>>>> rules--usually resulting in a SQL issue.  If you have any custom
>>>>>> rules, you may want to write down the details (so you could
>>>>>> recreate
>>>>>> them) and then delete them and see if things work properly.  If so,
>>>>>> start adding them back one by one until you find the culprit.
>>>>> I have 77 custom rules, most from October 2015 or older - only two
>>>>> new ones:
>>>>>
>>>>> program.title like '%Walking%dead%'
>>>>> program.title like '%Endeavour%'
>>>>>
>>>>> I did have a double for #1, but deleting it didn't do much.
>>>>>
>>>>> Can I unload/reloead table 'record' or will that screw up things?
>>>>> I have some 440 rules, I'd hate to try to recreate those :-(
>>>> 440 rules sounds like it could use an awful lot of memory so make
>>>> sure you have enough temporary disk space.
>>>>
>> http://lists.mythtv.org/pipermail/mythtv-users/2011-December/325302.html
>>> Great suggestion.  Those 2 new rules look fine, so it may well be
>>> something else (such as MySQL memory/connection issues).  (Look also
>>> at whether your MySQL is configured to allow sufficient
>>> connections--this has been an issue in the past, and can result in
>>> symptoms like you describe, where everything appears to work, but the
>>> scheduling doesn't and/or doesn't reliably.)
>> Max mysql clients is 151, the default I believe. Currently 28 active
>> connections from the master plus one slave.
>> mysql is using /var/tmp and there is about 10Gb of available space.
>>
>> I'm slowly getting the feeling it's somehow related to these messages:
>>
>> Scheduled 629 items in 1764.2 = 1752.96 match + 11.25 place
>> Scheduled 643 items in 164.1 = 155.02 match + 9.06 place
>> Scheduled 643 items in 916.3 = 904.87 match + 11.45 place
>>
>> Judging by the code, this is about how much was scheduled and how long
>> it took.  I took a look at those messages in the logs (back to 31/10, I
>> only keep the logs for so long).
>>
>> http://files.jessen.ch/mythtv-items-scheduled-since-20151031a.jpeg
>>
>> It seems to have been fairly steady, with a rise since December. It's
>> gone from around 600 items to more than 800.
>>
>> This is the interesting one though:
>> http://files.jessen.ch/mythtv-time-to-schedule-since-20151031a.jpeg
>>
>> Very stable until last week of November, then mayhem as of December.
>>
>> It looks like it used to take 60 seconds, since December up to an hour
>> or more - if it takes too long to run a reschedule, might this upset
>> the overall scheduling?
> 
> Yep.  That's your problem.  It's not that scheduling isn't running, it's
> that it's taking so long to run that you're not noticing the changes.

Well, today the last completed scheduling was at 16:03:45, about 5 hours 
ago:

Scheduled 717 items in 315.1 = 304.44 match + 10.64 place

Since then nothing but "sleeping for 30000 ms".  Just now my wife added a 
couple of recording rules, nothing changed.  I ran a "/usr/bin/mythbackend 
--resched", no change.  According to the database there is no long running 
query, so scheduling just isn't running.  What's keeping it back?


/Per