Tvheadend

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

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...

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 */

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!

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)

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 ?

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?

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.

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.

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 ;)

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?

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

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.

@perexg, shouldn't a disabled mux disable it's corresponding services and epg?

Good point. Fixed in https://tvheadend.org/projects/tvheadend/repository/revisions/ad50ceba3b9b0290df8c0ac9bd548d632823baa8/diff/ .