Bug #6249
OTA EPG grabber
0%
Description
As in bug #6237 already reported for arte received over DVB in the EPG is showing a transmission named "ARTE" with extra text "El canal de televisiðn cultural.".
This show is usual starting 6am and has a duration of 24 hours.
Asking arte what this EPG record is I got the answer this is a comment for the spanish EPG.
The anoying on this entry is that in the Tvheadend HTSP client for Kodi (libreelec 10.0.4) only this record is shown.
On other devices I could test (Smart TVs from LG, Toshiba, Sony and an old Sky receiver) this record is not shown. Also in the VDR EPG it is not shown.
This with the statement from Arte customer service bring me to the conclusion that the tvheadend OTA EPG grabber is falsely interpreting this as an regular show.
Files
History
Updated by Andreas Tauscher almost 2 years ago
Why invalid?
The EPG data for arte coming from the internal OTA grabber is obvious wrong, broken.
Other devices are working like expected and not showing this record which is not a television program.
Updated by Flole Systems almost 2 years ago
Because this is not a valid issue report:
Issue reports without debug logs/a stacktrace and instructions on how to reproduce the issue will not be accepted.
Updated by Andreas Tauscher almost 2 years ago
Flole Systems wrote:
Because this is not a valid issue report:
Issue reports without debug logs/a stacktrace and instructions on how to reproduce the issue will not be accepted.
To reproduce: Open tvheadend with a DVB-S source (Astra 19.2°) and have a look in the EPG for arte HD
First now the requested 30 seconds ts sample
The logfile for epg, epggrab giving nothing. It seems this comment event is sent not regular like normal EPG.
Keeping it runing and watching if it is showing up somewhen.
Updated by Andreas Tauscher almost 2 years ago
The 30 seconds sample ts with 144MiB was curt off: " Request Entity Too Large"
Updated by Flole Systems almost 2 years ago
You're probably not looking at the correct debug log, the EIT table contains all the EPG stuff, so that one is relevant here.
The TS probably contains unnecessary data aswell and not just the EPG data, if you remove audio and video data it should be possible to upload it.
Updated by saen acro almost 2 years ago
Read this old problem with EPG
https://tvheadend.org/issues/5062
and use https://www.digitalekabeltelevisie.nl/dvb_inspector/ to see what is wrong in your case.
Updated by Flole Systems almost 2 years ago
I also have more advanced tools to inspect the EIT available, they even find and show errors/specification violations automatically. I can definitely load a mpeg-ts file to verify it's contents.
Updated by Andreas Tauscher almost 2 years ago
Thanks for the information.
This will help to get the needed information out of logs an the ts stream.
Unfortunate my time is at the moment very limited and a broken EPG for Arte has not the highest priority.
Might need some time.
Updated by Deep Thought over 1 year ago
I see the same problem in kodi's epg, bit as soon as I actually tune to ARTE the EPG
updates to the correct one.
So probably what happens is that the "ARTE" title is downloaded from some other OTA source
during automated EPG scanning.
Updated by Andreas Tauscher over 1 year ago
Flole Systems wrote:
I also have more advanced tools to inspect the EIT available, they even find and show errors/specification violations automatically. I can definitely load a mpeg-ts file to verify it's contents.
I have now recorded 24 hours Arte.
How can I remove audio and video to make this 118GB file smaller.
My tries with ffmpeg seem being not sucessfull.
The "Stream #0:0[0x12]: Data: epg" changed in the output to "Stream #0:0[0x100]: Data: bin_data ([6][0][0][0] / 0x0006)"
I tried with
ffmpeg -i /recordings/ARTE2023-02-12.ts -map 0 -map -0:v -map -0:a -c copy -copy_unknown /storage/ARTE2023-02-12.ts
Updated by Flole Systems over 1 year ago
Maybe you should only record the EPG stuff instead of trying to filter it later on. I don't think ffmpeg knows anything about the concept of EPG, otherwise the map option should work.
Maybe a simple -map 0:0?
Updated by Andreas Tauscher over 1 year ago
Flole Systems wrote:
Maybe you should only record the EPG stuff instead of trying to filter it later on.
How?
If you want to download the 118G file. I can upload it to my esternal server.
Updated by Flole Systems over 1 year ago
Using SAT>IP/RTP. Simply only subscribe to PIDs 1-20, that should include all the tables but no audio/video/teletext/whatever.
There's probably no point in recording that long, 5 minutes should be more than enough.
Updated by Andreas Tauscher over 1 year ago
Flole Systems wrote:
Using SAT>IP/RTP. Simply only subscribe to PIDs 1-20, that should include all the tables but no audio/video/teletext/whatever.
There's probably no point in recording that long, 5 minutes should be more than enough.
Finally I got it.
Updated by Flole Systems over 1 year ago
I just checked the file and in this file there is no EPG entry named "ARTE". I assume it is broadcasted on another transponder, which is clearly a fault of the channel and not of Tvheadend. When changing to the correct transponder the correct EPG data is parsed, replacing the bad data again. It should even correct the data if you select a different channel on the same transponder. If you switch to a channel on the "bad" transponder it will most likely replace the good data with the bad data again. Someone mentioned on another forum that 10788:V is the "bad" transponder, if you grab EPG data from that one I can verify that.
Updated by Andreas Tauscher over 1 year ago
Flole Systems wrote:
I just checked the file and in this file there is no EPG entry named "ARTE". I assume it is broadcasted on another transponder, which is clearly a fault of the channel and not of Tvheadend. When changing to the correct transponder the correct EPG data is parsed, replacing the bad data again. It should even correct the data if you select a different channel on the same transponder. If you switch to a channel on the "bad" transponder it will most likely replace the good data with the bad data again. Someone mentioned on another forum that 10788:V is the "bad" transponder, if you grab EPG data from that one I can verify that.
This is the correct transponer.<
The EPG data is for
svcId | EIT avail | provider | service name
10301 | p/f sched | ARD - Das Erste HD
10302 | p/f sched | ARD - arte HD
10303 | p/f sched | ARD - SWR BW HD
10304 | p/f sched | ARD - SWR RP HD
At time of recording the "El canal de televisiðn cultural." did not show up.
But I continued the recording.
Now the file is 2.4GB.
Updated by Flole Systems over 1 year ago
The assumption is that there is a bogus EIT entry on that other transponder which overwrites the EIT on this transponder.
You can also periodically restart the recording if you don't see the bad entry, that will reduce the file size significantly.
Updated by Andreas Tauscher over 1 year ago
You can also periodically restart the recording if you don't see the bad entry, that will reduce the file size significantly.
I can not find this record.
I subscribed to the PIDs 0-20 with vlc and running wireshark for the case that vlc is dropping or correcting this record.
Could not find this "El canal de televisiðn cultural." in the wireshark records. No idea how it is encoded.
Wireshark was running from Sunday evening until now.
In the tvheadend EPG it showed up again for 21. March starting at 6:00 with duration 24h and the same for 22. March.
Today it disappeared again in tvheadend.
Updated by Andreas Tauscher over 1 year ago
This problem was already existing in 2017.
This record is from a different transponder.
Seems tvheadend is trusting channel and transponder IDs like vdr before it was patched 2018 and is merging EPG data from different transponders.
A solution here:
Updated by Andreas Tauscher over 1 year ago
- File arte.epg.ts arte.epg.ts added
Flole Systems wrote:
I just checked the file and in this file there is no EPG entry named "ARTE". I assume it is broadcasted on another transponder, which is clearly a fault of the channel and not of Tvheadend. When changing to the correct transponder the correct EPG data is parsed, replacing the bad data again. It should even correct the data if you select a different channel on the same transponder. If you switch to a channel on the "bad" transponder it will most likely replace the good data with the bad data again. Someone mentioned on another forum that 10788:V is the "bad" transponder, if you grab EPG data from that one I can verify that.
Now I got it.
Needed to read the whole thred again. Too busy and in the evening to tired the las weeks. Brain was not really working :/
The transponder 10788:V is transmitting this broken EPG data.
Updated by Flole Systems over 1 year ago
If you don't watch anything on that transponder you can just disable it.
Otherwise feel free to contact Arte again and ask them why they are transmitting that stuff on a different transponder, there's really no point in doing that and I suggest that they stop doing that ASAP.
Updated by Andreas Tauscher over 1 year ago
Flole Systems wrote:
If you don't watch anything on that transponder you can just disable it.
If this would work....
I went to config - Muxes and set 10788V to Disabled. The "Enabled" field and the "EPG scan" field.
I stopped tvheadend, deleted /home/hts/.hts/tvheadend/epgdb.v3 and started tvheadend again.
After a few seconds: "El canal....."
Otherwise feel free to contact Arte again and ask them why they are transmitting that stuff on a different transponder, there's really no point in doing that and I suggest that they stop doing that ASAP.
This is not a problem with Arte.
This transponder is not Arte. On this transponder are spanish free and pay-tv stations.
Updated by Andreas Tauscher over 1 year ago
Andreas Tauscher wrote:
Flole Systems wrote:
If you don't watch anything on that transponder you can just disable it.
If this would work....
Sorry. Also 11097:V (also Spanish) is transmitting this crap.
Updated by Flole Systems over 1 year ago
Andreas Tauscher wrote:
This is not a problem with Arte.
This transponder is not Arte. On this transponder are spanish free and pay-tv stations.
Well you can also try to contact the operator of the transponder. Usually the channel operator has a better way of reaching people who understand the issue and can fix it though.
Updated by Andreas Tauscher over 1 year ago
And 11038:V, 10979:V, 11453.5:V, 10817.5:V, 11435.5:V, 10729:V, 11258.5:V, 11685.5:V, 10906:V, 10935.5:V, 11156:V, 11126.5:V, 10758.5:V, 10876.5:V, 11317.5:V
Not sure which it is exactly but at least one of this is sending with the Transport stream ID of Arte in the EIT
Seems is messed up by the spanish pay-tv M+
Disabling all this muxes can be only a temporary workaround and not a solution.
IMHO it would be a good idea to handle this data like vdr doing it: Do not trust that the TSI is set correct. Verify that the actual transponder and the data in the SIT/EIT is matching.
Updated by Andreas Tauscher over 1 year ago
Flole Systems wrote:
Andreas Tauscher wrote:
This is not a problem with Arte.
This transponder is not Arte. On this transponder are spanish free and pay-tv stations.Well you can also try to contact the operator of the transponder. Usually the channel operator has a better way of reaching people who understand the issue and can fix it though.
Are you kidding?
Asking such organisations about techical issues?
This is like asking microsoft support when they fucked up again their mailservers.
Updated by saen acro over 1 year ago
Play with TSDuck, this problem not exist in my Neutrino box.
This is some glitch in TVH code.
Updated by Andreas Tauscher over 1 year ago
saen acro wrote:
Play with TSDuck, this problem not exist in my Neutrino box.
This is some glitch in TVH code.
Exact.
The screenshot is a packet I recorded from one of the M+ transponders.
Clearly visible is the Transport stream ID 0x03fb (decimal 1019).
This is the Transport stream ID of arte HD.
TVH is trusting that the Transport stream ID in the EIT is correct and merging all EIT with the identical transport stream ID together.
In this case the data is coming from a different transponder. The transport stream ID is wrong.
TVH should verify if the transponder and the transport stream ID is matching and only merging together what belongs together and ignoring crap.
Flole Systems Systems: Please change the status from invalid to new and assing it to somebody.
Updated by Flole Systems over 1 year ago
saen acro wrote:
This is some glitch in TVH code.
No, Tvheadend follows exactly the specifications that clearly says
Each service_id shall be unique within each original_network_id. Therefore the combination of service_id and original_network_id uniquely identifies a service.
Each unique instance of a service can be uniquely referenced through the path original_network_id/transport_stream_id/service_id (see EN 300 468 [i.1])
If some operator is violating this that's not a bug in Tvheadend. If you want to implement such a feature it could be tracked as a feature request.
Updated by Dave Pickles over 1 year ago
You can achieve what you want by commenting out line 1011 in src/epggrab/modules/eit.c. However this will break EPG on 29.2E, where the data is carried on a separate dedicated transponder.
Updated by Andreas Tauscher over 1 year ago
Dave Pickles wrote:
You can achieve what you want by commenting out line 1011 in src/epggrab/modules/eit.c. However this will break EPG on 29.2E, where the data is carried on a separate dedicated transponder.
Also no solution.
Only a woraround and not every user is able to build TVH from source.
Updated by Andreas Tauscher over 1 year ago
If some operator is violating this that's not a bug in Tvheadend. If you want to implement such a feature it could be tracked as a feature request.
But only TVH having this problem.
From about 10 different devices I tested (even a cheap crappy receiver I bought ~10 years ago for less than 30€) not a single one having this problem.
Only TVH is providing broken EPG data.
There is also one product from company M. from Redmond breaking the SMTP standard.
This is why mail servers reply on a EHLO with one double line:
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
It is not a problem of postfix, exim and others. M$ is breaking the SMTP and not able/willing to fix this, so others fixing it.
Updated by saen acro over 1 year ago
Flole Systems wrote:
No, Tvheadend follows exactly the specifications that clearly says
Exact exact or little bit not exact
Updated by Flole Systems over 1 year ago
saen acro wrote:
Flole Systems wrote:
No, Tvheadend follows exactly the specifications that clearly says
Exact exact or little bit not exact
All that isn't executed unless workarounds are enabled, literally the first line in that function says
if(sd->sd_disable_workarounds)
return;
So it does follow the specifications until it's told not to. I don't have a problem with workarounds if they have sane default settings that don't break anything.
Anyways, it's a feature request and not a bug, so the direction is clear: Either someone here wants to work on it (not entirely sure how a solution should look like if other satellites are carrying the EPG data on separate transponders, but I'll happily take a look at the PR once it's ready) or the status is correct as it's not a bug. Or you could still ask the operator or the channel to fix their stuff rather than working around it, that might be easier for you to do than changing Tvheadend itself.
Updated by Deep Thought over 1 year ago
Violations of the dvb standards are frequent on satellite: muxes lie about frequencies, satellite positions,
confuse east with west, and even contain contradictory data. That means workarounds are typically needed.
Standards are only useful when respected.
I have worked on code like this in the past, and perhaps the following info could be useful:
Some possible heuristics to get rid of crappy epg records are:
-if no epg data for the timeslot/service exists yet, accept any data from any source. In this case,
the spanish crap would be stored only if there is no valid epg yet.
Reasoning: better some epg than no epg at all, even if the result in this specific bug would not be
be helpful, it can help for other services and does no harm.
-if epg data exists, only overwrite it if the new epg data has higher priority than the old one
With a proper defintion of priority, the spanish crap will be overwritten when tuning to the arte transponder
and will not be overwritten later, when tuning to the spanish provider.
priority can be defined in multiple ways, which can be combined. None is perfect.
examples:
1. priority is higher if the mux providing the epg data also contains the actual service. In this case,
if spanish crap is present, epg grabbing of the mux containing arte will fix it and it will remain fixed.
2. epg data contains language encodings and I have seen muxes that broadcast data in multiple
languages simulatenously. So it would be useful as a feature anyway to ask the user to provide a list of language priories as configuration. E.g., 1st choice german, 2nd french ... spanish.
With such a preference, if data is received for a higher priority language it will overwrite existing data, otherwise not. This example would also fix the specific problem
of this bug by prefering french over spanish. Not a solution for everyone of course + language codes
can also be wrong.
3. priority can also be defined based on the length of "story". Records with longer length have priority.
Reasoning: in many cases this leads to more useful information for the user.
This too would probably fix the specific bug in question.
4. priority can be based on a user setting on the mux.
5. or on the duration of the program. Typically placeholders are much longer (many hours) than real epg.
So if new data overlaps with old data, prefer the shorter one. The details may require some work.
This might work in the case of the arte bug
6. if priority of old and new data is equal, and the records differ, prefer newer over older information.
All of the above solutions will make no difference at all if there is no conflicting data on satellite.
So they should be safe. Some are easier to implement than others, and they can be combined to some degree.
They are all heuristics and given the amount of crap broadcasters are making up,
they will not be full solutions and can still fail, but they can only fail on data for which
dvb standards are violated (=do no harm).
As all of this is a pain to debug, it may also be useful (as debugging option) to include the network_id and
ts_id of the mux which provided the data, along with the date when it was captured. This can be easier to check than in debug logs (but debug logs are of course still valuable. One does not replace the other)
PS. Why do have to annotate so many buses, just to log in on this forum? It is quite annoying.
Updated by Flole Systems over 1 year ago
Good luck finding someone who implements all that, but that seems like a good way of doing that.