docker-wyze-bridge
docker-wyze-bridge copied to clipboard
mrlt8
All streams buffering
Currently running a VPS on my mining rig with a docker instance of the wyze-bridge. (Testes on two VPS's, one locally and one in a remote datacenter)
When viewing streams, they play back normally for 5-20 seconds, then buffer for a few seconds. This keeps happening on repeat, and never "steadies" out. Something else I've noticed that the time in the bottom right of the stream goes faster than actual seconds sometimes.
Any assistance would be nice, as the cameras buffer for 2-10 seconds at times, and that causes the stream to be really behind at times.
Is this on the HLS or RTSP stream?
I'm using HLS and RTMP. They buffer and then skip to real time - delay. Right now I'm using HLS for my browser and RTMP inside of VLC/OBS does this.
I also noticed this, using RTSP. Additionally, I noticed that it is about 10 seconds behind real time as well. So I move in front of the camera, and 10 seconds later it appears in my dashboard.
@m50 Is it much worse than what you see in the wyze app? I believe rtsp should have the least delay.
Wyze app is real time. 0 delay whatsoever. But with this, it's behind by about 10s (sometimes a little more, sometimes a little less).
I also see 0 delay in the Wyze app, but when viewing the stream, the stream is always delayed at a minimum of 5 seconds. When the stream buffers, it starts playing back at 1.5x speed, then when it gets to the end of the buffer, it starts to buffer again. This infinitely repeats.
I am experiencing the same symptoms as everyone else on the latest version (1.0.3) as well
Logs:
wyze-bridge | 🚀 STARTING DOCKER-WYZE-BRIDGE v1.0.3
wyze-bridge |
wyze-bridge | 2021/11/26 20:43:36 [WyzeBridge] 📚 Using 'user' from local cache...
wyze-bridge | 2021/11/26 20:43:36 [WyzeBridge] 📚 Using 'cameras' from local cache...
wyze-bridge |
wyze-bridge | 🎬 STARTING ALL 3 CAMERAS
wyze-bridge | 2021/11/26 20:43:36 [WyzeBridge] Starting rtsp-simple-server v0.17.8
wyze-bridge | 2021/11/26 20:43:38 [Living Room] 🎉 Starting HD 60kB/s Stream for WyzeCam V3 "LAN mode" FW: 4.36.7.22 🔒 (DTLS) IP: 192.168.68.50 WiFi: 96%
wyze-bridge | 2021/11/26 20:43:38 [Living Room] WARNING: [First run] Wrong resolution: 1
wyze-bridge | 2021/11/26 20:43:38 [Living Room] WARNING: Frame not available
wyze-bridge | 2021/11/26 20:43:38 [Bedroom] 🎉 Starting HD 60kB/s Stream for WyzeCam V3 "LAN mode" FW: 4.36.7.22 🔒 (DTLS) IP: 192.168.68.55 WiFi: 92%
wyze-bridge | 2021/11/26 20:43:38 [Bedroom] WARNING: [First run] Wrong resolution: 1
wyze-bridge | 2021/11/26 20:43:38 [Living Room] WARNING: Frame not available
wyze-bridge | 2021/11/26 20:43:38 [Hallway] 🎉 Starting HD 60kB/s Stream for WyzeCam V3 "LAN mode" FW: 4.36.7.22 🔒 (DTLS) IP: 192.168.68.51 WiFi: 91%
wyze-bridge | 2021/11/26 20:43:38 [Hallway] WARNING: [First run] Wrong resolution: 1
wyze-bridge | 2021/11/26 20:43:38 [Bedroom] WARNING: Frame not available
wyze-bridge | 2021/11/26 20:43:43 [RTSP][LIVING-ROOM] ✅ '/living-room' stream is UP!
wyze-bridge | 2021/11/26 20:43:43 [RTSP][LIVING-ROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:43:43 [RTSP][HALLWAY] ✅ '/hallway' stream is UP!
wyze-bridge | 2021/11/26 20:43:43 [RTSP][BEDROOM] ✅ '/bedroom' stream is UP!
wyze-bridge | 2021/11/26 20:43:43 [RTSP][HALLWAY] 📖 New client reading
wyze-bridge | 2021/11/26 20:43:43 [RTSP][BEDROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:43:49 [RTSP][HALLWAY] 📕 Client stopped reading
wyze-bridge | 2021/11/26 20:43:49 [RTSP][BEDROOM] 📕 Client stopped reading
wyze-bridge | 2021/11/26 20:43:50 [RTSP][LIVING-ROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:43:50 [RTSP][BEDROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:43:50 [RTSP][LIVING-ROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:43:55 [RTSP][LIVING-ROOM] 📕 Client stopped reading
wyze-bridge | 2021/11/26 20:44:03 [RTSP][LIVING-ROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:44:032021/11/26 20:44:03 [RTSP][LIVING-ROOM] 📕 Client stopped reading
wyze-bridge | [RTSP][LIVING-ROOM] 📕 Client stopped reading
wyze-bridge | 2021/11/26 20:44:20 [RTSP][BEDROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:44:20 [RTSP][HALLWAY] 📖 New client reading
wyze-bridge | 2021/11/26 20:44:20 [RTSP][HALLWAY] 📖 New client reading
wyze-bridge | 2021/11/26 20:46:49 [RTSP][HALLWAY] 📖 New client reading
wyze-bridge | 2021/11/26 20:46:50 [RTSP][BEDROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:46:55 [RTSP][BEDROOM] 📕 Client stopped reading
wyze-bridge | 2021/11/26 20:46:55 [RTSP][LIVING-ROOM] 📖 New client reading
wyze-bridge | 2021/11/26 20:47:00 [RTSP][HALLWAY] 📕 Client stopped reading
wyze-bridge | 2021/11/26 20:47:07 [RTSP][LIVING-ROOM] 📕 Client stopped reading
docker-compose:
version: '2.4'
services:
wyze-bridge:
container_name: wyze-bridge
restart: unless-stopped
image: mrlt8/wyze-bridge:latest
ports:
- 1935:1935
- 8554:8554
- 8888:8888
environment:
- '[email protected]'
- 'WYZE_PASSWORD=my-password'
- SNAPSHOT=RTSP
- 'QUALITY=HD60'
- NET_MODE=LAN
volumes:
- ./tokens:/tokens/
And here's a video of how much delay there is:
https://user-images.githubusercontent.com/3577147/143637565-d6312dad-2046-426b-8af5-3c7b76cd1b5b.mp4
And for what its worth: The light changed instantly when I clicked the button, the delay is 100% in the video.
I also noticed that if I turn on DEBUG_FRAMES, the logs get spammed with:
wyze-bridge | 2021/11/26 20:43:30 [Hallway] WARNING: Frame not available
wyze-bridge | 2021/11/26 20:43:30 [Bedroom] WARNING: Frame not available
wyze-bridge | 2021/11/26 20:43:30 [Living Room] WARNING: Frame not available
Same problems as others reporting here (I understand this issue predates 1.0.3 but it seems relevant?), I did a little bit of bisecting
1.0.0 looks good 1.0.1 looks good 1.0.2 looks good (albeit with the memory leak after a few days or hours) 1.0.3 buffering every ~5 seconds as mentioned here
The "Frame not available" error is related to AV_ER_DATA_NOREADY, which usually means a poor connection to the camera:
The data is not ready for receiving yet.
1.0.3 will break out of that loop if it receives 500 or more consecutive AV_ER_DATA_NOREADY since the rtsp-simple-server connection will break if it does not receive any data.
Is there a delay if using a single camera?
I used to be on a really old version of this project and old camera firmware but when I brought everything up to date I started having issues, no change in wifi strength.
@mrlt8 FWIW (and I think we might be mixing a few issues here, hard to say) I experience the constant buffering with a single camera only in my setup
Is there a delay if using a single camera?
Yeah, I tried filtering to only support one camera, and the delay was exactly the same.
I am also noticing that when it lags, the rtsp stream displays them out of order, the timestamp would jump between frames 5 seconds before and current frames.
Well, I switched to webrtc card and my delay is gone. There is still some delay, but it's nothing compared to the picture card.
So for people using this with HA: I highly recommend trying that card if you are having lag.
Correction: Buffering still happens, but the delay is gone. So it sometimes skips ahead by like a second, but far less frequently.
The separate problems I see in this issue are 1) constant buffering and frame skipping in newer versions and 2) delay compared to wyze app
@mrlt8 do you want me to open up a separate issue? 1.0.4, 1.0.3 and 1.0.2 are all pretty unusable and I want to help get the data needed to resolve it.
I have 1 V3 camera, and either get ~5 second skips every ~10 seconds in the latest version or buffering every few seconds in 1.0.2. Tested HLS and RTSP, both are unusable
I have 0 errors or warnings or messages in the log
2022/01/09 17:18:27 [camera1] 🎉 Starting HD 120kB/s Stream for WyzeCam camera1 "LAN mode" FW: 4.36.8.15 🔒 (DTLS) IP: xxx.xxx.xxx.xxx WiFi: 79%
I think this might have something to do with the buffer which was also causing that memory leak issue.. I'll try to play around with it some more.
Could you also try to physically reboot the camera? I've noticed some weird issues communicating with the cameras that will sometimes go away after a reboot.
I think this might have something to do with the buffer which was also causing that memory leak issue.. I'll try to play around with it some more.
Could you also try to physically reboot the camera? I've noticed some weird issues communicating with the cameras that will sometimes go away after a reboot.
I agree that it seems related to the the part of the code with that recent buffer/memory leak
Sorry, I decided to just try the RTSP FW for the V3 and so far it has been solid, I will poke back in if I have issues and try to get you the data you need. A few other people seem to be having similar problems so maybe someone else has an active/problematic setup that can help a bit
So was running this with the home assistant addon on the RTSP firmware and was working perfectly. So, I decided if I wasn't going to use sound I might as well upgrade to the latest firmware and take advantage of DTLS and further firmware upgrades. Upgraded one camera that was easy to reach and decided to do the others later since I need a ladder to get to them. The DTLS firmware camera then would stream fine for 10-12 seconds, then skip/stutter for a 4-5 second break. Been like that for 2-3 weeks now as I tried to sort out the issue but couldn't.
Then came across this. Decided to stop the addon and recreate in a Portainer stack pulling version 1.0.0. DTLS firmware camera better, but still not as smooth as RTSP firmware camera. Rebooted DTLS firmware camera, put fresh_data=true in the stack and re-created. Perfectly smooth. No stuttering or skips and performance of DTLS firmware camera and RTSP firmware camera are on par.
Then came across this. Decided to stop the addon and recreate in a Portainer stack pulling version 1.0.0. DTLS firmware camera better, but still not as smooth as RTSP firmware camera. Rebooted DTLS firmware camera, put fresh_data=true in the stack and re-created. Perfectly smooth. No stuttering or skips and performance of DTLS firmware camera and RTSP firmware camera are on par.
Been having stutter problem with DTLS myself: https://github.com/mrlt8/docker-wyze-bridge/issues/275#issuecomment-1022870100
My fix was to revert to earlier non-DTLS firmware. How did you fix the problem? I see put fresh_data=true in the stack and re-created but don't understand what that means.
I am running Portainer. My docker-wyze-bridge stack says: "This stack was created outside of Portainer. Control of this stack is limited", but I can edit it. Just don't know where I would put "fresh_data=true". Little help?
I think this might have something to do with the buffer which was also causing that memory leak issue.. I'll try to play around with it some more.
Could you also try to physically reboot the camera? I've noticed some weird issues communicating with the cameras that will sometimes go away after a reboot.
I tried rebooting the camera. Still did not resolve the issue.
I have the same issue. Plays fine for about 10 seconds and then 3-5 seconds of buffering (Wyze timestamp frozen). Tried with just one camera and still saw the issue.
I have the same issue. Plays fine for about 10 seconds and then 3-5 seconds of buffering (Wyze timestamp frozen). Tried with just one camera and still saw the issue.
I believe this is an issue between DTLS and wifi connectivity. I live in a densely populated area, and have this problem with almost all of my Wyze V3 cams that are outside. I have reduced the buffering | stuttering by reverting the firmware to a non-DTLS version: https://github.com/mrlt8/docker-wyze-bridge/issues/275#issuecomment-1022870100
Buffering has reduced from every 10-15 seconds to every 20-30 seconds. Significant improvement, but not eliminated.
I suggest, as a test, you try reverting to firmware version 4.36.3.19 to see if there is any difference in performance.
Just tried this today and had the same issues in all my 3 cameras (2 v2 and Doorbell): the video would freeze every 10s and then recover skipping the next 5s. When I reverted to v1.0.1 the problem was gone. All my cameras are in the latest FW (from the main Wyze stream, not RTSP)
Tested v1.1.0 with 1 doorbell and this problem persists. It seems a bit better, freezing every 20-30s for around 5-10s, but it's still there. Reverted to 1.0.2 and it works fine. Also, on 1.1.0 I had to change IGNORE_RES to 3 instead of 4 in 1.0.2
Having similar problems with 1.0.4 and the recently deployed 1.1.0. Reverted container to 1.0.2. and it's now working rock solid for several minutes (getting almost the same performance as Wyze app): no AV_ER_DATA_NOREADY errors or dropped frames. I have three v3 cams with latest FW and i'm running this with just one of them.
I'm testing this on Win10 using Docker Desktop with WSL2 backend (!!) ... just fiddling with this to eventually migrate to a Raspberry Pi or HPE dedicated server with Linux.
Does increasing the MAX_NOREADY value to something like 300 help?
v1.1.x is also dropping frames until it receives a keyframe to prevent the corrupt frames/time glitches, so we may have to tweak that a bit more.
@tcnasc v1.1.x should already ignore 3 if IGNORE_RES is not set. Can you try running the container without IGNORE_RES ?
https://github.com/mrlt8/docker-wyze-bridge/blob/d899495e6ba8b421cffbd54c5232e35c4b2d92cd/app/wyzecam/iotc.py#L414
@mrlt8 You're right, I don't need to set IGNORE_RES anymore with 1.1.0 I tested with MAX_NOREADY=300 and the issue is still there. I'm running on Pi OS by the way Enabling the debug logs I noticed that when the stream breaks, the Frame Not Available counter starts increasing up to 40-60 and then returns to constant 1 which is when the stream starts working again. So it looks like the frame not available is actually a consequence and not the cause of the stream breaks.