Fixing EPG Prioritization Issues

niwi niwi

Hi,

I would like to use a TV channel (TVRI World on Astra 19.2° East) with a correct EPG. Unfortunately, the channel includes a meaningless EIT-EPG, which always displays "TVRI World" instead of the actual program names. However, I have an external source with a usable XMLTV-EPG. Unfortunately, the EIT-EPG overwrites all entries of the XMLTV-EPG. How can I change this?

What would not work for me is setting the XMLTV-EPG as the general default. In all other cases, I prefer the EIT-EPG.

In the channel settings under "Services," I have already activated the following option for TVRI World: "Ignore EPG (EIT):". This has no effect. The EIT-EPG is still prioritized. It also does not help to delete the entry for TVRI World under Channel/EPG -> EPG Grabber Channels.

How should I proceed?

DeltaMikeCharlie

In the channel settings, have you tried:

Disabling 'Automatically map EPG source?
Selecting the XMLTV 'grabber channel' as your EPG source?

niwi niwi

Yes and yes.

DeltaMikeCharlie

I have had success in the past with mixing EIT and XMLTV EPG sources, but it can have some drawbacks. I'm not claiming that this is the best way to achieve what you want. I'm just sharing a method that has worked for me in the past.

I have only tried this at a whole mux level, never an individual channel. This is a variation of what I have done previously:

On the current mux, make sure that your EPG source is forced to EIT as the grabber.
Create a new network. This will probably result in a whole lot of new muxes. You can either disable or delete the ones that you don't need.
On the one remaining active mux, ensure that the EPG scan is set to disabled.
The newly created network will not yet be allocated to any adaptors, so go into adaptors and add the new network to every adaptor that can receive the required mux.
Go back to the new mux in the new network and change the 'Scan status' to 'ACTIVE' and let it scan.
You should now get some services on that new mux.
Go into services and disable/delete the ones that you don't need.
Go into channels and create a new channel that points to the new service and set the EPG source to be the XMLTV source.
Hopefully, you should now have 2 copies of the same channel. One with EIT and one with XMLTV EPG. You could disable the EIT version or just live with the duplication.

The drawback now will be that if you want to record 2 services that includes "TVRI World" and one other that would normally be on the 'same' mux, your system will use 2 tuners instead of sharing 1 because you are going through 2 networks. Setting both recordings to use the EIT channel would prevent this situation, but would be a hassle to juggle.

I think that in situations like this, TVH needs a 'Super Deluxe Guru' mode for managing EPG sources. However, the overwhelming majority of users will never need it. Each channel can be sourced from multiple services. You could try allocating the new channel to both services, but I suspect that will just bring back the EIT.

UPDATE: There is also a 'Reuse EPG from:' field that allows a channel to be selected. In addition to the steps above, perhaps setting this value on the existing channel to point to the new channel may get the XMLTV EPG, but still allow recordings to occur in the same mux. It would just be the EPGgrab that would need its own mux when running.

niwi niwi

Thank you. I solved the problem with your suggestions.

Regarding TVRI: Now that I can see the external EPG, I realize that it is not only very precise but also incorrect... But that is a problem to be solved elsewhere.

DeltaMikeCharlie

niwi niwi Thank you. I solved the problem with your first suggestion.

You are welcome. I'm glad that it worked.

Your updated suggestion would probably mean that I would have to add the channel twice to my channel list, which is something I don't want to do. I tried disabling the channel to reuse the EPG from it, so that the channel appears only once in my channel list. However, in doing so, no EPG is visible at all.

If your frontend supports them, you could try experimenting with 'Channel Tags'. You could create a tag called 'My Channels' (or whatever) and just not put the XMLTV channel in that group. Put the EIT channel in the group that reuses the XMLTV channel's EPG. On your frontend, you could then select to only show the EPG for channels from 'My Channels'.

niwi niwi

Actually, I was wrong in the part you are quoting, and I delete some minutes after publishing. I made I mistake first that let me believe it wouldn't work.

At least for now, it works to disable a channel and still to reuse the EPG. However, it might mean that the EPG will not be updates in the future. Time will tell.

Using Channel tags would work for sure and might be a good solution for others reading this solution in the future. I use around 90 channels and use different channel tags for sorting my channels in TVHeadend/Kodi. So this wouldn't work for me.

DeltaMikeCharlie

niwi niwi

I just built a new empty system to test some EPG grabbing features that previously appeared to be not working properly. Between every run of TVH, I delete the EPG database so that I can see the effects of each single change that I have made.

Firstly, I set 'EPG Scan' on a single mux to 'Disabled'. Unsurprisingly, the EPG was not provided for every service on that mux.

Next, I set a single service to 'Ignore EPG (EIT). When I restarted TVH and ran an EPG scan, the whole mux previously selected AND the single service that I selected contained no EPG data. The other services that shared the mux with the single excluded service all got correct EPG. This is as expected.

Next, I fed some XMLTV data into TVH for the single service and that EPG data was recognised. I did not have to manually set the grabber channel because I ensured that I matched the channel details to the single service mentioned above.

Continuing on, without restarting TVH, I reran an OTA EPG scan and the EPG data for the XMLTV channel remained unchanged.

It seems that, at least on a pristine system, all of the EPG flags work as advertised.

I think that starting with an empty EPG database was the key and that what you (and I previously) experienced was the result of old records in the EPG database.

I think that all of that duplicate network stuff can be avoided by disabling the EIT on that single service that concerns you, stopping TVH, deleting the EPG database, restarting TVH, loading the XMLTV data and then doing an OTA EPG grab.

niwi niwi

Could you please write how you deleted the EPG database? Maybe you did it differently than me. I just deleted the entry for TVRI World under Channel/EPG -> EPG Grabber Channels.

DeltaMikeCharlie

niwi niwi - With TVH not running, I nuked the whole EPG database file epgdb.v3 and then restarted TVH. This is fairly radical and it is not without risk. You will then have to rescan all of your EPG sources. If you have any scheduled recordings linked to CRIDs, these may disappear or have their linkages broken.

A potentially safer alternative would be to ignore the EPG on that 1 service and let it sit like that for a week or until all of the EPG entries have naturally passed. Then you can enable the XMLTV.

EPGTechTalk

To fix EPG prioritization when EIT-EPG overwrites XMLTV-EPG entries, check your channel settings again. Even if "Ignore EPG (EIT)" is enabled for TVRI World under Services, the EIT-EPG may still take priority if the system isn’t processing the setting correctly.

Since the EIT-EPG for TVRI World only displays the channel name instead of program details, you may need to confirm that the XMLTV-EPG source is properly mapped to the channel. Verify that the XMLTV provider’s channel ID matches the exact service name in your system.

If the issue persists, manually adjusting EPG priorities in backend settings or updating your middleware software may resolve conflicts between the two EPG sources. Some platforms also require a restart after changes to enforce new EPG rules.

If possible, test with another channel to confirm the problem is specific to TVRI World. This can help isolate whether the issue stems from broadcast data or software handling.