Catch-up window sizing for IPTV restream operators
Catch-up TV sounds simple until the first busy weekend exposes the weak parts. A live channel is already moving through ingest, packaging, token checks, and CDN delivery. A catch-up window adds another job: keeping enough past segments available for viewers who start late, restart a program, or scrub back during a live event. If the window is too short, support gets complaints. If the window is too large, storage and origin requests grow faster than anyone budgeted.
For an IPTV restream operator, the right answer is not “keep everything.” The better question is which channels deserve catch-up, how long viewers actually use it, and what your origin can survive when thousands of active connections request old segments at the same time. HLS makes time-shifted playback possible, but the playlist, segment retention, cache rules, and authorization layer all need to agree.
This guide focuses on licensed IPTV restream operations where the operator controls the channel package, delivery path, and customer policy. The examples use HLS because it is the common path for device playback, but the same planning logic applies when your platform still supports MPEGTS for certain customers.
Start with the viewing policy, not the storage number
A catch-up feature needs a policy before it needs infrastructure. Some channels only need restart TV for the current program. Others may need a 24-hour replay window because viewers expect to catch evening news the next morning. Sports and premium channels may have tighter rights limits. The operations team should not decide this from a storage calculator alone.
Build the first version of the policy around four questions:
- Which channel packages are authorized for catch-up or restart playback?
- How many hours can each package keep available segments?
- Does the customer see a program guide entry, a restart button, or a simple rolling archive?
- What happens when a viewer tries to play content outside the allowed window?
The fourth question is where many teams get messy. A clean denial is better than a broken player. If the window has expired, return a predictable authorization response and a support-friendly message. Do not let the player request old segment URLs until it times out, because that looks like a network problem even when the policy is working.
RFC 8216, the HLS specification, defines playlists as ordered lists of media segments and includes tags such as EXT-X-MEDIA-SEQUENCE, EXT-X-DISCONTINUITY, and EXT-X-PROGRAM-DATE-TIME. Those tags matter for catch-up because the player and backend both need to map wall-clock time to the correct segment range. When program date time is missing or inconsistent, restart buttons can land viewers a few minutes early, a few minutes late, or on the wrong side of an ad break.
Calculate the window from bitrate and channel count
The rough storage math is not hard, but it needs to be done per package rather than across the whole platform. A 6 Mbps HD feed uses about 2.7 GB per hour before packaging overhead. Keep that channel for 24 hours and you are near 65 GB for one rendition. Add multiple renditions, audio tracks, and packaging files, and the practical number rises.
Here is a simple way to model the first pass. Treat the numbers as planning inputs, then confirm them against real segment output from your encoder or packager.
| Package type | Example retained window | Operational note |
|---|---|---|
| Basic news channels | 12 to 24 hours | Good candidate for rolling catch-up because viewers often replay recent bulletins. |
| Entertainment channels | 6 to 24 hours | Use program guide data so viewers restart the right show, not only a clock position. |
| Sports channels | Current event only or disabled | Check rights and blackout rules before enabling replay. |
| Regional channels | 4 to 12 hours | Start smaller until support demand proves that a larger archive pays for itself. |
Now add concurrency. A 24-hour window is cheap when only ten viewers use it. It becomes a different system when 2,000 viewers restart the same match at halftime. Old segments may be cacheable, but the first request for each segment in each region still has to come from somewhere. If your cache keys include short-lived token query strings, the CDN may treat each viewer as a separate object and push far more traffic back to origin than expected.
This is one of the most common catch-up failures I see in IPTV restream planning. The team sizes storage, confirms that the files exist, and launches. Then peak traffic arrives and origin load jumps because tokens, headers, or path rules prevent cache reuse. The fix is usually boring: normalize the cache key, keep authorization at the playlist or signed path layer, and test the exact URL pattern that customers will use.
Align playlist retention with token rules
Catch-up breaks when the playlist says one thing and the token system says another. A viewer may be allowed to replay the last 12 hours, but the token lifetime may be only 30 minutes. That can work if the player refreshes authorization while it plays. It fails if the player receives a static playlist full of segment URLs that expire before playback reaches them.
For IPTV restream token delivery, separate three time periods:
- Session authorization: how long the viewer is allowed to keep the playback session open.
- Playlist access: how often the player can refresh the catch-up playlist or request a time-bounded playlist.
- Segment access: how long each segment URL remains valid at the edge.
These periods do not need to match. In fact, they usually should not. A long segment token can leak too much access if a URL is copied. A very short token can interrupt legitimate viewing on devices that buffer slowly or sleep in the background. The safer pattern is a controlled session with playlist refresh and short enough segment access to reduce sharing risk.
Apple's HLS authoring guidance for Apple devices recommends predictable media segment behavior and clear playlist structure. The public HLS specification also says clients must use playlist tags to determine segment order and availability. In practice, that means your catch-up playlist should not be a giant unbounded file. Give the player the range it needs, keep media sequence values sane, and avoid surprising discontinuities unless the source actually changed.
Use program date time carefully
Program date time is useful because it gives the platform a time anchor. A viewer taps a program that started at 20:00, the backend maps that time to an HLS segment, and playback begins close to the expected point. That only works if the packager inserts accurate timestamps and handles source switches cleanly.
Clock drift creates small errors that become visible over long windows. A channel may start a program at 20:00 in the guide, but the first matching segment might map to 20:02:15. On a news channel, that may be annoying. On a sports channel, it can skip the kickoff or spoil the score. If your EPG source and stream timestamps disagree, the customer blames the app, not the clock chain.
During QA, pick a few programs and record the expected start time, actual first frame, playlist media sequence, and program date time. Then repeat the check after a source failover, encoder restart, or ad insertion break. The HLS EXT-X-DISCONTINUITY tag exists for a reason: clients need a signal when timestamp sequences or encoding characteristics change. If the discontinuity is missing, some devices keep playing while others stall or jump.
A practical IPTV restream catch-up test should include at least one low-end Android TV device, one iOS device, one browser player, and one set-top environment if your customers use it. Do not only test in a desktop player that tolerates timeline mistakes. The devices that complain first are usually the ones with stricter buffer and playlist behavior.
Protect origin during replay spikes
Catch-up traffic has a different shape than live traffic. Live viewers tend to request the same newest segments at the same time. Catch-up viewers scatter across the past window. That means the CDN cache hit rate can drop, especially when viewers restart different programs or scrub around.
Origin protection starts with retention tiers. Keep hot replay segments close to the edge for the first few hours. Push older segments to cheaper storage only if the retrieval delay does not hurt playback. If your platform offers a 24-hour window, the first two hours may handle most replay requests, while older content sees occasional access. Your cache and storage policy should reflect that pattern.
Cloud and CDN vendors publish different controls for cache TTL, signed URLs, and origin shielding, but the operational principle is the same: do not let every viewer become an origin request. Use origin shield where available, avoid cache-busting query strings, and test cache behavior with real signed playback URLs. A green result from an unsigned lab URL does not prove the production path is safe.
Set alerts that separate live and catch-up load. If both use the same origin dashboard, a replay spike can hide inside total egress until customers complain. Track playlist requests, media segment requests, cache hit ratio, 403 responses, 404 responses, and startup time for catch-up sessions. A sudden rise in 404s usually points to retention cleanup running too aggressively or playlist indexes pointing to segments that have already been removed.
Build the support workflow before launch
Support needs more than “try again.” Give agents a small set of fields they can ask for and verify: channel name, package, device, program time, customer region, error code, and whether live playback works on the same account. Those details quickly separate entitlement issues from delivery issues.
For example, if live playback works but replay fails only for one channel and one region, the likely causes are rights policy, geo-blocking, or missing retained segments for that package. If replay fails across many channels after 30 minutes, token refresh is a better suspect. If one device family starts late while others start correctly, look at playlist interpretation and program date time handling.
Publish the feature in stages. Start with a small channel group, a short window, and internal customers or friendly accounts. Watch the logs for at least one peak period. Then widen the window or add packages. This is slower than flipping one global setting, but it prevents a half-working catch-up feature from becoming a week of support tickets.
If you need connection-based IPTV restreaming with secure HLS delivery, active connection control, and practical channel package support, review the IPTV restream provider page or compare options on IPTV restream pricing. The best catch-up rollout is the one your operations team can explain, monitor, and roll back without guessing.