Features
Catch-Up TV / Replay Functionality Explained
Catch-up depends on the provider retaining a recording window, not on the app.
Who owns the replay
The moment a programme finishes, whether it becomes available to replay is decided entirely on the provider's side. The provider allocates recording capacity, sets a retention window for each channel, and enforces whatever licencing restrictions apply to storing and replaying that content. The app is a client: it asks the provider what is available and renders what comes back.
This division of responsibility explains the most common catch-up frustration. A programme that aired yesterday is missing because the provider either never recorded it, already expired it, or was never licensed to keep it. No setting in a player app can recover a recording the source did not make.
It also explains why catch-up behaves differently from live streaming in one important respect. With live television, a blank screen is usually a connection problem you can influence from your side. With catch-up, the list itself is information owned upstream; you can improve your connection and still never see a programme that the provider decided not to keep.
How catch-up is actually delivered
Replay streams are usually delivered in one of two ways. True video-on-demand serves a stored file that starts from the beginning and plays to the end. Timeshift, by contrast, records the live broadcast continuously and lets you seek back through it; the same mechanism that lets you pause and rewind live television is what makes a short catch-up window possible.
- A stored copy of the programme, served like any on-demand video with start and end points.
- A timeshift buffer around the live stream, which gives a rolling window rather than a permanent library.
- An EPG-driven list that converts schedule metadata into replay entries, which is why the guide and the catch-up list are often built from the same source.
The distinction matters for expectations. A timeshift window is a short, rolling buffer: it is gone on a rolling basis whether you watched it or not. A stored library can last for days. Which model a given channel uses is set by the provider, and it varies by channel within the same service.
Delivery also affects data use. A timeshift replay of a live channel is streamed at the same bitrate as live, so watching an hour of replay costs roughly what watching an hour live costs. A stored copy may be encoded separately, sometimes at a lower bitrate, which is why replays can occasionally look slightly different from the original broadcast.
Why availability varies by channel
Providers do not treat every channel the same. A channel broadcasting live sport may offer no catch-up at all, because the rights to replay the event are expensive or held by someone else. A news channel may keep replays for hours; a general entertainment channel may keep them for days. This variation is a licencing and capacity decision, not a bug, and it is decided upstream of the app.
Because the catch-up list is assembled from schedule metadata, anything that breaks the guide can break replay visibility too. If the EPG feed stops updating, the app cannot know what was on, and the replay list quietly empties as the retained window expires. That is the same mechanism that empties the regular programme guide, and it is worth checking before you blame the app.
Geography matters as well. A provider's retention window can differ from one region to another because the licencing it holds differs by market. A programme available for seven days in one country may vanish after a few hours in another, and the app cannot reconcile that because it never had any control over the window in the first place.
Troubleshooting catch-up
| Symptom | Likely cause | What to do |
|---|---|---|
| Programme is not listed for replay | The provider did not retain it, the window expired, or the channel has no catch-up rights | Check the provider's own catch-up window rather than assuming the app is at fault |
| Replay plays from the start but will not seek | Timeshift delivery that only supports offset playback | Use the app's progress bar where available; seeking is limited by the delivery model |
| Replay appears only after a delay | The recording window lags behind the broadcast | Wait; confirm when the provider publishes replays for that channel |
| Audio out of sync on replay | A mismatch in the stored copy, upstream of the app | Report to the provider; nothing in the player can fix a corrupt stored file |
When replay does work but stutters, treat it as you would any on-demand stream: the replay is being served on demand and competes for the same bandwidth as everything else. A stored file does not buffer any less than live video, and seeking within it can force the player to renegotiate the variant it is using, which is a common cause of a brief stall after a jump.
What AK47 Sports reportedly provides
The developer advertises catch-up and replay functionality. The length of the window and the set of channels covered are not publicly documented, and both are ultimately controlled by the provider.
Users report that catch-up availability varies by provider and channel in AK47 Sports, which is consistent with a client that only displays what the source retains. We could not verify the feature across every build.
The practical conclusion is simple: treat catch-up as a property of the source, not of the app. If a programme is missing, first check the provider's own replay listing and the stated retention window, and only then consider the app as a possible cause. The app's job is to display a list; the provider's job is to have made the recording in the first place.
Worth knowing: Catch-up is a provider-side recording kept for a limited window; the app only lists what the source has retained, so a missing programme is usually a provider decision rather than an app fault.