Allow the use of catch-up when using proxy

[djrarky]

When the proxy is disabled, I can rewind live tv, and use catch-up functionality by going backwards in the guide, however with proxy enabled, I'm unable to do so.

Is it possible to enable this functionality when the proxy is in use?

[sparkison]

I'm not sure this is possible? At least not without implementing buffering (I think). Going to close, but if anyone has ideas around how to do this, let me know! I'm open to it, just not sure how to do it without complicating the current proxy functionality.

[djrarky]

Hey mate, is it possible to re-open?
As discussed on discord, tivimate etc sends time stamp headers to the provider who stream the catch-up media.

Not looking for any local caching or rewind - that could be done on the player.

Thanks so much!

[sparkison]

re-opened! 😉
...although still not exactly sure how to make this work? If anybody know what's missing I'm open!

[djrarky]

I think I've found what's causing it, the following isn't being proxied

#EXTINF:-1 catchup="append" catchup-source="?utc=$utc&duration=3600" tvg-name="Channel" tvg-id="ch1" ...

[sparkison]

I think I've found what's causing it, the following isn't being proxied

#EXTINF:-1 catchup="append" catchup-source="?utc=$utc&duration=3600" tvg-name="Channel" tvg-id="ch1" ...

nice find! I can work with that 😉

I'll let you know when I have something for you to test...

[sparkison]

potential fix in latest dev release! Let me know how it works for you when you get a chance to test

P.S. You will need to re-sync the playlist for the catchup fields to be captured and saved to the respective channels.

[djrarky]

Hey mate, sadly that didn't work.

I have no clue what I'm doing, but dug into this a little.

My provider is using Xtream, and the following script shows me which channels are offering catch-up.

import json

# Your Xtream Codes details
xtream_url = "[url]"
username = "[username]"
password = "[password]"

# Get live streams list
response = requests.get(f"{xtream_url}/player_api.php", params={
    "username": username,
    "password": password,
    "action": "get_live_streams"
})
channels = response.json()

print("📺 Channels with Catch-Up Enabled:\n")
for ch in channels:
    if ch.get("tv_archive") == 1:
        print(f"Name: {ch['name']}")
        print(f"Stream ID: {ch['stream_id']}")
        print(f"EPG ID: {ch['epg_channel_id']}")
        print(f"Has Catch-Up: ✅\n")

Not sure why this is working with proxy disabled, but doesn't when enabled - I'm assuming the API requests from tivimate should work whether proxied or not.

But, I've got pretty far understanding how this is working in tivimate with the proxy disabled/provider as source.

1. Tivimate first makes request to CDN (Tivimate already knows the channel is catch-up enabled)
   GET /timeshift/{username}/{password}/{stream_id}/{start_time}/{duration}.ts HTTP/1.1
example: http://[hostname]/timeshift/[username]/[password]/30/202505052030/1800.m3u8

2. The server responds:

   302 Redirect

   Sends back a new URL with ?token=...&id=...
   Tivimate follows that redirect to the actual video segment

Hopefully that's all proxiable! But that's definitely beyond me. Can't thank you enough mate.

[sparkison]

Not sure why this is working with proxy disabled, but doesn't when enabled - I'm assuming the API requests from tivimate should work whether proxied or not.

it's probably because of this:

The server responds:

302 Redirect

Sends back a new URL with ?token=...&id=...
Tivimate follows that redirect to the actual video segment

I'm still not fully understanding this though?

When we proxy, we're just playing the generated stream URL via ffmpeg and re-streaming the output to the client directly. So ffmpeg will play the URL like: http://[hostname:port]/live/[username]/[password]/{ch.stream_id}.{ch.container_extension} and send results directly to the client.

The update I made was for the m3u playlist type, so it makes sense why it didn't work. I didn't realize you were using Xtream. That said, I can see the code sample you sent it's using the tv_archive variable to determine if catchup is enabled, but I can't tell how the stream URL is generated beyond that? Is there more to this code? A larger sample would be appreciated 🙏

[djrarky]

Appreciate it mate.

I've sent you a pcap via discord. I spent a long time trying to figure out how Tivimate figures out the {duration}.ts part of the string to request from the provider - I gave up by 2am and hit the hay.
But, I don't think that should matter right - we should just let tivimate know that the channels are catch-up aware right?

m3u4u take the Xtreme codes and spit out an m3u file for tivimate to use - and tivimate is still catch-up aware. Same with m3u-editor, with proxy disabled.

I'm wondering if it's possible to proxy those http requests?
I'll scrap the tivimate config tonight, and take a tcpdump of the full setup / playlist download etc, hopefully that gives more answers :)
Be sick if it can be figured out!!

[sparkison]

Moving this one to a discussion since it's still ongoing...

[djrarky]

Appreciate your help with this mate.

Gone a little further. I've got a solution that kinda works, but has issues because we're optimising for live content.

The following snippet in HlsStreamController.php works after line 60.

        /* ─── Timeshift handling ──────────────────────────────────────────── */
        if ($request->filled('utc')) {
            $utc  = (int) $request->query('utc');
            $lutc = (int) ($request->query('lutc') ?? time());

            $offset = max(1, intdiv($lutc - $utc, 60));          // minutes
            $stamp  = gmdate('Y-m-d:H-i', $utc);                 // 2025-06-13:20-00

            // helper that converts “…/live/u/p/<tail>” → “…/timeshift/u/p/<offset>/<stamp>/<tail>”
            $toTimeshift = function (string $url) use ($offset, $stamp): string {
                return preg_replace(
                    '~/live/([^/]+)/([^/]+)/(.*)$~',
                    "/timeshift/$1/$2/$offset/$stamp/$3",
                    $url
                );
            };

            /* primary channel */
            $channel->url_custom = $toTimeshift($channel->url_custom ?: $channel->url);

            foreach ($channel->failoverChannels as $f) {
                $f->url_custom = $toTimeshift($f->url_custom ?: $f->url);
            }
        }
        /* ─────────────────────────────────────────────────────────────────── */

If I manually seek, it does now work. Takes a while for it to start playing the catch-up footage, sometimes it just continues playing the live stream in a loop. I think this is because m3u continues to serve the cached segments, and that the provider can take 30+ seconds to respond to the timeshift requests. I had to up the ffprobe timeout to 30s.

I'm guessing just some optimisations / catch-up logic needs implementing, perhaps for timeshift url's we can skip the ffprobe check?

[djrarky]

Submitted PR. #235

I dropped HLS segment duration and upped the timeout, definitely needs some optimisations.
I looked into adding a new class, but noticed after I'd done it the rewrite needs to be different between StreamController.php and HtsStreamController, then realised HLS probably isn't the way to go about it anyway - I'm wondering if it's possible to hide the catch-up handling for those using HLS?
22b8915

[djrarky]

Okay, so ofc that last one didn't work - this does.
#292

I managed to do it for StreamController, but not Hls, I found the segment cache was wayyy to slow for it to be interactive. I also had to increase the ffmpeg timeout as timeshift content takes much longer to respond - however this is working!!