Skip to main content

Health, history, and updates

Alarms opens on Needs attention: the faults, failures, and anomalies waiting for a person. Detections are records, not alarms; they and every recovery are under All history, one click away, for correlating what a camera saw when something fired. The other views are Unacknowledged, Shelved, and Dismissed. Acknowledging a fault keeps it in Needs attention; shelving parks it for one, eight, or twenty-four hours and then returns it to the queue; dismissing removes it until the next failure raises it again. None of these repairs a fault or cancels a delivery. History records camera actions, rule activity, notification delivery, and account activity according to your permissions.

A recorder warning or error about a camera names the camera as it is called on the recorder, such as Front door, rather than by its internal number, and is filed under that camera, so the Camera filter on Alarms finds it. An entry that mentions more than one camera names each of them but is not filed under any one; an entry about a camera that has since been removed keeps the number.

A rule alert appears as a notice for a few seconds; one that goes unread lands in Recent alerts at the top of Alarms, and the count of unread alerts sits on the Alarms link until the page is opened. Up to six notices show at once; error notices stay until dismissed.

Each History tab shows the latest 100 entries and Load more extends that by 100 at a time, to 500; past that, narrow by camera or export what is shown as CSV. Only the open tab refreshes.

Administrators use Settings → This recorder for recorder health, version, disk health, the recorder's clock and camera clocks, a factory reset, and Settings → Updates for updates. Both are in the Recorder group of the Settings sidebar; each Settings page has its own address under /settings/, so a runbook can link straight to it. Follow the explanation on each fault; recording, detection, and notification delivery can fail independently.

Recorder clock​

Settings → This recorder → Recorder clock shows the recorder's time, whether network time is on and synchronized, and whether the cameras are taking their time from the recorder. An administrator can change:

  • Time zone, from the system's list. Schedules, reports and every time the recorder writes use it from then on, without a restart.
  • Set the time automatically from network time. With it off, Date and time sets the clock by hand, read in the chosen zone. Use this only on a site that cannot reach a time server; a clock set by hand drifts.

Cameras take their time zone and time from the recorder, so a change here reaches every camera at its next clock check, within a few minutes. Each change is recorded in History. Which NTP servers the recorder itself uses is set on the host, not here. If EVERNVR_TZ is set in the service configuration, times are written in that zone whatever the system's zone is, and the page says so.

Problem banner​

A critical fault puts a red banner across the top of every page, for every signed-in user. It leads with the consequence, such as Not recording or Cameras offline, and then gives the cause. Select All issues to list every critical fault, or Details to open recorder health (administrators) or Alarms (everyone else). The banner clears on its own within about ten seconds of the fault being fixed. Select × to dismiss it for the faults it is showing. The fault stays open, and Recorder needs attention appears beside the navigation instead. Any new critical fault brings the banner back within about ten seconds. Dismissing lasts until the page is reloaded. Warnings do not raise the banner. They appear as Recorder needs attention beside the navigation.

A camera that is added or turned on gets a few minutes to connect and finish its first recordings before it can raise a camera fault. Faults that are still there after that appear as usual.

When recording storage is lost​

If the recording drive is unplugged, unmounted, or replaced, recording stops, but live view keeps working. The recorder will not write into an empty mountpoint on the system disk. Cameras that share one connection for recording and live view carry on showing live video. Their tiles read Not recording: … with the reason. Recording starts again by itself within about ten seconds of the storage coming back. A camera whose recording write fails, for example on a full or failing disk, keeps its live view and does not reconnect to the camera until the storage check has looked at the folder again and found room; a full disk reads Recording paused: storage full and starts a retention pass at once (see full storage). If writes keep failing, the camera waits a minute between tries.

The health message names the storage folder, says why it cannot be reached, and says how to fix it. A previous location, one that holds older footage but no longer receives new recordings, can go missing too. Only playback of the footage on it is affected, so it is a warning rather than a banner. Reconnect the drive and mount it at the same path. If the drive is retired, administrators can select Remove location beside the message in recorder health. It opens the removal dialog in Settings → Storage & retention for that folder.

A drive that has been reformatted counts as replaced. It no longer carries the storage marker. Mount it, then add its folder as new storage under Settings → Storage & retention and remove the old location.

Recording gaps​

A hole in a camera's recording that has already closed is history, not a live fault: the camera or its network dropped out and came back. Each camera gets one warning per day in the alarm history, N recording gaps on , S seconds in total, updated as the day goes on, so a camera on an unreliable link or a nightly reboot does not raise dozens of alarms. A single gap longer than ten minutes is recorded on its own as critical. Neither holds the problem banner or the dead-man check; the live faults, not delivering recent images and not reporting recording progress, do that while the gap is open.

Camera clocks​

A camera that loses its clock in a power cut stamps every frame with the wrong time until someone notices. With Settings → This recorder → Camera clocks → Keep camera clocks correct on, which it is by default, the recorder reads each ONVIF camera's clock every 15 minutes and when a camera comes back online. It sets the time when it is more than a few seconds out, and with it the recorder's time zone and the recorder itself as the camera's NTP server, which it also does for a camera whose time is right but whose zone or time source is not. The recorder answers NTP on UDP port 123; if another time service on the host holds that port, the recorder log says not serving NTP to cameras and the cameras are kept right by the regular checks alone. Each correction is on History → Camera changes as Clock corrected, made by the recorder. The setting only stops the writes; the reads continue so the drift on each camera's Overview tab stays current. A correction of a minute or more, automatic or from Correct the clock, also reconnects the camera's streams, at the cost of a few seconds of recording, because some cameras stop advancing the timestamps of a stream that was open across the jump. See camera clocks.

Separately, the recorder compares each stream's timestamps with its own clock. A stream that runs well fast or slow for a minute is reconnected; a second fault within 15 minutes switches that camera to the recorder's own timestamps until the recorder restarts. Each leaves a resolved warning on History → Recorder health, such as Lobby viewing stream timestamps ran at 0.25x real time; reconnected the stream. A stream whose timestamps jump backwards is reconnected at once, and a camera that stops delivering live video for 25 seconds after it had been delivering it is reconnected too.

Two clock situations become warnings on History → Recorder health. A clock that was a day or more out leaves a warning such as Lobby clock was 3 days out; corrected, already resolved: it happened and it is fixed. A camera corrected three or more times in a day gets Lobby clock keeps drifting; its NTP source may be wrong, open until a day passes without a correction. It stays open, and is listed once, across a recorder restart. Fix the camera's NTP server, or switch it to manual time from its Overview tab. Neither warning raises the problem banner.

Disk monitoring​

The installer enables the disk-health timer with an empty device list. An administrator must install smartmontools and configure the physical recording devices in /etc/evernvr/disks.json. See disk hardware health. Without smartmontools a configured disk reads SMART data is not available: smartmontools is not installed, a warning that says what to install rather than a stale or missing result.

Unknown health is not a healthy result. Unsupported devices report unknown, and results older than fifteen minutes remain warnings. Disabling alerts for missing configuration does not disable disk-failure or stale-result alarms. Change Alert when disk health results are missing, then select Save in the disk-health form. The checkbox takes effect only when saved.

The system disk​

The database, the logs and the default backup folder live on the system disk, not the footage drive. Two faults concern it. The recorder's system disk is full is critical: database writes are failing, so events, alarms and settings changes are not being saved while recording to the footage drive continues; free space there (old backups and logs first) or move the backup folder to another drive, and the fault clears by itself once there is room. The database was migrated without a safety copy is a warning raised once after an update: the copy the recorder takes before changing its schema did not fit, so the update went ahead without it; the pre-update backup the updater took is the fallback, and the system disk needs space before the next update. The default backup folder keeps nightly backups and those pre-update copies within 4 GB together, oldest first, never the newest of each kind.

Factory reset​

Settings → This recorder → Factory reset returns the recorder to how it was when installed, for handing it to a new owner or starting a site again. Only a permanent owner administrator sees it; a temporary installer cannot reset the recorder. Select Factory reset…, then enter your password again, your authenticator or recovery code if your account has two-step sign-in, and RESET typed to confirm, and select Erase this recorder. A session is required; an API token cannot reset the recorder.

The recorder then restarts and, before it opens its database, erases:

  • every account, session, and API token;
  • cameras, their passwords, zones, rules, layouts, schedules, and all other settings, including notification and integration settings;
  • events, alarms, history, identities, and thumbnails;
  • the recordings on every recording drive it can reach (each drive stays registered, empty);
  • its backups, both under the recorder's data folder and the recorder's own backups in a backup folder chosen in Settings → Backups.

It keeps the license, the recording drives and network shares it records to, the service configuration under /etc/evernvr (network address, any HTTPS certificate of the site's own), the recorder's own certificate authority, so devices that trusted it still do, and its logs. Cameras are not reset: they keep what the recorder set on them, including network time pointed at this recorder.

Pre-update snapshots under /opt/evernvr/backups are not erased: they sit outside the recorder's data and hold the previous owner's database. Delete them on the host when the recorder changes hands (see a factory reset).

Recordings are set aside at once and deleted in the background, so the recorder is usually back within a minute however much footage it held, and the page opens first-run setup for a new owner account. A drive that was unplugged or unreachable during the reset keeps its footage, and so does a recording folder that does not carry the recorder's storage marker; erase it by hand before using it again. A reset interrupted by a power cut runs again at the next start. A reset cannot be undone, so take a backup and copy any footage you need first.

Update a recorder​

Updates pause recording for a minute or two. Schedule the gap and check storage and backups first.

The recorder checks the EverNVR release server for updates and shows what is available under Settings → Updates. Nothing is installed until an administrator installs it, unless Install updates automatically has been turned on for the site (it is off by default).

  1. Open Settings → Updates, or select the version label at the foot of the side rail. It shows the installed version, when the recorder last checked, and any available release with its notes. Select Check for updates to ask now.
  2. Select Download, then Install. The page shows each step. When the recorder stops to switch releases, an Installing the update notice covers the page instead of a disconnection warning, and the page reloads by itself once the new version answers or the restart has signed you out. After that reload the step list picks the install up where it was and follows it to the end, without reloading the page again. The notice follows you to any page you open in the meantime.
  3. Read the outcome: updated, or rolled back and why. Then verify camera recording, playback, detection, and notification settings. If the update was rolled back and the database restored, everyone signs in again.

A site without access to the release server uses Install from file on the same page: choose the .run release file and its .run.sig signature. The recorder checks them against the keys it trusts before installing anything.

The updater verifies the release, prepares the detector environment while the recorder is still recording — an update whose detector packages are unchanged reuses the environment already on the recorder — then stops the recorder, backs up the database and configuration, switches releases, and checks that the new release starts and answers. Any failure rolls back to the previous release, restoring the database if the new release had started. The previous release stays installed, so an update that passed its checks but is unwanted can be undone from the host with evernvr-update rollback. An interrupted update requires the documented recovery procedure; do not delete its marker merely to retry.

A recorder installed by an older EverNVR installer (0.1.33 and earlier) cannot update itself from this page until the new installer has been run on it once; see installation.

Use the full update procedure and recovery guide for commands and failure handling.

Support information​

Download logs and the support bundle when diagnosing a fault. A support bundle is redacted and is not a backup. A configuration backup contains the credential key and must be handled separately.

For a recorder that cannot be reached, start with troubleshooting. An external dead-man check can alert when the recorder itself cannot send a message; its setup is in the installation guide.