Multi-DVR Overview
ChannelWatch monitors each configured DVR’s event stream separately. One DVR going offline does not turn the other DVR connections into the same failed connection. You manage one container and one settings file.
Start with the dashboard
Section titled “Start with the dashboard”The header’s All DVRs selector combines enabled DVRs in the dashboard. Choose one DVR to inspect its activity and status. Use distinct names so entries are easy to recognize in the selector, history, and alerts.
To add another connection, open Settings > General > DVR Servers. See Adding DVR Servers for the current form, save behavior, and credential limits.
What is separate and what is shared
Section titled “What is separate and what is shared”| Per DVR | Shared by this ChannelWatch instance |
|---|---|
| Connection and reconnect state | The container, monitoring core, and UI backend |
| Stream/session tracking | /config/settings.json and the configuration volume |
| Alert overrides and deduplication | Configured provider accounts and credentials |
| Notification routes by event type | Sign-in protection and the web UI |
| DVR identity in history and health results | Application restarts, updates, and available CPU/memory |
A core restart briefly affects monitoring for all DVRs in this instance. ChannelWatch’s core and UI are separate managed processes inside the container; a DVR’s independent state does not mean it runs in a separate container.
Choose destinations per DVR
Section titled “Choose destinations per DVR”Configure providers under Settings > Notifications, then open Settings > Routing to choose which event types from each DVR reach each destination.
For example:
| DVR | Recording events | Disk and health alerts |
|---|---|---|
| Living Room | Pushover and Discord | Pushover |
| Basement | Discord | Discord |
| Test DVR | No destinations | No destinations |
Routing chooses destinations from the providers configured for this instance. The standard provider fields are shared: every DVR routed to that Pushover configuration uses the same credentials, and every DVR routed to that Discord configuration uses the same webhook. Use separate instances when those provider accounts must be isolated.
See Per-DVR Notification Routing for the matrix, defaults, and save behavior.
DVR identity
Section titled “DVR identity”The canonical ID generated for a new connection is:
dvr_ + first 8 hexadecimal characters of MD5(normalized_host + ":" + port)For 192.168.1.10:8089, the canonical ID is dvr_17c621dc. This is an address-derived identifier, not a password or security token. The ID connects saved configuration, history, routes, and per-DVR API results.
Renaming a DVR does not change its identity. Existing saved entries can retain their ID when edited, while removing and re-adding an entry can create a different identity. Do not infer identity from the display name or manually replace IDs without reviewing routing and history.
Automation
Section titled “Automation”The recommended path is the first-run wizard followed by Settings. For deployment-managed bootstrap, CHANNELS_DVR_SERVERS accepts a comma-separated list of Name@host:port entries. See Environment Bootstrap Config.
The planned CW_DVR_<N>_* variables and /config/dvrs.yaml are not supported setup paths in v1.6.5. Legacy CHANNELS_DVR_HOST and CHANNELS_DVR_PORT remain compatibility inputs with startup warnings.
Limits to plan around
Section titled “Limits to plan around”- One replica. Multiple ChannelWatch replicas sharing
/configare unsupported. The Helm chart enforces one replica and persistent configuration storage. - Shared downtime. If the container stops, monitoring stops for all DVRs in that instance.
- Shared resources. More event streams and activity consume more CPU, memory, and storage. The runtime logs a soft warning above 10 enabled DVRs; it does not enforce a hard 10-DVR cap.
- No per-DVR access boundary. A DVR filter is a viewing aid, not a separate login or access-control boundary.
- Independent instances. Two ChannelWatch instances monitoring the same DVR can both send alerts. They do not share deduplication state.
Older installations
Section titled “Older installations”Multi-DVR support was introduced in v0.9.0. Earlier versions monitored one DVR per instance. Starting in v0.9.0, that model was replaced by a shared server list. Follow the migration guide when moving an old single-DVR setup.