How to display the EPG and enjoy catchup/replay?

[GoPapaSmurf]

Hello,

I saw there's an EPG and catchup functionality in IPTVNator in the EPG sidebar: #658
I tried enabling it here, but I'm unable to display the EPG in the right side bar...
I went to the program settings, then "EPG", and it says "No EPG sources yet", although my Xtream account does provide an EPG, catchup service, and in fact, under the video there are the forthcoming TV programs listed (but not the past ones for replay).
I tried adding the TV service URL in the form of http://my_provider_here.com/get.php?username=abc&password=123&type=m3u_plus&output=ts in the EPG section of the settings, to no avail, it reports "Text data outside of root node". I guess this is not an EPG URL (wrong data and format).
I'm able to watch past TV programs in other applications (e.g. Tivimate, Zoom Player Stream), but I'm struggling to enable it in IPTVNator. Could you help me please?

Thank you.

[salvador-castro]

The URL you're using (get.php?type=m3u_plus) returns an M3U playlist, not EPG data — that's why you're getting "Text data outside of root node". IPTVNator's EPG section expects an XMLTV-formatted URL.

With Xtream Codes providers, the EPG URL usually follows this format:

http://your_provider.com/xmltv.php?username=abc&password=123

Try adding that in the EPG settings instead. Your provider supports EPG (since you can see upcoming programs), so the endpoint should exist — it's just a different URL than the M3U one.

If that doesn't work, some providers use slightly different paths like /epg.xml or /epg.php — you can ask your provider directly for the XMLTV URL.

[GoPapaSmurf]

Thank you. Yes, this helped. Now, my EPG is imported, and the settings don't complain anymore not having any EPG source.
Only problem is how to display the EPG on the right-hand side, and how to display past TV programs in the EPG to replay them.

[salvador-castro]

Glad it worked! For the EPG sidebar display, make sure the channel names in your M3U playlist match the tvg-id or tvg-name attributes with the channel IDs in the XMLTV file — mismatches are the most common reason the EPG appears empty in the sidebar even after importing.

For catchup/replay, IPTVNator requires the channel to have catchup="default" and a catchup-source attribute in the M3U. If your provider supports it, those should already be in the playlist — it might be worth checking a channel entry directly in the M3U file to confirm.

[GoPapaSmurf]

Thank you.

[salvador-castro]

For the EPG sidebar, once the XMLTV is imported, program details should appear automatically in the right sidebar when you select a channel — but only if the tvg-id in your M3U matches the channel IDs in the XMLTV file. You can verify this by opening your M3U playlist in a text editor and checking a channel entry like:

#EXTINF:-1 tvg-id="CNN.us" tvg-name="CNN",...

That tvg-id value must match exactly the id attribute of the corresponding <channel> tag in the XMLTV. If they don't match, the sidebar will stay empty even with EPG imported.

For catchup/replay, this depends entirely on your provider including the right attributes in the M3U. Look for something like this in a channel entry:

#EXTINF:-1 tvg-id="..." catchup="default" catchup-source="http://provider.com/timeshift/{id}/{start}/{duration}/",Channel Name

If those attributes are missing, IPTVNator has no way to know where to fetch past content — that's a provider limitation, not an app one.

[GoPapaSmurf]

Thank you. I downloaded both EPG and M3U files and opened them in a text editor. I searched for the "id" tag in the EPG and the "tvg-id" tag in the M3U. They have the same value:

In EPG.txt:

<channel id="TF1.fr"><display-name>FR| TF1 HD</display-name><icon src="http://url_here/picons/logos/france/507471.png" /></channel>

In M3U.txt:

#EXTINF:-1 tvg-id="TF1.fr" tvg-name="FR| TF1 HD" tvg-logo="http://url_here/picons/logos/france/507471.png" group-title="FR| FRANCE HD",FR| TF1 HD http://url_here/abc/123/something_else

However, my EPG isn't displayed in the right pane, and the EPG that is displayed below the video doesn't allow to replay a past TV program (it only displays current and forthcoming TV programs). I didn't find any entry for "timeshift" or "catchup" in the text files.

I just took a look again in Tivimate and in Zoom Player, tuning in the same TV channel, I was able to watch TV programs aired this morning and yesterday evening. I wonder how Tivimate and Zoom Player work to allow to view past TV programs, maybe they work differently.

[WolfganP]

Does anyone know if catch-up works in XC streams?

URL build seems to be implemented in https://github.com/4gray/iptvnator/blob/master/libs/portal/xtream/data-access/src/lib/services/xtream-url.service.spec.ts , but I cannot make past entries' EPG load into iptvnator (even if past days EPG & catchup works in android and other desktop clients accessing the same provider list)

I don't remember if it worked before, and stopped working with 12eca90 introduced in v0.20, but can't test due to database changes (I need to setup another environment to test old versions)

TIA for any help.

Edit: Catch-up works in v0.21 (I left open a channel EPG to advance some programs, and both live and the past displayed entries work in catch up).
It seems to be an issue with EPG past entries loading.

[GoPapaSmurf]

FYI, I use Xtream Codes to get connected (not a URL).
I hope catchup works here one day.

[WolfganP]

@4gray is there any way we can help you troubleshoot this issue to see if it's a new one or regression?

[salvador-castro]

@GoPapaSmurf The reason Tivimate and Zoom Player can replay past content without catchup attributes in the M3U is that both apps implement the Xtream Codes API natively — when you connect via XC credentials, they use the provider's built-in timeshift endpoint directly (/timeshift/{username}/{password}/{duration}/{start}/{stream_id}.ts) instead of relying on M3U-level catchup attributes. IPTVNator currently doesn't implement that XC-native timeshift path for past content, which is why you hit a wall even though your provider supports it.

@WolfganP Your observation about past EPG entries not loading is a separate but related issue. The xtream-url.service you linked handles URL construction, but the problem is likely upstream of that — IPTVNator probably isn't fetching the get_short_epg or get_simple_data_table XC API endpoints for past programme data at all, only the XMLTV feed (which many providers only populate with current + future entries). That would explain why live and upcoming catchup works in v0.21 (those entries are in the XMLTV) but past ones don't load (they're only accessible via the XC API directly).

For the EPG sidebar not displaying despite matching tvg-id — @GoPapaSmurf, one thing worth checking: when you connect via Xtream Codes in IPTVNator (not URL), the app may be internally constructing channel identifiers differently than the XMLTV id you added manually. Try going to EPG settings and re-importing the XMLTV URL after your XC playlist is fully loaded, and check whether IPTVNator has a "refresh EPG" or "re-match channels" action. The import order can sometimes cause matching to fail silently.

In the meantime, the most actionable path for replay is filing or upvoting a feature request specifically for XC-native timeshift support — the infrastructure for XC URL construction is clearly already in the codebase, it's a matter of wiring it up to the catchup UI.

[Alanon202]

Been trying to see if I can fix some of this in #1104 and #1106 and got to a fairly useable state for my xstream providers and EPG use, at least...

[salvador-castro]

@Alanon202 @WolfganP Both fair points, and I don't think they're actually in conflict — it's more a question of where to draw the line between "the player should just play what it's given" and "the player shouldn't silently lose data it already has."
The EPG-cache-loss issue and the timezone-normalization issue read to me as bugs, not features — a provider is sending correct catch-up data, and IPTVNator is either discarding it on refresh or misinterpreting the timestamp. That's different from manual channel-to-EPG mapping, which is genuinely new functionality layered on top of what a provider sends. Splitting on that line might make the smaller PRs easier for @4gray to reason about: "fix data we already have" vs. "add a new matching workflow" are very different review burdens, even though both came out of the same debugging session.
On the favourites-list vs. live-tv-list divergence — that's a good root-cause thread to pull on before touching UI: if catch-up registers correctly in one list but not the other for the same channel/provider, there's likely a shared EPG/catch-up resolution service being called with different context (or not called at all) depending on which list triggers it. Worth grepping for wherever catch-up availability gets computed and checking if the favourites path even reaches that function, versus reimplementing it separately.
@WolfganP, re: "do it externally" — I get the philosophy, but Alanon202's point about providers blocking cloud IPs (which rules out most external EPG/list tools) and not wanting to hand credentials to third-party editors seems like a real practical constraint, not just a preference. Might be worth asking @4gray directly whether basic manual matching (not full EPG aggregation) is something upstream would even consider merging, before Alanon202 sinks more time into polishing it.

[Alanon202]

@salvador-castro I had some free time yesterday so I dug in and ported everything to 0.22 release, made some new PRs and chatted with the AI to fix some oversight on my part. I did think about how to make things more focused (among others like you hinted, I placed several smaller fixes and tweaks which improve things around EPG and put them together in a separate PR, favourites list catch-up and live catch-up are together, etc). Most are simpler in nature and smaller in scope. The biggest PR by far is manual EPG mapping which by nature touches a lot of code in different places, not much I can really do about that.

I’ll refrain from messing around any further without some feedback from upstream. (Since you were kind to tag the dev, I’ll refrain from doing that, by the look of things they’re probably very busy working on implementing embedded mpv.) As you said, there’s a question of whether any of these things are even interesting for them to implement, also a question of whether my code is good enough, so, I’ll wait. I don’t really have the time or stomach to maintain a fork, and I certainly don’t have the juice in me to re-rebase these things on 0.23 any time soon. That said, I’m not princely about my code, if the devs said "we like the features but your work is crap, please create four feature requests" I’d be fine with that.

I also pulled in the favourites list persistence code into my local build, and basically, with these couple of changes implemented, I’m happy using IPTVnator with my provider. So, if there isn’t an appetite for these PRs, I’ll probably just stick with my build for a while, then try out a new version in six months and maybe re-base off that, etc.

[4gray]

Hey guys, thanks for this discussion — I've been following it, but sorry I haven't had a chance to reply until now. It's a huge help, since I only have a few playlists to test with, and EPG is one of the features that's poorly supported in mine — honestly, I don't really use it much myself, so any help in this area is very welcome. Also, if you have portals (especially Stalker portals) that you could share with me for testing, please let me know — especially cases where a portal features works fine in another app but misbehaves in IPTVnator.

Regarding some of the features discussed here:

EPG mapping: Since I don't use EPG that often myself, I can't really judge how convenient it is to configure the mapping manually, or how to avoid redoing it after refreshes/updates — it definitely needs to be persisted properly. But as was pointed out, other players offer this feature, so I think we can add it, test it, and iterate based on feedback.

EPG caching: Also a very good point. To be precise, EPG data is already persisted in the local database, but every refresh replaces a source's data with whatever the feed currently contains — so past entries are lost unless the source itself provides archives. Retaining past programs across refreshes is definitely a good idea. We'd need to decide how to define the retention window (2–3 days?) — it could be configurable, or derived from the catch-up/timeshift duration that providers already report per channel (tv_archive_duration for Xtream, catchup-days in M3U).

@Alanon202 I also saw your latest PRs — I'll try to review them soonish. Thanks for the effort! 💪

[salvador-castro]

@4gray Good news that you already persist EPG data — that simplifies this a lot, it's really just "don't overwrite, merge" on refresh rather than adding a new storage layer.
On the retention window: deriving it from what the provider already reports (tv_archive_duration for Xtream, catchup-days in M3U) seems like the better default over a fixed 2–3 days — providers vary a lot here (some offer 24h, some offer 7+ days), and a fixed window would either throw away catch-up data some users actually have access to, or keep useless entries for users whose provider only offers a day. A hardcoded fallback (e.g. 3 days) for cases where neither attribute is present would cover the gap.
One edge case worth deciding up front: what happens when a channel's tv_archive_duration shrinks between refreshes (provider changes their retention) — trim the cache to match on next refresh, or just let old entries age out naturally without ever exceeding what the provider currently reports as available? Probably a minor detail, but it affects whether the retention logic runs on every refresh or just on insert.
Happy to help test once EPG mapping/caching lands — I don't have a Stalker portal handy, but if it'd help I can dig up an Xtream provider with a short retention window (~24h) to check the edge case above.

[WolfganP]

Good idea to use the provider params to adjust the merge window. But as always with these "prone to fail" providers, if the EPG information gets corrupted, a full/hard refresh path override should be implemented (maybe in the settings page have a button to reset EPG info and reload all again?).

BTW, I'm still seeing catch-up availability for the same channel being treated differently in Live TV vs Favorites tab #1138 in the latest dev versions