Recording Servers

Recording servers are the workhorses of a Meridian VMS deployment. Each server runs the recorder daemon, which manages continuous recording and a stream relay for RTSP ingestion. The management server coordinates all recording servers through its API and real-time messaging.

Recording servers are managed from Settings > General > System in the web interface.

Registering a Server

Recording servers register themselves automatically when the recorder daemon starts. The daemon connects to the management server using the credentials configured during installation.

Registration Flow

1. The recorder daemon starts and reads its configuration.
2. It registers with the management server, providing its name and network address.
3. If the server was previously registered, the management server updates its status to online.
4. If this is a new server, a new registration is created.
5. The recorder then fetches its assigned cameras and begins recording.

Server credential security

Server authentication credentials authorise all recorder-to-management communication including heartbeats, segment indexing, and event reporting. Keep configuration files secure and restrict file permissions to the service user.

Server name

On first registration, the server name is set automatically by the daemon. You can rename it later through the Edit dialog in the UI. Subsequent registrations preserve the name you set.

Heartbeat Monitoring

Each recording server sends a heartbeat to the management server every 30 seconds. The heartbeat includes:

• Disk usage — total and used bytes on the recordings partition
• Per-camera status — each camera reports as recording, error, or offline

The management server uses heartbeats to:

• Update the server’s last_heartbeat timestamp
• Set the server status to online
• Bulk-update camera statuses in a single database query
• Trigger failover rebalancing if the server was previously offline

Server Status

Status	Meaning
online	Heartbeat received within the expected interval
offline	No heartbeat received; the server may be down or unreachable
degraded	The server is online but one or more cameras are in an error state

When a server transitions from offline to online, the management server automatically triggers a failover rebalance check if failover is enabled.

Server Health

Clicking a recording server row in the System page opens a detailed health modal showing real-time statistics. The modal auto-refreshes every 10 seconds.

CPU and Memory

The health modal displays:

• CPU utilisation — percentage and core count, with a colour-coded progress bar (green < 50%, yellow 50-80%, red > 80%)
• Load average — 1, 5, and 15-minute load averages
• Memory usage — used vs total, with a breakdown of memory consumed by individual recording processes

GPU Statistics

If the recording server has a CUDA-capable GPU (required for AI object detection), the health modal shows:

• GPU model name — for example, NVIDIA Tesla T4
• CUDA version
• GPU utilisation — percentage with colour-coded bar
• VRAM usage — used, free, and total memory with a progress bar
• GPU temperature — in degrees Celsius

No GPU detected

If a recording server does not have a CUDA GPU, the Object Detection section of the Edit dialog displays a message indicating that detection is unavailable on that server.

Camera Counts

The health modal also shows:

• Total cameras assigned to the server
• Number of cameras currently recording
• Events detected today

Service Threads

A list of internal daemon threads (heartbeat, retention, detection, etc.) with alive/dead indicators.

Detection Settings

Each recording server has independent AI object detection settings. These are configured through the Edit dialog accessible from the server row in the System page.

Terminology

The UI refers to this as “Object Detection” or “AI Detection”. These labels are used throughout the interface.

Configuration Options

Enable Object Detection : Master toggle. When disabled, no inference runs on this server regardless of other settings.

Model : The detection model to use. Available options:

| Model | Description |
|---|---|
| Nano | Fastest inference, lowest accuracy |
| Small | Good balance of speed and accuracy |
| Medium | Best balance (recommended) |
| Large | Highest accuracy, GPU intensive |
| VisDrone | Optimised for overhead/aerial camera angles |
| Combined | COCO + VisDrone + LLVIP + CrowdHuman merged model |

Inference FPS : How many frames per second to process through the detection model. Range: 0.5 to 10.0 in 0.5 increments. Higher values detect events faster but consume more GPU resources.

Confidence Threshold : Minimum confidence score (10% to 90%) for a detection to be recorded as an event. Lower values catch more detections but may increase false positives.

Detection Classes : Which object classes to detect. Presented as toggle chips. Available classes include: person, car, truck, bus, motorcycle, bicycle, dog, cat, bird, pedestrian, people, van, motor, tricycle.

Live Detection Settings

Separate from the recording detection pipeline, each server also has settings that apply only to the real-time Live Detection page:

Live Confidence : Confidence threshold for detections shown on the live detection view. Can be set independently of the recording threshold.

Live Detection Classes : Which classes to show on the live detection page. Allows showing a different set of classes than what is recorded.

Automatic restart on detection changes

Saving any detection setting automatically triggers a restart of the recording service on that server. This is necessary for the model and configuration changes to take effect. A confirmation message appears in the UI.

Restarting a Server

Administrators can restart the recorder daemon on any server directly from the UI by clicking the Restart button on the server row. This sends a POST /api/servers/{id}/restart request, which proxies a restart command to the recorder’s local API.

After triggering a restart, the UI polls the server status every 3 seconds for up to 90 seconds, showing a “restarting” badge until the recorder reports back as healthy.

When to restart

Restarting is useful after configuration changes that do not auto-restart, or when a server enters an error state. Detection setting changes trigger an automatic restart and do not require a manual one.

Disk Usage Monitoring

Each recording server reports disk usage through its heartbeat. The System page displays:

• A progress bar showing used vs total disk space, colour-coded:
  • Green: < 75% used
  • Yellow: 75-90% used
  • Red: > 90% used
• Used and total bytes in human-readable format (MB, GB, TB)
• Total recording size stored on each server

The disk usage reported is for the partition containing /recordings, where all video segments are stored.

Disk full behaviour

When disk usage exceeds 90%, the system behaviour depends on the disk full strategy configured in Storage settings. See Storage & Retention for details.

Deleting a Server

Administrators can delete a recording server from the System page. Deleting a server:

• Removes the server record from the database
• Unassigns all cameras that were assigned to it

Data loss

Deleting a server does not delete recording files from the server’s disk. However, the segment index entries are removed from the management database, making those recordings inaccessible through the UI. Only delete a server if you are certain you no longer need its recording history.

API Reference

Method	Endpoint	Description
POST	/api/servers/register	Recorder self-registration
GET	/api/servers	List all servers with recording size
GET	/api/servers/{id}	Get a single server
PATCH	/api/servers/{id}	Update server name, URL, or detection settings
DELETE	/api/servers/{id}	Delete a server
POST	/api/servers/{id}/heartbeat	Heartbeat with disk usage and camera statuses
POST	/api/servers/{id}/restart	Trigger recorder restart
GET	/api/servers/{id}/cameras	List cameras assigned to server
GET	/api/servers/{id}/detection	Get detection config (called by recorder)
GET	/api/servers/{id}/zones	Get detection zones for all cameras on server