Configuration

The app reads runtime settings from bunryu.json in the app root.

bunryu.json:

Relative file paths are resolved from the app root. Command names like ffmpeg and ffprobe are left as command names.

SRS values are inferred from srs.conf:

• RTMP pull/publish port from top-level listen
• SRT pull/publish port from srt_server { listen ... }
• SRS HTTP API port from http_api { listen ... }
• SRS log tail path from srs_log_file, if present — otherwise the dashboard falls back to journalctl -u srs.service (production's srs.conf logs to console/journald instead of a file; only local dev's still sets srs_log_file)

The dashboard's own log and the relay's log are always read via journalctl -u bunryu.service / -u goryu.service — both only ever log to the journal. All three require bunryu.service's SupplementaryGroups=systemd-journal (set by server-install.sh); without it, the Server Logs view shows no output for whichever service's journal it can't read.

The control plane also writes structured diagnostics to /var/lib/bunryu/diagnostics/ in production. The rotated JSONL files keep output starts/exits/restarts, SRS and relay transitions, input and bonded-leg transitions, and FFmpeg timestamp/media-clock warnings for seven days (the last ffmpeg stderr tail at exit is included on the exit event; raw stderr isn't streamed to diagnostics to keep incident volume from crowding out the window; timestamp warnings are aggregated as described under Input timestamp fault detection). Once per minute it also stores compact health snapshots containing SRT counters, leg rates/health, relay forwarding state, and FFmpeg output progress so an incident can be investigated after the live one-hour chart window has passed. The snapshots also record resource usage: per-output FFmpeg RSS/CPU and memory limit (translation mixers included), CPU and RSS for the Node control plane (plus its V8 heap), SRS and the SRT relay (the same samples the dashboard shows, up to ~10 s old), and host total/available memory and swap. Separately, host-memory-low (available memory under 15% of total) and host-memory-recovered (back above 20%) events are logged on transition, the former with the five largest processes by RSS. Files are rotated daily or at 100 MB, whichever comes first, with a 5 GB total diagnostics cap that removes the oldest rotated files first. The installer configures persistent journald with a seven-day retention limit, 1 GB system journal cap, 256 MB runtime cap, and one-day journal file rotation.

Relay ports and status polling are read from goryu.json, located beside srs_config_path.

Installer/development overrides: