Several CCTV Recorders, One Workflow for Operators

When cameras are spread across several recorders (NVRs, the boxes that store the footage), operators should not have to remember which box holds which camera. Organise the control room by area, let one system talk to every recorder, and plan capacity per recorder: live-view sessions, playback slots, bandwidth, and the clock each recorder keeps.

Most buildings do not plan this split. A recorder fills up, the next one is installed, and new cameras go wherever channels are free. A few years later the lobby can sit on two recorders and the car park on three.

Why does a second recorder make the operator's job harder?

Each recorder's own software usually lists cameras by channel number on that box. With three recorders, the operator works with three lists, three logins, and three timelines. Following one person from the lift to the lobby can mean switching applications halfway through the search.

In one building I worked on, about 120 cameras ran through three recorders, and a single recorder could hold up to 64 channels. Channel numbers that large are not something a shift operator can memorise. The cameras worked; the arrangement worked against the people using them.

Organise by area, not by recorder

Operators think in places: lobby, lifts, car park, back gate. An area is a list of cameras chosen from any recorder. The administrator builds saved layouts for each area, and operators switch between them without touching the configuration.

Permissions follow the same areas. A parking officer receives the car-park area, wherever its cameras are recorded. The CCTV user access guide covers how to test those permissions from an operator account.

Do you need new software for this?

Not always. Some video management software (VMS) can already join several recording servers into one system. Hanwha's support article on merging systems in WAVE is one example. Whether your existing recorders can join such a system depends on the model, firmware, and the protocols they support; the ONVIF and RTSP compatibility guide explains what to check.

How many operators and screens do you need?

No standard gives a fixed number. The second edition of IEC 62676-4, published in October 2025 and replacing the 2014 edition, states there is no theoretical limit on cameras and displays. In practice, the limit comes from the control and display equipment and the operator's ability to manage the system. The standard includes a section on operator workload.

So start from the work, not the camera count. List the areas each shift must watch, the events that need a response, and the cameras that are only recorded for later review. A camera nobody watches live can still matter; it simply does not need a tile on a screen all day.

Event noise counts as workload too. In the building above, motion alerts were enabled only on lift cameras chosen by the administrator. Alerts from every camera would have buried the few that needed attention.

Plan capacity per recorder, not for the whole site

Every recorder has its own limits, and the total camera count hides them. The specification of the recorder model on that site lists 10 live-view users, one search/playback user, and 400 Mbps of outgoing transmission per unit.

That has direct operational consequences:

• Live view. If three operator PCs, a guard post, and a manager's laptop each log in to the recorder directly, the live limit arrives quickly. A central system that holds one connection per recorder and shares it with every PC uses far fewer of those slots.
• Playback. With one playback user per recorder, a second operator replaying footage from the same box is refused. The application should say who is using it instead of showing a vague error.
• Bandwidth. Grids should use the small stream each camera provides; the full-resolution stream is for one enlarged camera.

On 29 September 2026, one of those recorders delivered 27 channels of 1080p video at once through a single shared session, with 26 actually sending frames. That was one field test, not a limit for every model. The technical side, including reconnect behaviour, is in handling 100+ camera streams in one Go backend.

Do the recorder clocks agree?

An incident that crosses two recorders only makes sense when both timelines use the same time. During the same field test, one recorder was 1 hour 27 minutes ahead. It tried to sync with an internet time server, but the camera network had no internet access, so the sync kept failing.

Point every recorder to a time source inside the network, then check the offset during handover. A central system can also read each recorder's offset and adjust playback, but fixing the source is better. The clock drift article explains why mismatched timestamps weaken evidence.

What should operators see when something breaks?

"Offline" is not enough with several recorders. Operators and technicians need to know whether the camera lost its picture, the camera lost its link to the recorder, or the whole recorder is unreachable. Each cause goes to a different person: a site technician, a network check, or the recorder vendor.

Keep the tile in its layout and show the reason. A missing tile makes a gap in the area that nobody notices until footage is needed.

What should you prepare for a discussion?

Prepare a list of recorders with model and firmware, the channels on each, and the area each camera belongs to. Add the number of operator PCs and monitors, who usually replays footage, and how the recorders get their time.

In the Pantau CCTV management project, cameras from several recorders are grouped by area, operators work from saved layouts, and a central server handles the connections to each recorder. It is one example of site-specific development, not a claim that other systems cannot combine recorders. For monitoring and integration work, see IoT system development.

Describe your recorders and control room. The initial 15-minute discussion is free. Surveys, configuration, and development are scoped after discussing the site.