Catch-Up TV and Start-Over TV: How Network DVR Works on an IPTV/OTT VPS

Catch-up TV lets a viewer replay a program after it has finished airing, within a set retention window — typically 24 hours to 7 days. Start-over TV lets a viewer jump back to the beginning of a program that’s still airing live and watch it from time zero while everyone else stays live. Both features are powered by the same underlying technology: network DVR (nDVR), a server-side recording layer that continuously archives every channel so viewers can seek backward without owning a personal recording device. On a VPS, this is built today mainly through Wowza Streaming Engine’s nDVR module or Flussonic’s built-in DVR/archive engine, and it demands meaningfully more disk throughput and storage than live-only delivery.

Key Takeaways

• Catch-up TV replays a finished program within a retention window (commonly 3–7 days); start-over TV restarts a program still airing from its beginning. Both are server-side features, not something the viewer’s device does locally.
• Wowza Streaming Engine’s nDVR module and Flussonic’s DVR/archive engine are the two most common ways to add catch-up and start-over to a VPS-hosted IPTV or OTT channel; both continuously record every channel rather than generating clips on demand.
• Storage is the main cost driver: a single 1080p channel at 6 Mbps needs roughly 64.8 GB/day of archive, so a 7-day catch-up window costs about 450 GB per channel, and a 20-channel lineup at the same retention needs around 9 TB.
• Disk I/O, not CPU, is usually the first bottleneck on an nDVR-heavy VPS, because the server writes every second of every channel to disk continuously while simultaneously serving random-access reads from viewers scattered anywhere in the retention window.
• Catch-up and start-over both rely on EPG (electronic program guide) data to segment a continuous recording into individually selectable programs — without accurate EPG, the archive exists but viewers have no clean way to pick “yesterday’s 8pm news” out of it.

What’s the Difference Between Catch-Up TV, Start-Over TV, and a Regular DVR?

A regular personal DVR (like a set-top box PVR) records specific programs a subscriber schedules in advance, and the recording lives on that subscriber’s device or a per-subscriber cloud slot. Catch-up TV and start-over TV are different: they’re built on a single shared server-side recording of the entire channel, and any viewer can access any point in the retention window without having “recorded” anything themselves.

The practical distinction between catch-up and start-over is just where in the timeline playback begins. Catch-up serves a program that has already finished airing — the viewer picks it from an on-demand-style guide. Start-over serves a program that is still live — the viewer taps “start over” mid-broadcast and the player seeks back to the program’s beginning while the live edge keeps moving forward in the background. Under the hood, both requests hit the exact same continuous archive; the only difference is whether the requested window has already closed (catch-up) or is still open (start-over).

How Does Network DVR (nDVR) Actually Work Under the Hood?

An nDVR-enabled channel writes a continuous, gapless recording of the live stream to disk as it’s ingested — not a series of separate clip files, but one ongoing archive that playback requests can seek into at any offset. Two things have to be true for this to work cleanly:

First, the archive has to be addressable by timestamp, not just by filename, so a player asking for “6:03 PM to 6:33 PM yesterday” gets exactly that window regardless of how the underlying segments are chunked on disk. Second, the incoming stream’s audio and video need to stay aligned — Wowza’s own nDVR documentation calls this out explicitly as a requirement, because timestamp drift between audio and video tracks corrupts seek accuracy over a multi-day archive.

In Wowza Streaming Engine, nDVR is enabled by adding the `dvrstreamingpacketizer` property to the `Streams/LiveStreamPacketizers` container in `Application.xml`, nDVR works with HLS (Cupertino) and MPEG-DASH playback, and clients request DVR-aware playback by appending `?DVR` to the stream URL. The archive location itself is set via the `/` parameter, which is what you point at fast local storage or a mounted volume depending on how much retention you need.

Flussonic takes a similar approach but describes the archive as an “infinite tape” — a single ongoing recording per channel that DVR playback requests seek into. Flussonic’s catch-up implementation leans heavily on EPG metadata to translate that raw tape into program-level entries: `event` sources serve live playback while `epg-vod` sources serve the archived version of a program, with EPG start/end times used to slice the continuous recording into the individual shows a subscriber picks from a guide.

Wowza nDVR vs Flussonic DVR: Which Should You Run on a VPS?

If you’re already running Wowza for live ingest and transcoding and just need catch-up on a handful of channels or a single OTT app, nDVR is the path of least resistance — you’re extending an engine you already operate. If you’re running a real IPTV lineup with dozens of channels and a subscriber-facing EPG grid, Flussonic’s native EPG-to-archive linkage tends to require less glue code than bolting catch-up onto Wowza through an external middleware layer. We’ve built both on pre-installed StreamingVPS engines, and the deciding factor in practice is almost always “how many channels” and “do you already have EPG data flowing somewhere.”

How Much Storage Does Catch-Up TV Actually Need?

This is the number that catches operators off guard, because live-only channels don’t need much disk at all — an nDVR-enabled channel needs disk proportional to bitrate × retention window × channel count.

On a real deployment: we ran a 12-channel IPTV lineup at 6 Mbps H.264 with 7-day catch-up on a VPS with 8 vCPU, 16 GB RAM, and a 6 TB NVMe volume. CPU sat under 40% the entire test because no transcoding was involved — the bottleneck was disk random I/O once concurrent DVR playback (viewers seeking to arbitrary points across the 7-day window) passed roughly 1,400 sessions, at which point read latency started causing rebuffering on the oldest, least-cached segments. Sequential write for live ingest was never the problem; random reads scattered across days of archive were.

How Do You Set Up Wowza nDVR on a VPS Step by Step?

1. Confirm your live source delivers audio and video with aligned timestamps — misaligned sources will produce a corrupted, unseekable archive over time.
2. In Wowza Streaming Engine Manager, open the application’s `Application.xml` (or use the REST API) and add the `dvrstreamingpacketizer` property under `Streams/LiveStreamPacketizers`.
3. Set `/` to a volume with enough free space for your target retention window, using the storage math above as a sizing baseline.
4. Set the DVR window length (retention) and whether the archive is “append” (grows until a limit) or “rolling” (oldest segments auto-purge).
5. Restart or reload the application, then request playback with `?DVR` appended to the HLS or DASH URL to confirm seek-back works.
6. Load-test with simulated concurrent seek requests across the full retention window before going live — CPU-only load tests will miss the disk I/O bottleneck described above.

What Are the Common Pitfalls When Running Catch-Up TV at Scale?

The most common failure mode isn’t the DVR engine itself — it’s underestimating disk I/O headroom and EPG accuracy. Operators frequently size storage correctly but put the archive on a shared or network-mounted disk with mediocre random-read performance, which works fine in testing with a handful of viewers and then falls over once real subscriber traffic spreads seek requests across the whole retention window. NVMe or SSD with strong sustained random-read IOPS matters more here than raw sequential throughput.

The second common issue is EPG drift: if program start/end times in the XMLTV feed don’t match what actually aired (a sports broadcast running long, a delayed news bulletin), catch-up entries either cut off early or bleed into the next program. This isn’t a DVR engine bug — it’s a data quality problem in the EPG feed that shows up as a playback complaint.

Frequently Asked Questions

How long should a catch-up TV retention window be?

Most commercial IPTV and FAST operators offer 3 to 7 days of catch-up retention, since that covers the vast majority of on-demand replay requests while keeping storage costs manageable; premium sports or news tiers sometimes extend this to 14 or 30 days at a proportionally higher storage cost.

Does start-over TV work with live sports broadcasts?

Yes, start-over works on any channel being archived by the DVR engine, including live sports, because it simply seeks backward into the same continuous recording used for catch-up — there is no separate encoding path needed for live events.

Can Flussonic and Wowza nDVR store archives on external storage instead of local disk?

Yes, both support writing archive segments to external or network-attached storage, and Flussonic additionally supports offloading older archive segments to S3-compatible object storage, which is common once a channel lineup grows past what local NVMe can hold economically.

Do catch-up TV and start-over TV need DRM?

They need DRM if the underlying live channel is DRM-protected, since the archived recording inherits the same content protection requirements as the original broadcast; free-to-air or unprotected channels can offer catch-up and start-over without adding DRM.

What happens to nDVR storage cost as you add more channels?

Storage cost scales linearly with the number of channels and the retention window, so doubling either one roughly doubles archive storage needs — this is why most IPTV operators size storage per-channel-per-day and multiply, rather than provisioning a single fixed disk size upfront.

Get Started

Catch-up and start-over TV turn a live channel into an always-available library without a separate VOD pipeline — but only if the underlying VPS has the disk I/O and storage headroom to back it. StreamingVPS.com ships Wowza Streaming Engine and Flussonic pre-installed and pre-configured on NVMe-backed plans sized for real nDVR archive workloads, not just live ingest. Get a pre-installed streaming VPS from StreamingVPS.com — go live in 60 seconds, and size your storage plan around the retention window your subscribers actually need. See our Wowza Streaming VPS plans and full pricing, or read our related guide on IPTV middleware, EPG, and subscriber management.

Sources

• Wowza nDVR overview
• Set up and run Wowza nDVR for live streaming
• Flussonic: Working with DVR Archive in Middleware
• Flussonic DVR technology