[mythtv-commits] Ticket #1728: refactoring dvb eit scanning and eit cache

[MythTV]

#1728: refactoring dvb eit scanning and eit cache
--------------------------------------------+-------------------------------
 Reporter:  Janne <janne-mythtv at grunau.be>  |        Owner:  danielk
     Type:  enhancement                     |       Status:  new    
 Priority:  minor                           |    Milestone:         
Component:  dvb                             |      Version:         
 Severity:  medium                          |   Resolution:         
--------------------------------------------+-------------------------------
Changes (by Janne <janne-mythtv at grunau.be>):

  * summary:  patches for the eit refactoring branch => refactoring dvb eit
              scanning and eit cache

Comment:

 The eit branch is stable after [9918] for me. I'll start with refactoring
 the eit scanning based on following ideas posted by danielk:

 1/ Master backend has a list of all the channels/services being scanned.
 2/ For each transport we have a list of the channels/services which
    it provides EIT information, and this list tells us if now/next
    information is available and if future information is available.
 3/ Each recorder has a transport to scan and a list of channels/services
    for which it collects EIT and a list of channels/services it should
    ignore.
 4/ If a recorder sees EIT for a channel/service which is not on either
    list it requests permission to collect this information from the
    master backend.
 5/ The master backend responds to a request by telling the slave to
    either ignore or collect the EIT info. The logic for which to do
    is simple, if no one else is collecting info on that service then
    allow collection. If someone else is collecting information, but
    they only see current/next and we see future then tell the other
    recorder to ignore that channel/service and give the recorder
    with better information permission to collect the data. Otherwise,
    tell the recorder to ignore the data.
 6/ Anytime a recorder is given permission to collect EIT info on a
    channel/service it loads the cache for that channel/service from
    the DB. When a recorder ends the scan of a channel/service it
    saves the cache and then tells the master backend it is done with
    the channel.
 7/ The permission to collect EIT on a channel/service expires after
    30 minutes. So if a backend dies the master can assign those
    channels to some other recorder to scan. We can cap the time
    spent on any one transport to 25 minutes. If this is a passive
    scan (during a recording) then the recorder just has to save
    the info and stop the scan before 25 minutes are up, or request
    permission to collect the EIT again.
 8/ When a recorder stops collecting EIT on a transport it saves the
    list of channels/services (and whether we have now/next and/or
    future data) available on the transport, and then requests a new
    transport to scan. This allows us to update the lists when cross
    listing information changes.

 The master backend should keep separate sorted lists of the transports
 with EIT on each source (sorted from channel with the most cross-listing
 to the least cross-listing). When a recorder needs a new transport to
 scan we look for first transport on the list which doesn't conflict
 with an in progress recording. If none can be found we look for the
 first transport for which we have seen future information, and for
 which we are only scanning current/next info currently. If we find one
 of these we tell the recorder with that channel/service to quit scanning
 that channel/service, and then assign the transport to the requesting
 recorder. Whenever a transport is assigned we remove it from the list,
 and whenever the list is empty (or no transport can be found to scan
 for a requesting recorder), we reload the list. But if a recorder
 terminates a scan early so that a recording, scheduled or livetv,
 can be started it should be returned to the master backend and
 reinserted into the list.

 We should also keep track of the last time a list was [re]loaded, and
 when a recorder needing a transport to scan has more than one source
 assigned we should prefer the one that was [re]loaded a longer time ago.

 There may be other criteria for the master backend assignments. For
 instance, with DVB-S with a rotor we would probably want to prefer
 transports on the same satellite as the last channel on that recorder.
 So I'm not terribly concerned with getting the master backend
 transport scheduling correct right now. I'm more concerned that we
 get the protocol right so that only one scanner collects EIT on
 any one channel/service at a time we collect as much information
 as possible, with as little communication as possible.

-- 
Ticket URL: <http://cvs.mythtv.org/trac/ticket/1728>
MythTV <http://www.mythtv.org/>
MythTV