Two mechanisms hide behind the same phrase. Catch-up is server-side: the operator keeps a rolling window of a channel, commonly three to seven days, and your player requests a past time slot instead of the live edge. You store nothing, you own nothing, and when the window rolls past, the program is gone. Recording is client-side: your player app opens the same stream, writes the incoming segments to a file, and stops on a timer. That file lives on your storage and survives canceling anything. Ask which one a service means, because a page that says DVR and delivers a seven-day replay window is not lying, it is just answering a different question than the one you asked.

1. 1Catch-up: no file, fixed window, zero storage on your side
2. 2Recording: a real file, your storage, your retention
3. 3A rolling window that already passed cannot be recovered later

A recording is the stream written to disk, so file size follows bitrate, not resolution labels. A 1080p feed at 5-8 Mbps lands near 3 GB per hour. A 4K feed at 15-25 Mbps lands near 7 GB per hour. HEVC needs about half the bitrate of H.264 for comparable output, so an HEVC 1080p feed can land closer to 1.5-2 GB per hour while looking the same. Run the multiplication before you buy a drive: a 2 TB USB disk is roughly 660 hours of 1080p or 285 hours of 4K, and a household recording two hours a day at 4K fills it in about five months. Nothing about IPTV DVR changes that arithmetic.

1. 11080p H.264: ~3 GB/h. 4K: ~7 GB/h
2. 2HEVC roughly halves the bitrate, so roughly halves the file
3. 3Compute hours, not gigabytes, when sizing a drive

Because the schedule comes from EPG data, and EPG data is a claim about when a program will air, not a signal from the broadcast itself. Guide times drift, live events overrun, and a filler segment shifts everything after it. Player apps expose start and end padding for exactly this reason; two to five minutes on each side absorbs most of the drift. Recordings that stop after 15 seconds or die at the 20-minute mark are a different fault: that pattern points at storage permissions, a full disk, or a connection limit being hit mid-recording, not at padding. Check the file size against the expected gigabytes per hour and you can tell the two apart immediately.

1. 1Set 2-5 minutes of padding at both ends
2. 2A truncated file with a plausible size means the schedule was wrong
3. 3A tiny file means storage or session failed, not the guide

Yes, and this is the limit most guides skip. A recording opens a stream exactly like watching does, so recording one channel while somebody watches another is two connections, and two recordings plus a viewer is three. On IP4KTV, plans run 1 to 5 simultaneous connections, so the number you pick is really a decision about how many things can happen at once, not just how many televisions you own. Bandwidth stacks the same way: two 4K sessions at 15-25 Mbps each want 30-50 Mbps of sustained throughput. Installs are unlimited, so the app can sit on every device in the house, but the connection count is what governs concurrency.

1. 1Recording + watching = two connections
2. 2Two 4K sessions want roughly 30-50 Mbps sustained
3. 3Unlimited installs, 1-5 concurrent streams by plan

Some failures are upstream and honest guides say so. If the source feed stalls during your scheduled window, your player writes whatever arrives and the gap is in the file forever. A live stream is delivered as roughly six-second segments, so a stall longer than the buffer becomes a visible break rather than something the app can paper over. No buffer setting, no DNS change and no faster router repairs a feed that was not sending. That is why uptime is a recording spec, not a marketing line: IP4KTV runs 99.99%, which is about 53 minutes of downtime across a whole year, and 53 minutes is the honest worst case for how much scheduled recording could be affected.

1. 1Streams arrive as ~6-second segments; a longer stall shows as a gap
2. 2Ask any service for a stated uptime figure before you rely on scheduling
3. 399.99% = ~53 minutes a year, not zero