I’ve had a quick look at the code. One of the first things that happens to the incoming EIT payload is that there are some sanity checks on the table ID.
Next, the service_id, transport_stream_id, original_network_id and segment_last_section_number are extracted.
If the table ID type is for ‘other’, then it tries to find the mux based on TVH network, onid and tsid. I think that this is doomed to fail outside of Auckland.
If the table ID type is ‘actual’ (ie, not ‘other’), then it tries to do some TSID/ONID matching (I also think that there may be a bug in the ‘ignore TSID’ feature that ignores if ONID does not match as well). If that match fails, then the payload is ignored.
Looking at some of the logs in the original issue raised 7 years ago, it would appear that ‘other’ table types are being used.
I think that 2 things need to be done:
1) The TSID in the EIT data needs to be changed to be a valid local TSID that will match to a mux. TSID 0x0019 (Auckland) needs to be changed to TSID 0x001C (South Island).
2) The table type, if set to ‘other’ also needs to be changed to ‘actual’ so that TVH will handle it properly. Table type 0x4F -> 0c4E, 0x60 -> 0x50, etc.
As a proof-of-concept, we could simply hard-code the change from 0x19 to 0x1C as well as the table types.
If that works, then for a permanent solution, once SID is known, a lookup can be done for a local service matching that SID. The TSID and ONID for that SID can then be hacked into the EIT payload as well as changing the table types. Naturally, if the result comes back as 0x19, the user is in Auckland and no further action is required.
