Catchup not working after M3UEditor Processing

[McChafist]

Describe the bug

I have an m3U file where some of the channels support Catchup
When I process the same m3u file via M3UEditor, none of my IPTV apps recognise that catchup is available.

To Reproduce

Steps to reproduce the behavior:

Add M3U URL to M3UEditor and process.
Add output M3U URL to IPTV app
Observe catchup is not available

Expected behavior

Catchup should be available on the same channels as before processing

Actual behavior

Catchup is unavailable.
I've tried Tivimate and Android TV, MyTVOnline Android app and IPTV Expert on Windows all with the same result

Screenshots

docker-compose.yml contents

# docker-compose.yml contents here

Container/Host Logs

<!-- Insert logs here -->

Additional context

I have compared the original and processed m3U file and see the following

-- Original
#EXTINF:-1 tvg-id="BBCOneOxford.uk" tvg-name="UK: BBC ONE LONDON 4K ◉" tvg-logo="http://icon-tmdb.me/stalker_portal/misc/logos/320/11987.jpg?90172" group-title="UK| GENERAL ᴴᴰ/ᴿᴬᵂ",UK: BBC ONE LONDON 4K ◉ http://domainname:80/username/password/497001

--Post Procesing
#EXTINF:-1 catchup="1" tvg-chno="2" tvg-id="BBCOneOxford.uk" tvg-name="UK: BBC ONE LONDON 4K ◉" tvg-logo="http://icon-tmdb.me/stalker_portal/misc/logos/320/11987.jpg?90172" group-title="UK| GENERAL ᴴᴰ/ᴿᴬᵂ",UK: BBC ONE LONDON 4K ◉ http://domainname/live/username/password/497001.ts

Note, the latter has a catchup tag but is the one where catchup is ignored. I suspect the addition of "live" to the output URL is causing the problem.

I can provide a working M3U source to test if needed

[mikhoul]

Was looking to deploy this project but found your issue and I need the catch-up so I made some ressearch:

The /live/ prefix is defined in the Laravel route declaration. In routes/web.php you’ll find:

Route::get('/live/{playlist}/{channel}', [\App\Http\Controllers\StreamController::class, 'stream'])
     ->name('live');

The /live/ proxy in m3u-editor serves to turn all upstream stream URLs into requests that pass through the application, rather than exposing the raw source URLs directly. Practically, this offers:

Access control and security
By routing every stream through /live/..., Laravel’s authentication middleware can enforce that only logged-in users (or API-tokened scripts) fetch streams—preventing unauthorized direct access to your provider’s URLs.

Centralized caching, throttling, and logging
Applying Laravel middleware on /live/... lets you cache segments, rate-limit per-client requests, and record usage stats for all streams in one place.

URL abstraction and flexibility
Client playlists always point to your server’s /live/{playlist}/{channel}. If an upstream URL changes, you update it once in the database; clients needn’t update their playlists.

Catch-up streams typically require dynamic query parameters (e.g. start, end, or placeholders like ${start}) embedded in the original URL. When m3u-editor proxies via /live/, it fetches and re-serves a fixed URL stored in the DB—losing those dynamic placeholders. As a result, catch-up requests never carry the correct time parameters, so the upstream service returns only live content.

In short: proxying through /live/ provides security, logging, and abstraction benefits, but it strips or fails to forward the catch-up time parameters. To fix this, m3u-editor’s StreamController would need to preserve and forward those dynamic placeholders (or reconstruct the query string) when generating its proxied request for catch-up channels.

For my use I only need pure playlist/EPG editing (merge, hide, reorder, group, update EPG). I don't know if there could be a toggle switch implemented to disable the proxy layer for users like me that don't need it since I don't use DVR @sparkison ?

Regards 😺

[McChafist]

So is the addition of "live" only need to support playlist authentication?

I am not using any authentication (or proxying the streams) so ideally the original m3u stream links should be preserved in this case.

[mikhoul]

So is the addition of "live" only need to support playlist authentication?

I am not using any authentication (or proxying the streams) so ideally the original m3u stream links should be preserved in this case.

It could, I'm not familiar with proxy in the IPTV context, the main thing I know it's for various purposes including authentification it regenerate the URL's to be compatible with DVR setup.

If @sparkison don't implement a switch/toogle to bypass the proxy maybe later after the summer I could fork it and try to remove the proxy layer to only keep the editing parts to use with IPTV players like TiviMate.

I'd like to be able to not rely entirely on M3U4U to manage/edit my playlists and EPG but with a similar friendly GUI with drag and drop to reorder things.

[sparkison]

Catchup has been a struggle to get working with the proxy. We had a contributor that got close, but wasn't able to get it fully implemented.

The /live url is used for the Xtream API and compatibility, so as of now that is required. But thinking that's not the real issue here, the real problem is what @mikhoul outlined and the need to be able to forward the query parameters and make dynamic url replacements before completing the upstream request.

[sparkison]

Going to move this one to a discussion, since it's not really a bug, but a known limitation of the proxy functionality. It's something I'm aware and working on, so hopefully have something in the near future 😉

[McChafist]

@sparkison But this issue is not really related to streaming through the proxy. I just want to host the m3u file locally which provides the links and continue to stream from the original source.

Although m3uEditor creates the correct ordering of channels in the output m3u file, it seems to also alter the streaming URL which isn't needed. The new URL still works for direct streaming but IPTV players fail to recognize catch-up is available.

When proxy is not used, could the original channel URL be left as per the input?

[djrarky]

I recon I know how to finish this and get it working.

Sorry, I just haven't the time at the moment. I get back home mid August and will definitely revisit it then.

This is where I got to so far, works only with MPEG-TS, the way HLS works it's not really possible.
The only bit that needs working out is the logic behind the timestamps. This works, but streams are two hours out. Eg. Ask for 4pm and you'll get the stream from 2pm.
https://github.com/djrarky/m3u-editor/tree/broken/timeshift-support

My parents are on my case about it, will get to it.

[McChafist]

Are you referring to the proxy streaming scenario? I am talking about non-proxied streams. As that is streamed directly from the source, if the original stream URLs were preserved it should also preserve catchup. However as the URL is altered slightl;y it gets lost.

[sparkison]

I see what you're saying @McChafist!

I'm just realizing this is related to Xtream API playlist import since we have to compose the URL to import.
You mentioned the provider URL looks like: http://domainname:80/username/password/497001, where did that come from? Is the direct_source key set in the API response from your provider? Wondering if maybe that's the piece I'm missing...

[McChafist]

The provider provides both xtream API and an m3u file. IPTV apps recognize all the channels that support catch-up when either source is used. That URL can direct from the source m3u.

The URL outputted from m3ueditor is different (not sure why) when using the m3u source and is not recognized for catch-up by IPTV apps.

[McChafist]

I see what you're saying @McChafist!

I'm just realizing this is related to Xtream API playlist import since we have to compose the URL to import.
You mentioned the provider URL looks like: http://domainname:80/username/password/497001, where did that come from? Is the direct_source key set in the API response from your provider? Wondering if maybe that's the piece I'm missing...

Strangely, I've just retried the m3ueditor output on tivimate and the enigma2 m3uiptv plugin and both now report channels with catch-up. It's very strange as I'm still using the same version of m3ueditor. Maybe my provider has changed something.

Either way it's working now so not an issue for me anymore