Summary: If any device on your tailnet advertises a subnet route covering your own home LAN (a router like a UniFi gateway, or a NAS, Pi, etc.), the DVR's built-in Tailscale sometimes sends traffic to local sources through the tunnel to that router instead of straight across the LAN. On my setup, that made recordings from a LAN-based M3U source (PrismCast) drop 30-110 s chunks, sometimes dozens per recording. Turning off the built-in Tailscale fixed it immediately.
Setup
- Channels DVR beta 2026.10.14.1921 on a QNAP TVS-h474 (native package). Built-in Tailscale was on (embedded client reports 1.82.5-dev20261014).
- LAN M3U source (PrismCast) on a Mac at
http://192.168.x.29:5589/playlist. The DVR is at 192.168.x.45, on the same /23. - A UniFi Cloud Gateway Max is a Tailscale subnet router advertising
192.168.x.0/23. I need that route for remote access to non-Tailscale devices. A Synology NAS also advertises the same route as a standby subnet router. The DVR used whichever was primary (the gateway), and a standby taking over would presumably produce the same behavior.
Symptom Recordings from the LAN source logged hls: temporary failure while downloading: hls: timeout while waiting for data after ~35 s, then skipped ahead. That meant 1–3 drops on a good night and 24 on a bad one (an SNL recording lost ~16 minutes). Internet sources (Fubo/Paramount) on the same DVR were consistently clean.
What I found
- The source host saw every DVR request coming from the gateway's LAN IP (192.168.x.10), not the DVR's, going back weeks. The DVR process had no direct TCP connection to the source at all.
- Other processes on the same QNAP (curl, iperf3) reached the source directly and never stalled. That's why every network test I ran came back clean.
-
channels-tailscale.logshows the DVR's WireGuard peer (the gateway) flapping paths between the gateway's LAN address and our public IP (hairpin), 8–38 times an hour. It occasionally fell back to a DERP relay (NYC). - The stalls line up with those events. For example, a handshake and path switch at 00:09:38 marked the exact start of a stall that ended in a drop at 00:10:13, and a "adding connection to derp-1" at 01:11:46 coincided with a drop at 01:11:45.
- CPU-heavy work in the DVR process made it worse: drops clustered near the end of Enhanced+ fingerprint jobs, presumably because userspace WireGuard competes for the same 2-core CPU.
Before/after (same 3-hour recording)
- Built-in Tailscale ON, first 75 min: 3 drops, ~38 retries
- I turned it off mid-recording (
DELETE /remote/tailscale). The next 105 min: 0 drops, 0 retries. The source immediately saw the DVR's own LAN IP. - A follow-up 2.5 h test with Enhanced+ on and two fingerprint jobs plus a second recording running alongside: 0 drops, 0 retries.
Parallel pings, a parallel iperf stream, NIC counters and fresh HTTP connections all stayed perfectly healthy throughout, so the LAN itself was never the problem.
Suggestions
- The built-in Tailscale shouldn't route traffic for the DVR's own directly connected subnet into the tunnel, even when a peer advertises a route covering it. Alternatively, expose an "accept subnet routes" toggle. Right now the only setting is on/off.
- It may be worth a note in the docs: with a home subnet router, local sources may go through Tailscale.
Related threads with similar symptoms: Tailscale Connected = No Local Network (Dec 2023) and Custom Channels Issue with v2026.02.17.0559 (Feb 2026), where turning off Tailscale restored LAN sources. I think this is the mechanism behind those, in an intermittent form.
Happy to send diagnostics or logs.
And yes, Claude helped me both diagnose this and write up this summary here. I'm not sure I would've discovered it otherwise, but I sure am glad to have the workaround (of disabling Tailscale in Channels for now).