[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 Roger James <roger@…>):

 Guys,


 Firstly I agree with what dekarl says. It is easy to split my current
 patch in the two parts. Virtually all the DVB heavy optimization stuff is
 confined to eitcache.cpp. If you just leave in there the bit that checks
 changes to endtime and returns a flag, then all the rest is about reducing
 the number of reschedules, which does fix the breakage!

 Any way back to the heavy DVB stuff.

 I think I will have to nail my colours to mast and defend my
 interpretation.


 This is going to sound horribly preachy, sorry.

 Here is what EN300468 section 5.1.1 says about version numbers


 {{{
 d)
 version_number:
 When the characteristics of the TS described in the SI given in the
 present document change
 (e.g. new events start, different composition of elementary streams for a
 given service),
 then new SI data shall be sent containing the updated information. A new
 version of the
 SI data is signalled by sending a sub_table with the same identifiers as
 the previous
 sub_table containing the relevant data, but with the next value of
 version_number.
 For the SI tables specified in the present document, the version_number
 applies to all
 sections of a sub_table.

 }}}

 Here is what EN300468 section 5.2.1 says about transport stream ids

 {{{
 The combination of original_network_id and transport_stream_id allow each
 TS to be uniquely
 identified throughout the application area of the present document.

 }}}


 I think some of the confusion is caused by mixing up what is meant by a SI
 table as an object and as data encoded into a transport stream for
 transmission. To me there is one notional EIT table object per original
 network id/transport stream id/service id combination. As one of its
 properties it has version number. Copies of this object are then encoded
 into various transmitted transport streams. If it is encoded into the
 transport stream to which it belongs it is encoded as an "actual" table.
 If it is encoded into any other transport stream it is encoded as an
 "other" table.

 Lets have a look at the following scenario. You are tuned to a transport
 stream with an original network id XXXX and a transport stream id YYYY.
 You a receive an EIT table with a table id of PF_EITa which must according
 to EN300468 section 5.2.4 contain original network id XXXX and transport
 stream id YYYY and a service id of ZZZZ. This table has a version of 8
 which you store and process. You then tune to a different mux. You then
 encounter a PF_EITo containing original network id XXXX, transport stream
 id YYYY, a service id of ZZZZ a version of 9. The service id of course
 refers to to original mux you were tuned to. If the version numbers "for
 the same actual snapshot of the data" can be different then you have
 absolutely no way of knowing whether this is new, old, or identical data
 to the snapshot you received previously marked version 8. So the only
 possible thing you can do is discard it. This would negate the whole
 concept of having "other" tables.

 I am off a for pint of beer (or three) in my local pub. My head hurts.

 Cheers,

 Roger

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