Live CCTV Works but Playback Fails: What to Check

When live CCTV works but recorded footage will not play, the camera and the network are already proven. The fault sits in what playback adds: footage that must exist for that hour, a recorder clock that must be right, a request with a time range, a limited playback session, and a separate permission. Check them in that order.

That order matters because the first two are the most common and the cheapest to rule out. The last three are where integrations with third-party software usually stall, and they are invisible from the recorder's own screen.

Why can live video work while playback fails?

Live video and playback travel different roads. Live video is a continuous stream: the viewer asks for a channel, and the recorder (the NVR, the box that stores the cameras' video) passes it along. Playback is a search. The viewer asks for a time range, the recorder looks it up on its disks, opens a separate session, checks whether this user may see old footage, and only then starts sending.

A working live view therefore tells you nothing about any of the five boxes on the right. Each has failed on real sites, and each has its own symptom.

Is there actually footage for that hour?

Open the recorder's own timeline or calendar before blaming any software. If the hour you want is empty there, no viewer can play it. The usual causes are a schedule that records only on motion, a disk error that stopped recording, or footage already overwritten because retention was shorter than everyone assumed. Retention is covered in why 30 days of CCTV storage rarely means 30 days.

Sometimes footage exists but looks broken. During a field test on one site in September 2026, a recorder was configured to save roughly one frame every eight seconds, about 0.13 frames per second, to stretch its disks. Playback worked perfectly and looked like a slideshow. That is a recording setting, not a playback fault, and fixing it means a decision about storage, not software.

Is the recorder's clock right?

Playback is a search by time, so a wrong clock looks exactly like missing footage. On the same site, the recorder's clock ran 1 hour 27 minutes ahead. It was set to sync with an internet time server through NTP (the protocol devices use to set their clocks automatically), but the CCTV network had no internet, so every sync failed silently.

The effect is easy to miss. At 10:00 real time, that recorder labelled its video 11:27. An operator who typed "10:00" into the search got footage that was really from 08:33, and reported that the incident "was not recorded".

Time zones add a second trap. The ONVIF standard for searching recordings requires all times in UTC, the world reference time that Western Indonesia runs seven hours ahead of, marked with a "Z", in both requests and responses (ONVIF Recording Search Specification, version 26.06, June 2026). Many recorders' own interfaces use local time without any zone. Software that mixes the two shifts every search by seven hours in Western Indonesia.

Two fixes work together:

• Give the recorders a time source they can reach: an NTP server on the CCTV network itself, or the site's router if it offers one.
• In integration software, read each recorder's clock periodically, keep the offset, and convert every search and every timeline. The system I built reads it at most every ten minutes, and the offset falls back to zero once the recorder is corrected.

Before changing a recorder's clock, write down the displayed time, the real time, the time zone, and the NTP setting. A clock change can leave gaps or overlaps in the recording timeline, as this recorder date-and-time guide from Security Wholesalers warns.

Does the software ask for playback the way this recorder expects?

This is where third-party viewers and video analytics systems fail most often, while the recorder's own app works. A live address is fixed. A playback address carries a start time, an end time, and a session number, and each manufacturer has its own conventions for it.

The ONVIF profile for this job is Profile G, which covers recording, search, and replay. Its current text requires a conformant device to provide replay addresses through GetReplayUri, accept the onvif-replay feature tag, and let the client configure the session timeout (ONVIF Profile G Specification, version 1.1, October 2025). A recorder that only passed Profiles S or T supports live video through ONVIF, not playback. The recorder on that site claimed basic ONVIF compatibility and no Profile G at all, so playback had to go through the manufacturer's own interface. Why the ONVIF label on a box promises less than it seems is covered in why "ONVIF" cameras still fail to integrate.

On that recorder, the request itself broke in three places. Video travels over RTSP, the protocol that sets up and controls a video stream, and the exchange showed:

The fix was a small relay: a piece of software between the player and the recorder that rewrites these requests. It also computes the recorder login itself, so the password never reaches the player.

Pacing was the last issue. The manufacturer's protocol has a Rate-Control header that tells the recorder whether to send at real-time speed. With it on, the sparse recording arrived in bursts, about 186 KB followed by six to seven seconds of silence, long enough for players to give up. With it off, the recorder sent a whole two-minute clip in two seconds. The relay now takes the fast transfer and releases frames according to their timestamps, so the player sees steady, real-time video.

Is someone else already using the playback session?

Recorders limit playback far more tightly than live video. The specification of the recorder model on that site lists ten remote users for live unicast but only one for search, which includes playback. In the field log, that single session covered up to 16 channels, but a second operator was still locked out.

The limit also bites when nobody else is watching. A session that ends without the RTSP "teardown" message (the client's way of saying it is done) keeps the slot occupied until the recorder times it out, about 60 seconds on that model. During that minute, the next request got error 560 The user has exceeded the maximum. In the operator's eyes, playback was simply broken.

Software can soften this:

• Always send the teardown message, including when a user closes the browser tab or switches cameras.
• Let a new request from the same system take over the slot cleanly instead of waiting for a timeout.
• Show "playback is in use" with the user's name, rather than a generic error.

Live streams have their own limits, and how they behave at scale is covered in handling 100+ camera streams in one Go backend.

Does this account have permission to view recordings?

Many systems treat live video and recorded video as separate rights. In AXIS Camera Station Pro, for example, the Viewer role can see live video only, the Operator role can be given access to playback and export, and an administrator can block access to recordings older than a set age (AXIS Camera Station Pro user manual). A user with that age limit sees today's footage and nothing from last week, which looks like a playback fault.

The test is simple: reproduce the problem with the operator's own account, not the admin account. If playback works for admin and fails for the operator, the answer is in the permission screen. How to design those permissions around operator duties is in who can view each CCTV camera.

Which symptom points to which cause?

What should you test before accepting an integration?

Run these with the actual recorders, the actual firmware, and the operators' own accounts:

1. Play a clip from yesterday and one from the oldest day the retention target promises.
2. Note a real event against a phone clock, then find it in playback at the expected minute.
3. Open playback, close the browser tab, and open it again at once.
4. Start playback from two operators on the same recorder at the same time.
5. Repeat with an operator account and a viewer account.
6. Play a clip from a camera that records on motion only.

If one of these fails, the table above narrows it to one cause, and the fix is usually a setting or a relay, not new hardware. If you are connecting existing recorders to an operator workflow or an analytics system and playback is the part that will not behave, I can help you trace it to the right layer.