Six of the nine cameras in my Frigate setup are wired Hikvision units, and they have never given me a moment of trouble. The other three are Wyze cameras on WiFi, and they would not stay connected. Streams dropped constantly, the logs scrolled errors, and the live view spent half its time reconnecting. This is what I tried, what helped, and the honest place it ended up, because part of the problem turned out to be the cameras themselves.

The symptoms, and the tell

The Frigate logs were a wall of stream failures: connection timeouts, “no frames received,” corrupt decoded frames, and a steady stream of non-monotonic DTS errors. FFmpeg’s watchdog was tearing the streams down and rebuilding them over and over.

The clue that mattered was where else it happened. The same Wyze cameras were just as unstable in Home Assistant as they were in Frigate. Same cameras, two completely independent consumers, the same drops in both. That pointed away from Frigate and at the cameras and the path to them.

Stop hitting the camera from two places

Wyze’s RTSP can barely hold a single connection, and I had Frigate and Home Assistant each opening their own direct stream to every camera. For a weak camera that is asking to be knocked over.

The fix is to put go2rtc in front. go2rtc, which Frigate already bundles, makes one connection to the camera and restreams it, so Frigate and Home Assistant both consume go2rtc’s restream instead of the camera directly. One stream off the camera instead of two or three. For hardware that struggles with a single RTSP session, cutting the number of connections to it was the single biggest improvement.

Kill the audio

Those non-monotonic DTS errors were the audio track. Wyze’s audio timestamps arrive out of order, and FFmpeg refuses to process a stream whose timestamps go backwards. I do not need sound from a security camera, so I disabled audio entirely and ran the streams video-only. That whole class of error disappeared.

TCP, longer timeouts, and the firewall

Three smaller changes rounded it out:

• TCP transport instead of UDP. Over WiFi, UDP packet loss shows up as corrupted video. Forcing RTSP over TCP trades a little latency for a stream that does not shred when a packet drops.
• Longer timeouts. I gave go2rtc a 60-second timeout with a 10-second retry, so a brief WiFi blip does not immediately tear the whole stream down and trigger a full reconnect.
• Open the RTP ports as well. RTSP sets up the session on port 554, but the actual media flows over a separate range of UDP ports. My cameras live on an IoT VLAN, and the firewall was only allowing 554. The control channel connected and the video did not, until I also opened the RTP UDP range (5000-5999) across the VLAN boundary.

Where it landed

All of that made a real difference. The streams connect, Frigate consumes the restreams, and the audio errors are gone for good. But I want to be honest about the result: it is not fixed. In one fifteen-minute window I still counted 55 stream restarts.

The remaining drops are the cameras. The Wyze v1 RTSP firmware is a beta, running on hardware that was never designed to be a dependable RTSP source, on WiFi. Software can paper over a lot, and it did, but it cannot turn a flaky camera into a solid one. The wired Hikvision cameras still do the serious work, and the Wyze units are a nice-to-have I have stopped fighting. The real fix, when I get to it, is better cameras.

Lessons

• When a device misbehaves in two independent apps, the device is the problem. The Wyze cameras were flaky in both Frigate and Home Assistant, which ruled out either of those being the cause.
• Restream once, consume many. Putting go2rtc in front of a weak camera means one connection to it instead of one per consumer. For a camera that can barely hold one RTSP session, that is the biggest lever you have.
• Disable audio you do not need. Non-monotonic DTS errors are almost always the audio track. A security camera does not need sound, and dropping it removes a whole category of failure.
• Open the RTP range as well as port 554. RTSP negotiates media on a separate UDP port range, so if the firewall allows only 554, the session connects and the video never arrives.
• Software mitigations have a floor. I got these cameras much more stable and they still drop. Past a certain point the answer is better hardware, and no amount of configuration substitutes for it.