Support and current limits
This initial documentation reflects the implementation and evidence reviewed on
September 22, 2026. No physical appliance, sustained camera-count rating, complete
camera compatibility matrix, or phone/browser support matrix has been qualified.
The repository's deploy/SUPPORT_MATRIX.md holds the detailed evidence ledger.
Evidence so far
| Area | Current evidence |
|---|---|
| Ubuntu 24.04 install, signed update, rollback, and configuration recovery | Disposable VM trials using synthetic streams, with the installer and updater used up to 0.1.33 |
| Makeself installer on Ubuntu 26.04 | Disposable KVM trial of the installer used up to 0.1.33: signed download, fresh install, first-owner login, CPU detector readiness, migrations, file ownership and reboot; no cameras or Hailo hardware |
Current installer and updater (Harness .run, in-app updates, adoption of older recorders, automatic rollback) | Implementation and the updater's automated tests; no VM trial recorded yet. The repository's host qualification script drives this path and has not been run against a host |
| Hailo and NAS setup from Settings | Implementation and automated tests; each runs in its own system unit outside the recorder's sandbox, and has not been run on a host since the recorder began running as root |
| Continuous integration | The workflow exists; no run has been recorded |
| Detector under the host's own Python (3.13 or 3.14) | Python 3.14 on the development bench only; 3.13 has not been run anywhere; the pinned development environment is 3.12 |
| Full system disk, backup folder size cap, database durability settings | Implementation and automated tests; never observed on a disk that was actually full |
| ONVIF adoption, recording, playback, CPU detection | Development bench cameras |
| Hailo acceleration | Sixteen generated cameras at 5 detections per second with no dropped frames, and a direct measurement of the accelerator's throughput, both on the development host on September 22, 2026 |
| Automatic Hailo setup on Ubuntu 26.04 | Implemented in the fresh installer and Settings; isolated kernel-driver and Python 3.14 build checks, imports, model parsing and CPU fallback inference; full fresh hardware installation remains unqualified |
| HEVC | Development camera playback; no complete browser matrix |
| Audio | Synthetic tests for verified AAC and G.711 |
| Accounts, permissions, API tokens, notification queue | Implementation and automated tests |
| MQTT publishing | Implementation and automated tests; no third-party subscriber qualified |
| Automatic camera clock correction | Implementation and automated tests against simulated ONVIF cameras; clocks set by hand on development bench cameras, no record yet of the automatic correction on real hardware |
| Camera time zone and the recorder as NTP server | Implementation and automated tests against simulated ONVIF cameras and a local NTP client; no camera has yet been recorded taking its time zone or its time from the recorder |
| Face and plate recognition | Implementation and automated tests; thresholds tried on one site's cameras, no reviewed accuracy dataset |
| Talking through a camera's speaker (ONVIF audio backchannel) | Detected on the development bench's three Amcrest cameras and correctly refused on its two Tapo cameras; a browser's microphone heard through an Amcrest IP8M's speaker on October 13, 2026. No other make tried |
| Spoken messages (recorded or spoken by Piper) and the Play a message rule action | A Piper-spoken message heard through an Amcrest IP8M's speaker, played from the API and by a rule, on October 13, 2026; a browser recording saved, not yet played through a camera |
| Deterrence outputs (a camera's relay, light, or siren) | One Amcrest active-deterrence camera's white light switched on and off from the recorder on the development bench on October 2, 2026, and its siren found but not yet sounded; ONVIF relay outputs and the Tapo light and siren are implementation and automated tests only, with no camera with relay outputs and no Tapo camera with its app password entered tried |
| Physical storage failures, NAS appliances, phone notifications | Real-hardware/provider qualification outstanding |
| Detection and cross-camera retrieval accuracy | No reviewed real-scene accuracy dataset |
The installer accepting an OS is not a claim that a particular machine is supported. Short 4-, 8-, and 16-camera synthetic runs do not establish sustained capacity or disk throughput. Commission the actual machine, cameras, storage, and client devices, and keep dated results.
Detection capacity
One accelerator serves every camera, so the number that has to fit is cameras multiplied by the detection rate — not the camera count on its own.
On a machine like the development host (a Ryzen 9 9955HX with a Hailo-8 M.2):
| If you set the detection rate to | Plan for about |
|---|---|
| 5 per second (the default) | 20 cameras |
| 4 per second | 24 cameras |
| 3 per second | 32 cameras |
Those are working figures with margin left in, not a ceiling. The accelerator itself runs out somewhere near 30 cameras at 5 per second; the gap is there so a night when wind and rain move every scene has somewhere to go. Detection schedules and the recorder's motion gate mean fewer frames arrive than the rate suggests — count that as part of the same margin, not as room for more cameras.
What runs out first on this hardware is not the processor, memory or disk throughput. Watch storage size, the fan-out of a large camera wall, and the camera bitrates landing on one network interface before you worry about the accelerator.
Without an accelerator, each frame costs far more, and a sixteen-camera trial on four processor cores dropped frames. Size the processor for the detection rate, not for the recording.
Where the figures come from: the Hailo-8 was timed directly against the shipped DAMO-YOLO-T model at 6.33 ms of device time per frame, about 148 inferences per second; sixteen generated cameras at 5 per second ran with no dropped frames on two thirds of one core; decoding costs 3.1–3.4% of a core per substream, 5.8% for a 1080p main stream and 11.6% for an 8 MP one. All of it was measured on one development machine on September 22, 2026. Sixteen cameras is the largest configuration ever run — on generated streams, for thirty seconds. Nothing larger has been tried, and no recorder of any size has run for a day.
Operational limits
- Unknown or fully reserved camera connection budgets block ingestion.
- Recording review is limited to 120 seconds per request without export permission. Older recorded stills require export permission too.
- Recorded pulls share limits of 16 concurrent playback/export transcodes per account and 32 site-wide. MJPEG live streams are limited to four per account.
- Recorded-frame requests are limited to 30 per minute per account. Over-limit requests return HTTP 429.
- Investigation ranks at most 2,000 filtered events and returns up to 100 matches. Narrow the filters when results are truncated.
- Evidence archives run one at a time site-wide and have bounds on source size, segment count, and response time. Whole segments may include surrounding footage.
- Incident holds bypass retention and can consume all recording space.
- Notification delivery is at least once, with five attempts and a one-hour expiry. Provider acceptance does not establish receipt by a person.
- Off-site access is not built in. Configuration backups exclude footage, thumbnails, a site's own certificate, and host configuration; the recorder's own certificate authority is included.
Use the first-run checklist and the commissioning report to record what was actually tested at the site.