Dynamic stream creation fails with "stream not found" until Docker restart

[ryann0097]

Today, we proceeded to configure the camera system. When we tried to add a stream, even though it looked like everything went right, we got a new error with go2rtc.

When adding a new camera (via auto-detect or simply motion mode), the stream doesn't start properly or immediately. It just gets “added” to the streams, but we can't see the live stream, and it gives us HLS 404 errors and RTSP failures with 404 NOT FOUND. Only when we restart Docker does it work. To avoid exposing the URL or the camera name, I changed them to and , respectively. Below are the logs and our suppositions.

1. Creation and initial stream log:

lightnvr | [2026-02-12 15:13:09] [INFO] Added stream configuration: name=<my-cam-name>, enabled=true, detection=true, model=motion
lightnvr | [2026-02-12 15:13:09] [INFO] Created stream state for '<my-cam-name>' in slot 8 with initial reference count 1
lightnvr | [2026-02-12 15:13:09] [INFO] Created stream state for '<my-cam-name>'
lightnvr | [2026-02-12 15:13:09] [INFO] go2rtc_stream_is_ready: API is responsive (HTTP 200)
lightnvr | [2026-02-12 15:13:09] [INFO] Stream <my-cam-name> is registered with go2rtc, WebRTC URL: http://localhost:1984/webrtc/
<my-cam-name> 

2. go2rtc preload attempt.

lightnvr | [2026-02-12 15:13:09] [INFO] Preloading stream with URL: http://localhost:1984/api/preload?src=
<my-cam-name>&video&audio
lightnvr | [2026-02-12 15:13:09] [ERROR] Failed to preload stream in go2rtc (status 500): streams: stream not found: <my-cam-name>
lightnvr |
lightnvr | [2026-02-12 15:13:09] [WARN] Failed to preload stream <my-cam-name> in go2rtc - detection snapshots may be intermittent

Now go2rtc responds with 500, saying it can't find the camera stream. The API responds, but the stream isn't ready in go2rtc.

3. Despite this, the HLS is ready

lightnvr | [2026-02-12 15:13:09] [INFO] Using go2rtc native HLS for stream <my-cam-name> (no ffmpeg HLS thread needed)
lightnvr | [2026-02-12 15:13:09] [INFO] go2rtc native HLS ready for stream <my-cam-name>
lightnvr | [2026-02-12 15:13:09] [INFO] Started HLS streaming for '<my-cam-name>'
lightnvr | [2026-02-12 15:13:09] [INFO] Stream '<my-cam-name>' is now running

The preload fails, but the workflow continues and the stream is labeled as “running”.

4. Failed attempt at internal RTSP connection.

lightnvr | [2026-02-12 15:13:09] [INFO] [<my-cam-name>] State: CONNECTING (attempt 1)
lightnvr | [2026-02-12 15:13:09] [INFO] [<my-cam-name>] Connecting to stream: <my-cam-rstp>
lightnvr | [rtsp @ 0x7fdbf8000b80] method DESCRIBE failed: 404 Not Found
lightnvr | [2026-02-12 15:13:09] [ERROR] [<my-cam-name>] Failed to open input: Server returned 404 Not Found

And in the console, when we open it with element inspection, we see this:

[HLS <my-cam-name>] go2rtc base URL: http://10.7.8.216:1984

Using HLS.js for stream <my-cam-name> (mode: go2rtc)

:1984/api/stream.m3u8?src=<my-cam-name>&mp4=flac:1 Failed to load resource: the server responded with a status of 404 (Not Found)

[HLS <my-cam-name>] Fatal error: networkError, details: manifestLoadError
[HLS <my-cam-name>] Network error recovery attempt 1/3

The endpoint "/api/stream.m3u8?src=" returns 404 Not Found.

[matteius]

I believe these type of issues are resolved in 0.21.13 -- could you verify?

[matteius]

Understood — the go2rtc config sets origin: '*' which should make CORS work for direct connections to port 1984. Are you able to verify your go2rtc config has this?

[matteius]

So the situation is:

The browser connects directly to go2rtc on port 1984, and if auth is enabled there, the CORS middleware never gets to add headers (because auth rejects first).

Let me check — when lightNVR's proxy calls go2rtc internally on 127.0.0.1, go2rtc's auth middleware already skips loopback addresses (the isLoopback check). So auth on go2rtc only matters for direct browser connections. But with auth enabled, those direct browser connections get blocked before CORS headers are set.

The simplest fix: stop writing username/password to go2rtc's config. go2rtc's auth middleware won't activate, CORS middleware will work, and lightNVR's own auth on port 8080 still protects the main application. Direct access to go2rtc on port 1984 would be unauthenticated, but that's a local network port — the same as how go2rtc works by default.

[ryann0097]

Yes. There is:

# go2rtc configuration generated by NVR software
api:
  listen: :1984
  base_path: /go2rtc
  origin: "*"
  username: <dummy-username>
  password: <dummy-passwd>

[matteius]

I believe 0.21.14 fixes this and that 0.21.13 it works possibly if demo mode is enabled....