Project

General

Profile

Feature #2858

Ignoring onid:tsid on actual ts eit tables

Added by B C over 9 years ago. Updated over 9 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Category:
EPG
Target version:
Start date:
2015-05-19
Due date:
% Done:

100%

Estimated time:

Description

While looking if there is some eit information available for the AFN package on Eurobird 9a, I found out that instead of the real onid:tsid (9:1) there is always 100:100 in any eit table for the current ts. By ETSI definition all EIT sub-tables for the actual Transport Stream shall have the same transport_stream_id and original_network_id values (well they are the same but not correct :-) ). If this check could be ignored on table ids 0x4e and 0x50 to 0x5f and if onid and tsid would be fetched from the ts, I assume that the epg would get populated without any further action. This would not harm correct tables and the probability that other mailformd eit tables enter the epg is quite low. It could be even locked down to 100:100 to further minimize any impact

2015-05-19 23:15:43.282 [  TRACE]:eit: 00 01 DD 08 B8 00 64 00 64 08 51 2F 19 DF 4D 03 ......d.d.Q/..M.
2015-05-19 23:15:43.282 [  TRACE]:eit: 00 00 01 00 00 00 19 4D 13 65 6E 67 0E 49 6E 73 .......M.eng.Ins
2015-05-19 23:15:43.282 [  TRACE]:eit: 69 64 65 20 54 68 65 20 4E 42 41 00 54 02 00 00 ide The NBA.T...
2015-05-19 23:15:43.282 [  TRACE]:eit: 2F 1A DF 4D 04 00 00 01 00 00 00 17 4D 11 65 6E /..M........M.en
2015-05-19 23:15:43.282 [  TRACE]:eit: 67 0C 53 70 6F 72 74 73 43 65 6E 74 65 72 00 54 g.SportsCenter.T
2015-05-19 23:15:43.282 [  TRACE]:eit: 02 00 00 2F 1B DF 4D 05 00 00 01 00 00 00 17 4D .../..M........M
2015-05-19 23:15:43.282 [  TRACE]:eit: 11 65 6E 67 0C 53 70 6F 72 74 73 43 65 6E 74 65 .eng.SportsCente
2015-05-19 23:15:43.282 [  TRACE]:eit: 72 00 54 02 00 00 D1 CF FD FE                   r.T.......      
2015-05-19 23:15:43.282 [  TRACE]:eit: invalid tsid found tid 0x51, onid:tsid 9:1 != 100:100

History

#1

Updated by Jaroslav Kysela over 9 years ago

It's probably better to have a whitelist somewhere...

#2

Updated by B C over 9 years ago

A whitelist configurable under epg/ota grabbers would definitely be the soluton to go as it would need to be enabled by the user. Great implementation idea.

#3

Updated by B C over 9 years ago

I hardcoded this into eit.c to check if the eit information is valid, and voila, I now have EPG on this package. The only thing I noticed is that while on a channel, it grabs only EPG from the current SID, is this by design?

#4

Updated by B C over 9 years ago

so I'm ignoring onid:tsid for nearly a month without any issue. It would be great if this could be enabled on a per mux basis or with a white list.

#5

Updated by Jaroslav Kysela over 9 years ago

  • Target version set to 4.2
#6

Updated by Jaroslav Kysela over 9 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|32a2d9c8eb1b9d5b2a3486848c37a8418807985a.

#7

Updated by B C over 9 years ago

thanky you very much
I now get:

2015-09-21 15:46:34.199 eit: completed pid 18 table 00000000 / 00000000
2015-09-21 15:46:34.199 eit: grab complete

but no new EPG entries. In my temporary patch I did set:

mm->mm_tsid = tsid;
mm->mm_onid = onid;

which should do the trick.

#8

Updated by B C over 9 years ago

so set mm = NULL only if we don't ignore it, and use onid and tsid of the channel we are currently parsing.

I have tested the following as working: (from line 646 in /src/epggrab/module/eit.c)

     if (mm->mm_onid != MPEGTS_ONID_NONE &&
          mm->mm_tsid != MPEGTS_TSID_NONE &&
          !mm->mm_eit_tsid_nocheck) {
        tvhtrace("eit",
                "invalid tsid found tid 0x%02X, onid:tsid %d:%d != %d:%d",
                tableid, mm->mm_onid, mm->mm_tsid, onid, tsid);
        mm = NULL;
      }
      else {
         mm->mm_tsid = tsid;
         mm->mm_onid = onid;
      }

#9

Updated by B C over 9 years ago

some more testing revealed that

mm->mm_tsid = tsid;
mm->mm_onid = onid;

is not necessary, so just not setting mm = NULL and putting it in braces with the log message is fine

#11

Updated by B C over 9 years ago

yes, this is working as well, thanks

Also available in: Atom PDF