Streaming and recording are separate pipelines
Live view and recording look like one feature but are two independent paths inside the recorder. Live view pulls a stream on demand and throws it away; recording continuously writes a (often different) stream to disk under a schedule, subject to storage, licensing and channel configuration. Everything that can break the second path is invisible on the first.
That is why spot-checking the live wall proves nothing about the archive. A recorder can serve flawless live video from all 32 channels while recording only 20 of them.
The seven usual suspects
1. Recording schedule misconfiguration
The channel is set to motion-only when continuous was intended, the calendar excludes weekends, or a technician disabled recording during maintenance and never re-enabled it. The device works exactly as configured - the configuration is the fault.
2. Motion detection tuned wrong
On motion-triggered channels, insensitive detection zones or thresholds mean events do not trigger recording. The archive is not empty - which makes the gaps even harder to spot.
3. Storage exhaustion or failure
A full volume with a stuck overwrite cycle, or a dying disk, stops writes on some or all channels. Many recorders keep reporting 'recording' status regardless.
4. Channel licensing
On VMS platforms and some recorders, a lapsed or reassigned channel license silently stops recording for that camera while live view continues to work.
5. Stream drop between camera and recorder
The recorder's connection to the camera's recording stream fails - credentials changed, the RTSP path broke after a firmware update - while your monitoring pings the camera directly and sees it 'up'.
6. Recording service crash
The recorder's OS is up and its web interface answers, but the internal recording process died. Everything looks alive except the one process that matters.
7. Overwrite outpacing retention
Recording works, but added cameras or raised bitrates shrank the retention window - so the footage existed and was already overwritten by the time it was requested.
Detection: check the archive, not the status
Every cause above shares one signature: recording segments stop appearing (or stop being retained) for the affected camera. That makes segment-level verification the universal detector - query the recorder for the newest segments per channel and alarm when they are missing or stale.
This is exactly how IOSentra's recording verification works: vendor drivers search each recording system's archive per camera on schedule, and a camera without fresh segments opens an incident naming that camera - whatever the underlying cause turns out to be. Storage checks, clock checks and device events then narrow the root cause: a full disk points one way, a licensing event another, a dropped camera-to-recorder stream a third.
The practical payoff is time-to-detection. Each of the seven causes above routinely survives weeks when discovery depends on someone requesting footage. Under scheduled verification, all of them surface within one check interval.
Quick manual triage when you find a non-recording camera
- Confirm the channel's recording schedule and mode (continuous vs motion) match intent
- Check the recorder's storage state: volume capacity, disk health, overwrite status
- Verify the channel shows in the recorder's active-recording list, not just live view
- Check channel licensing status on VMS platforms
- Test playback of the last hour for that channel specifically
- Compare recorder clock to real time before trusting any timestamps you find