Catch-up and timeshift: what they are and why your window is shorter than advertised

Three words get used for overlapping things. Separate them first.

Timeshift is pausing or rewinding a live stream you are currently watching. Catch-up is opening a programme that finished earlier from your provider's archive. Recording is capturing a stream to a file on your own machine.

They are implemented differently, they fail differently, and only one of them is entirely within your control.

Why you cannot usually rewind a live stream#

Start with the one people expect to work and which mostly does not.

A live IPTV stream, in its normal shape, is a single HTTP response that never ends. There is no length. There is no index. The server is writing bytes and the player is reading them, and neither of them has any notion of a position 10 minutes ago because nothing kept it.

The client's own gate for live seeking reflects that precisely: the player must report the stream as seekable and a positive length must be available. Both have to hold. The transport is not an input at all.

The test that covers this carries the honest comment: a typical live transport stream may have a demuxer that claims seekable while there is no length to scrub against. A claim without a length is not a capability.

Some providers do offer a rewindable live window. Where they do, it is implemented as the archive rather than as a property of the live stream, which brings us to the mechanism that matters.

How catch-up actually works#

A provider that keeps an archive is recording its own channels, continuously, into storage on their side. Your client does not stream from a saved file with a name; it asks for a slice of the channel's timeline.

The structural fact is that the client constructs that request. No per-programme URL is delivered anywhere. The builder takes a channel, a start time and a duration, and produces an address:

live      http://line.example.com:8080/user/pass/12345.ts
catch-up  http://line.example.com:8080/timeshift/user/pass/120/2026-08-30:21-00/12345.ts
                                                  ^^^  ^^^^^^^^^^^^^^^^^^^^
                                                  minutes    start, local time

Two consequences follow, and both explain reports that otherwise look like bugs.

A portal that supports archives but uses a different path layout will receive a request for an address that does not exist there. From the sofa that looks like a missing programme rather than a wrong URL.

And the start time and duration come from a programme row. So catch-up depends on the guide, entirely.

The reason your window is shorter than advertised#

Your provider says 7 days. You can reach 2. Nothing is broken and nobody is lying.

A catch-up entry is materialised from a programme row in your guide. A programme your guide no longer holds has no row, and therefore nothing to open. So the reachable depth is whichever is smaller: the provider's archive window, or your guide retention.

Guide retention is not accidental either. The parser keeps 8 days forward and 1 day back by default, clamped at 14 and 7, and it drops programmes outside that window during the parse rather than storing them and pruning later. A guide publishing 14 days into a client keeping 8 is not losing data through a fault.

provider archive   7 days back
guide retention    1 day back  (default)
reachable          1 day back

So if your catch-up window is disappointing, the thing to extend is guide retention, not an archive setting. That surprised me the first time I traced a 7 day claim down to a 1 day window: the natural place to look is an archive setting, and the limit lives in the guide parser. It is the single most useful thing in this article.

What is built and what is not#

Catch-up shipped on the desktop head first, with its own catalogue schema version. The console page is named as outstanding work, along with resume positions and flag re-sync. So on an Xbox today you get live channels and the schedule, and the rewind is in the Windows app. Catch-up TV on Xbox says what to do in the meantime.

The intended cascade, where archive behaviour is decided per source, then per channel, then not at all, is half built. The URL materialisation ships. The settings surface for choosing between those levels does not.

Recording, which is the part you control#

Everything above depends on your provider keeping something. Recording does not.

Scheduling from the guide is complete, and the scheduler is careful about the thing that most often ruins a recording: guide times are approximate in a way archive slices are not. A guide recording applies an automatic margin of 2 percent of the programme's duration, clamped to between 1 and 5 minutes, at each end:

programme     margin (2% of duration, clamped to 1..5 minutes)
30 minutes    1 minute      (0.6 rounded up to the floor)
40 minutes    1 minute
2 hours       2.4 minutes
3 hours       5 minutes     (3.6 would be 3.6, the ceiling binds at longer runs)

A finished recording carries a frame extracted from itself as its thumbnail, rather than the channel logo, so a list of recordings is scannable.

Two properties of recordings are deliberate rather than incidental.

Recordings are local files on the client that made them. The server holds no recording data at all: there is no recordings family in the sync model and no recording types in the catalogue service. Server-side recording management was removed as a goal rather than postponed, because an index of what you recorded is knowledge of what you watch, and holding it would make the service content aware. That is a line this product does not cross, and cloud DVR is a permanent non-goal under the same rule.

And a live capture cannot report progress as a percentage, because the input duration is unknown. That is the same fact that makes live seeking impossible, showing up in a different place. A recording in progress can tell you how long it has been running. It cannot tell you how far through it is, because there is no end to measure against.

What recording actually does to the stream#

A recording is a remux, not a re-encode. The capture engine drives FFmpeg to copy the elementary streams out of the live transport and into a file, without decoding or re-compressing anything. The picture in the file is bit-for-bit the picture that was broadcast.

Two consequences follow directly.

It costs almost nothing. There is no decode and no encode, just demux and mux, so recording a 4K channel does not load the machine the way playing it does. You can record while watching something else.

And there are no quality settings, because there is no quality decision to make. A recording is exactly as good as the stream, and no better. If the channel is a soft 1080p upscale, so is the file. Recording quality presets appear on our own remaining-work list, and what they would actually control is a re-encode, which is a different feature with a different cost.

One practical prerequisite: FFmpeg has to be resolvable. If it is not present, the capture returns a not-found error rather than failing silently partway through.

Where recordings go#

Two backends ship: local disk and an SMB network share, with a connection test for the second so you find out that credentials are wrong before a recording rather than after one.

An SMB target is the right answer for a household with a NAS, and it changes the arithmetic considerably. Live television at broadcast bitrates is a few gigabytes an hour. A season of anything fills a laptop quickly.

A cloud backend is not implemented and, for the boundary reason above, is not planned either.

The gap in scheduling#

Individual recordings from the guide work. Recurring and series recording does not exist.

So "record every episode of this" is not something you can ask for today; each episode is scheduled separately from the guide. That is the largest single gap in this area of the product, and worth knowing before you plan a workflow around it.

The connection cost nobody budgets for#

One thing catches households out, and it applies to all 3 of these mechanisms equally.

Catch-up is a stream. Recording is a stream. Both consume a provider connection for as long as they run, exactly as live viewing does. A line permitting 2 connections, with 1 recording in progress, has 1 left.

That is why a recording scheduled for the evening can quietly prevent someone else watching, and why two overlapping recordings on a 2 connection line means nobody watches anything. The recording side of connection awareness is on our remaining-work list, so the app does not currently warn you about that collision before it happens. Max connections covers the accounting, including why a connection can stay spent after a stream stops.

Which to use#

If the programme has already aired and your provider has an archive, use catch-up, and expect the reachable window to be bounded by your guide rather than by the provider's claim.

If the programme has not aired yet, record it. It does not expire when the provider's window rolls over, and it does not depend on guide retention after the fact. It is a file you own.

If you want to pause live television, the honest answer is that you usually cannot, and the reason is structural rather than a missing feature. MPEG-TS or HLS covers what a live stream is and why a position in one is not a thing that exists.