[mythtv-commits] Ticket #13072: Schedule busy looping with sched_sleep of 0

[MythTV]

#13072: Schedule busy looping with sched_sleep of 0
----------------------------------+--------------------------------
 Reporter:  lucylangthorne55@…    |          Owner:  gigem
     Type:  Bug Report - General  |         Status:  infoneeded_new
 Priority:  minor                 |      Milestone:  unknown
Component:  MythTV - Scheduling   |        Version:  0.28.0
 Severity:  medium                |     Resolution:
 Keywords:                        |  Ticket locked:  0
----------------------------------+--------------------------------

Comment (by lucylangthorne55@…):

 Thanks for getting back.

 Yes I had added some debug to try to determine the problem, sorry I hadn't
 made it clear.

 So I was logging the secs2next etc at 2031, just above the if(sched_sleep)
 check for sleeping since there was no logging for why it was looping.

 I ended up disabling the slave for the moment.

 I'm thinking that since scheduled run time in my example log file is 122
 that maybe what happens is that normally my reschedules are fast (<3s) but
 sometimes I get a reschedule that takes a very long time (60s+, sometimes
 several minutes), possibly because of the number of rules I have that
 match against description, maybe because slave connects/disconnects.

 So, perhaps for most people we get "scheduled run time takes 2s", hence
 the busy loop is very fast since we often sleep until very near (within a
 couple of seconds of the start of the next programme), whereas for me
 sometimes it will say that scheduler run time could take three minutes so
 it busy loops for those three minutes, which then causes knock-on effects.

 Now that I look at the code more, the schedRunTime is always the absolute
 max, rather than a "recent" max so that suggests that if a schedule takes
 three minutes at any point in the day then we assume all future schedules
 also take three minutes, so then we go around the loop, say we can't
 reschedule because it would take too long and nothing is due to start
 within 30s, and then busy loop for 2.5 minutes doing the same checks.

 So all we need is for a reschedule to happen with three minutes of the
 start of the next programme for us to enter the busy looping, e.g., I
 think OTA EIT causes a reschedule every few minutes.

 I've never managed to track down why a reschedule sometimes takes a long
 time with the same rule queries (even with a separate drive) sometimes
 being immediate and sometimes a couple of seconds, figuring it might be
 due to concurrent OTA EIT updates.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/13072#comment:2>
MythTV <http://www.mythtv.org>
MythTV Media Center