[mythtv-commits] Ticket #11399: EIT scanner causes unnecessary reschedules and prevents idle shutdown

[MythTV]

#11399: EIT scanner causes unnecessary reschedules and prevents idle shutdown
-----------------------------------+----------------------------
 Reporter:  Roger James <roger@…>  |          Owner:  stuarta
     Type:  Patch - Bug Fix        |         Status:  new
 Priority:  minor                  |      Milestone:  0.26.1
Component:  MythTV - EIT           |        Version:  0.26-fixes
 Severity:  medium                 |     Resolution:
 Keywords:  eit idle               |  Ticket locked:  0
-----------------------------------+----------------------------

Comment (by dekarl@…):

 In the past I have successfully setup a backend with idle shutdown and EIT
 scanning by tweaking the timeouts for
 a. idle time between recordings that prohibits shutdown
 b. idle time before starting the EIT scan
 c. and the idle time after which the backend shuts down
 by setting a > b > c the backend would scan EIT between recordings but
 shut down when the time until the next recording exceeded c. But I was not
 really satisfied with the result. The real question is, why does a
 reschedule reset the idle timer. (I remember a change where it would not
 reset the timer but bump it up to a minimum value of a minute or so to let
 the reschedule finish)

 Now on to the patch.

 According to ETR 211 4.1.4.2.1 L) "segments that correspond to events in
 the past '''may''' be replaced by empty segments" which is in contrast to
 "The tables do not overlap."

 After reading ETR 211 and EN 300 468 it is my understanding that the
 version_number is per sub-table. With the EIT sub-table being identified
 by table_id + service_id. (aka table_id_extension, signaled by
 section_syntax_indicator being 1)

 As the service_id (by looking up the corresponding chanid) is used as part
 of the key we can leave that out and restrict the value to table_id +
 version_number.

 As the table_id of an event only changes once every 4 days but the segment
 it is in changes every 24 hours, thus changing the version_number, we can
 leave it (the table_id) out of the value. (3 hours per segment of 8
 sections with 256 sections per table_id => 256/8*3 hours of guide per
 table_id)

 Thus I do think you can safely re-purpose the table_id field of the EIT
 Cache. The field should be renamed in a database update in master.

 As the event_map is per channel it should be safe to leave out the
 table_id/table_id_extension there, too.

 Up to here the changes appear to be safe, but I'm having a hard time
 identifying the benefit.

 What I can identify is the comparison of events against recording rules
 when they are the following or present event. That should avoid lots of
 reschedules. I have gone a similar way by ignoring updates to
 present/following for other transports, but I like your solution better.

 If we can find a way to update the guide with present/following
 information but avoid reschedules when there is no matching rules, that
 would be perfect.

 See [c99b2967] and [b7bab70a] for my attempts to avoid needless
 reschedules. I'd like to backport them to fixes/0.26 but would prefer if
 someone can verify they don't break anything.

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