Bug #1942
EPG missing channels
0%
Description
The latest Gotham builds for the RPi (since http://forum.xbmc.org/showthread.php?tid...pid1584139) have had a problem whereby the EPG misses certain channels. These channels are still available to play but there is no information about them in the EPG. A temporary fix is to toggle "skip initial scan" and reboot the RPi. After doing so, all the channels are again listed in the EPG but they dissapear again after a few days.
More discussion on this issue is at the XMBC forum:
http://forum.xbmc.org/showthread.php?tid=181933
I've looked over the 'Bug Reporting' page at this site but all the necessary steps for 'creating a ticket' (such as creating a mux dump and getting a debugging log) presume that the reader has an understanding of unix commands... I do not. If anyone can help by telling me exactly what I need to do to get the logs, I'm happy to pass them on.
Files
History
Updated by Paolo Roascio about 9 years ago
Well, i revamp this bug as it may be related also to bugs 2473 and 2973 (in the EIT part, of course). and, of course, it applies at least to 4.1.449
In my normal use, i turn on my HTPC and use it the time i watch television (or other, but doesnt'matter). then i turn off the equipment. With this use i never noticed that my epg after some time, was empty for some channels.
In my actual tests, the HTPC is more time turned on, then i can see this behavior:
When tvheadend starts, it scans all muxes (initial scan on) and then correctly fills EPG
For some reason, not all services are registered in otamux/[mux]/config as service field, so, next rescans (which scans only muxes with service fields in their config files in otamux) skip some "problematic"(?) muxes.
I noticed that if a mux reach timeout needs a manual rescan (epggrab_ota_timeout_cb), but not all these muxes reach timeout, then there is something that prevent correct filling of the otamux directory.
In my case, muxes affected are those which serve only the present and the next program, weekly EPGs are correctly processed.
Due to the case that EPGs are only for the actual and the next program, i have to set a cron command less per hour, so the problem has surfaced.
A curious thing is that in one mux (that reaches timeout) there are three radio channels and four tv channels. in the config file for that mux under otamux directory there are only listed services for the radio channels, but periodic EIT scan retrieve correctly also tv channels.
To investigate the reason some channels are not registered in otamux configs, i did this:
- i discovered that the bandwidth during epg scan is really low (but no BER o other signal issues, vision is perfect);
- thinking to a timeout issue (some muxes problematic or no give me timeouts, but epg is correctly filled...), not per mux, but per channel, i raised the timeout in epggrap_ota_start function to 60 secs, without any result.
Ah, Of course, i tried to manually fill involved files in otamux. Naturally inserted services are deleted...
Activating idle scan muxes doesn't help too...
I hope this can be useful to investigate the reason some services are not correctly registered in config files under otamux. But if this not the case, please add the choice to force full epg scan per mux
Updated by Paolo Roascio about 9 years ago
Ops, i have to rectify, my mistake:
Activating idle scan muxes is a workaround for epg filling, but, accordly to tvheadend documentation
"If your adapter have problems with lots of (endless) tuning, try to disable this. Note that this option should be OFF for the normal operation. This type of mux probing is not required and it may cause issues for SAT>IP (limited number of PID filters)."
Then not a solution...
Updated by Paolo Roascio about 9 years ago
- File tvheadend.log tvheadend.log added
Ok, for further investigation, here is the trace (eit,epg) log for the problematic mux which serve the epg for all channels, but registers only radio channels in otamux directory.
Personally i'm not able to understand differences between radio and tv eit which prevents tv channels to be registered.
i only noticed that for these channels the "ota" parameter for epggrab_ota_service_add function is 0x0, so the if statement in eit.c skips registering (if no i think it can be obtained a segfault)
Here is a work for a skilled guy, at least to explain the log...
Updated by Jaroslav Kysela about 9 years ago
Could you test this patch ?
diff --git a/src/epggrab/module/eit.c b/src/epggrab/module/eit.c index 57e9400..b55be65 100644 --- a/src/epggrab/module/eit.c +++ b/src/epggrab/module/eit.c @@ -618,7 +618,7 @@ _eit_callback // TODO: extra ID should probably include onid /* Register interest */ - if (tableid >= 0x50) + if (tableid == 0x4e || tableid >= 0x50) ota = epggrab_ota_register((epggrab_module_ota_t*)mod, NULL, mm); /* Begin */
Updated by Paolo Roascio about 9 years ago
Hello Jaroslav, i'm testing a similar patch in this moment!!!
My synptoms are becuse ETSI EN 300 468 - V01.03.01 draft - pag. 15 (wich point me to this) tells:
0x4E event_information_section - actual_transport_stream, present/following
0x4F event_information_section - actual_transport_stream, present/following
0x50 to 0x5F event_information_section - actual_transport_stream, schedule
0x60 to 0x6F event_information_section - actual_transport_stream, schedule
So, the if statement in your patch might be:
if (tableid >= 0x4E)
This allows reception of both "present/following" and "schedule" epg
Thank you!
Updated by Paolo Roascio about 9 years ago
Sorry, but since addresses above 0x6F are for other purposes, might be better limit the table id addresses. Something like this:
if (tableid >= 0x50 && tableid <= 0x6f)
Updated by Jaroslav Kysela about 9 years ago
No, only 0x4e should be added. The 0x4f and 0x60-0x6f range is for "other transponders". It means that the broadcaster can send EIT using another transponders (other than current), too. But the actual logic is to avoid registration of these muxes as the EIT source. If broadcaster uses only other transponders to sent the whole schedule, the logic should be redesigned, but I don't think that it's your case. Is 0x4e value sufficient ?
Updated by B C about 9 years ago
is it in general a bad idea to scan other muxes eit on the fly? Maybe add some option to enable this as it might spare some manually scheduled mux eit scans?
Updated by Jaroslav Kysela about 9 years ago
The current code accepts EIT data also from the other muxes (if you tune a service from this mux for example), but it does not register these muxes as source for OTA EIT for given service (thus the OTA EPG scheduler does not scan these muxes). It's expected, that EIT for given service is broadcasted on the same mux where the service runs.
Updated by B C about 9 years ago
sure, and that should cover if, just meant if eg a provider is broadcasting eit data from all his muxes on any of his transponders, a single scan would be sufficient, at the end it does not make a difference.
Updated by Paolo Roascio about 9 years ago
Jaroslav Kysela wrote:
No, only 0x4e should be added. The 0x4f and 0x60-0x6f range is for "other transponders". It means that the broadcaster can send EIT using another transponders (other than current), too. But the actual logic is to avoid registration of these muxes as the EIT source. If broadcaster uses only other transponders to sent the whole schedule, the logic should be redesigned, but I don't think that it's your case. Is 0x4e value sufficient ?
Yes, you are right, adding 0x4f in my tests let me receive eit for overall broadcaster channels. I agree this is not optimal: maybe not all muxes serve all places, so is better that each eit refers its channel, so ok for 0x4e, but maybe the if statement should is also limited to 0x5F?
B C wrote:
sure, and that should cover if, just meant if eg a provider is broadcasting eit data from all his muxes on any of his transponders, a single scan would be sufficient, at the end it does not make a difference.
Code covers the case a single mux broadcasts eit for all channels (0x60-0x6F, only schedule), but, i think, i'm not a programmer, so not code skilled, receiving full eit from one mux doesn't avoid the scan of other muxes. By the way, as already wrote, i agree with Jaroslav, there are places (at least here in Italy) where not all muxes from a broadcaster reach the same radio coverage, the case is for the RAI broadcaster, some channels from 482 MHz (the Mux in my log), some from 546 MHz and others from 514 MHz. Repeaters aren't on the same tower, so, if i e.g. don't receive 514 MHz i can do without the related epg.
Now, sorry for my bad english, i gi ti play with my patched tvheadend
Updated by Paolo Roascio about 9 years ago
Ok tested with this if statement:
if ((tableid = 0x4E || (tableid >= 0x50 && tableid <= 0x5F)))
and works perfectly, only eit related to interested channels and config files under otamux directory are correctly filled. Periodic scan works as expected.
Just for my curiosity, at this point, this code (Eit.c - line 437):
/* Mark re-schedule detect (only now/next) */
if (save2 && tableid < 0x50) *resched = 1;
*save |= save2;
is still needed?
Updated by Jaroslav Kysela about 9 years ago
- Status changed from New to Fixed
Fixed in v4.1-467-ge2ee2a7 . The resched flag is ignored at the moment - the epggrab_resched() function in src/epggrab.c is empty.
Thanks for the report and testing.
Updated by B C about 9 years ago
Paolo Roascio wrote:
B C wrote:
sure, and that should cover if, just meant if eg a provider is broadcasting eit data from all his muxes on any of his transponders, a single scan would be sufficient, at the end it does not make a difference.
Code covers the case a single mux broadcasts eit for all channels (0x60-0x6F, only schedule), but, i think, i'm not a programmer, so not code skilled, receiving full eit from one mux doesn't avoid the scan of other muxes. By the way, as already wrote, i agree with Jaroslav, there are places (at least here in Italy) where not all muxes from a broadcaster reach the same radio coverage, the case is for the RAI broadcaster, some channels from 482 MHz (the Mux in my log), some from 546 MHz and others from 514 MHz. Repeaters aren't on the same tower, so, if i e.g. don't receive 514 MHz i can do without the related epg.
Well if you don't have the services in your list, corresponding epg entries won't pop up anyway, but we do get all necessary entries the normal way, so current functionality is working
Updated by Paolo Roascio about 9 years ago
B C wrote:
Well if you don't have the services in your list, corresponding epg entries won't pop up anyway, but we do get all necessary entries the normal way, so current functionality is working
Well, in my tests with 0x4F actived i deactivated all muxes but 482 MHz, so services are still in list.
With this setup i observed that epg page show all channels from RAI broadcaster, but only seven (the total is 18 in three muxes) are registered as services.
Is relevant that other muxes for which i receive epg are only deactivated and not erased, maybe this the reason i continue to receive?
Although, i observed that if i disable a channel, related epg is not shown.
Updated by B C about 9 years ago
@perexg, shouldn't a disabled mux disable it's corresponding services and epg?