wyze-bridge will only start 1 camera #2
Comments
|
I did some more troubleshooting. Turns out that it is the wyzecam-to-rtmp.py script that is not opening the 2nd camera. I ran it manually and now the camera 301 is streaming to nvr. /home/ron/wyze-to-rtmp/bin/python /home/ron/wyze-to-rtmp/wyze-to-rtmp.py --user [user] --password [pw] --cameraname "WyzeCam301" --url rtmp://127.0.0.1/wyzecam301 This is the same problem I was having when I tried to create a script to start this on boot. One camera would start but not the other. I am wondering if it might have something to do with this error: wyze-bridge | requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: https://auth-prod.api.wyze.com/user/login Perhaps wyze isn't allowing back-to-back logins? |
|
I am also having this issue. It seems like the wyzecam-to-rtmp script can only run one camera at a time. |
|
I can get 2, sometimes 3, cameras going at the same time. And it seems to be different cameras depending on which ones I try first. I get "ERR: no one is publishing to path" from the log above and also "ERR: path must end with a slash". From a discussion for another program also using rtsp-simple-server, there is some special consideration when using rtsp-simple-streamer and ffmpeg in the same docker. See the last message: |
|
Made some changes to try to catch the failed login or ffmpeg error and restart wyzecam-to-rtmp.py when it does.. I've run into them in the past, but they seem to come and go, which makes it hard to debug! |
Cool! I know it sounds like a dumb question, but how do I get these changes. I'm like totally new to docker. |
|
You may need to edit your docker-compose.yml with your credentials after pulling the changes. You can try something like this to rebuild the container: |
Simple enough. Don't need to specifically pull the new image first? |
That should pull the latest changes, and you'll probably need to update your credentials in docker-compose.yml before rebuiling. |
|
I'm still getting errors when trying to open more than 2 or 3 cams. The changes seem to make the streams that aren't going to connect die faster if that makes sense. VLC gives more errors, faster. Here is a log. I was manually trying to view the streams with VLC from another computer so I didn't try to access them all. |
|
The changes make it restart but I am still facing the issue with more than 1 camera |
So, the process seems to be: From /home/ron/docker/docker-wyze-bridge git reset --hard HEAD update your credentials in docker-compose.yml before rebuilding. docker-compose up --build --force-recreate --remove-orphans Did the above, restarted computer, all the cameras came up! I have one that just keeps disconnecting for some reason (the first one I installed!) but it eventually re-connects. |
I was having pretty much the same problem with one camera. Fixed it by using a different camera connected to a different access point. Changing the network connectivity a bit has totally resolved my streaming issues. This may not be your issue, but worth a try. |
|
It's working better for me now. I removed an offline camera from the Wyze app. I still get a lot of errors, but if I just ignore them and keep opening cameras eventually things settle down and the errors go away or are reduced greatly at least. I think my next step is to try it with some NVR software like Shinobi or Frigate. |
|
I made some minor changes to cameras.py. I forced one of my cameras to reboot and the stream eventually comes back on its own. Can update with: As @SomebodySysop points out, I'm wondering if the publishing error is due to a poor network connection on the camera forcing FFmpeg to drop frames...? |
|
Has anyone tried increasing |
|
I'm sure some of it is due to dropped frames and network/signal strength. All of my cams except one are outdoors. I added all of the cameras now as RTSP cameras in TinyCam. It takes a minute or two for everything to come up during which I get a lot of errors but after that everything works. I get occasional drop outs, but that's normal for me. Not having to remember/type in a half dozen different IPs alone is kind of great. My take aways are that maybe VLC isn't the best for testing this. It complains a lot and doesn't recover very well. Also, I tried to remove anything weird from my setup. I deleted an offline cam and a remote cam that was on a different account. I don't know if that helped or not. |
If you are on Windows, you might try ContaCam to test rtsp streams. Free to download, no setup to speak of. Just go to Camera->Network/IP Camera and enter in your camera's rtsp uri.
|
|
With the latest update, I am seeing that FFMpeg restarts but it the stream doesn't last very long and keeps on crashing (see logs below). Basically this keeps on happening in a loop. It works fine for one camera though. I just restrict the cameras by filtering out the result of |
I had the same problem, and I've been trying to think through the possible reasons. I'm just spit balling here, but... Are both cameras connecting to the same router or access point? If so, try connecting to different APs. I had the same problem when connecting all 3 of my cameras to the same router, which is my strongest but also ISP provided. I then switched it up and connected each one to a different access point closest to it. All 3 cameras have been running without fail now for over 24 hours. What I am saying is play around with your connectivity a bit, use different routers / access points if you have them. I have found this wyze-bridge to be so rock solid, that it is connecting to (and staying connected to) cameras that even the Wyze app fails to connect to. I have a camera on my back porch that I bring inside to set up using an ap that sits just inside the door. When I put the camera outside, Wyze has trouble finding it, but the wyze-bridge fires up the stream with no problems. Also, have you tried testing with rtsp as opposed to hls? |
|
@imhotep did you try increasing readBufferCount? You should be able to find it in /app/rtsp-simple-server.yml in the latest version. |
|
@mrlt8 I did but no changes. I am starting to think it's an issue with that specific camera. The feed only sticks for 36 seconds or so and then dies for some reason: Here are the logs with JUST that one camera: The question is why does the feed stop working after exactly 36 seconds? It seems unrelated to the wyze-bridge. |
|
hmm, could you see if commenting out line 22 helps..? docker-wyze-bridge/app/cameras.py Line 22 in c89b9fa
Could you try testing that camera using @noelhibbard's original script |
|
Hey @imhotep, I pushed an update to enable some additional environment options. You should be able to filter the cameras directly in your docker-compose.yml now. |
|
@mrlt8 I updated to the latest and unfortunately I am still seeing the same stuff My guess is that there is something up with that camera. It's not a connection issue as I've been able to leave the feed on in the Wyze app for 10 minutes without any interruptions. |
|
@mrlt8 I restarted the (faulty) camera and it seems to be holding strong for now! Great job! |
readBufferSize: 8192 in rtsp-simple-server.yml seems to help a lot. Streams are much more likely to recover if they freeze up. I tried increasing readBufferCount but the readme for rtsp-simple-server suggests 1024 for corrupted frames and it was already set to that. I tried 2048, 4096, and 8192 and didn't notice any appreciable difference. |
|
I spoke too soon. It's back to failing again. increasing the |
|
One thing I noticed today on my Wyze doorbell is if I am pulling a stream into my NVR, the Wyze app struggles to do a two way audio session when someone rings the bell. I got to thinking, the built in Wyze motion detection is probably cloud based so that is one stream from the camera. Then I have a second stream into my NVR. So the doorbell call ends up being a 3rd stream. I turned off all the built in motion detection (because it sucks bad compared to Frigate anyways) and after that I can make a successful two way audio session with it. Long story short, most homes have incredibly bad WiFi and even fewer people have any coverage at all outdoors. Trying to run multiple streams to these Wyze cameras is asking a lot. So try turning off the built in motion detection and see if stability improves. I've personally had no stability issues at all but I only have one V3 and one Doorbell but I also have seamless WiFi coverage that doesn't drop bellow 200Mbps at any location indoors or outdoors. |
|
That make sense.
does Also check the wyze app and make sure you can get a good stream there. |
|
The stream in the wyze app works fine (most of the time). It does freeze from time to time. I am going to try |
|
Actually it seems like it's doing the opposite? When DEBUG_NOKILL=True it's killing the stream immediately? Either way it keeps on dying. It works fine in the wyze app :/ |
|
Is there a easy way to clean up the high number (over 500) over zombie processes this app creates? |
Having the same problem with only 1 of 6 cameras. Discussed issue here: #5 (comment) Possibly an individual camera issue. But, without knowing what the issue is, no ideas on how to address it. |
|
@SomebodySysop yeah it seems like a very similar issue. The latest version of the bridge restarts streams whenever they die so it alleviates the issue somewhat. It's still unclear why streams die to begin with. It is not connectivity or too many auths as I am able to maintain a stream going in the Wyze app for longer than 10 minutes without issues. |
|
I am working on an update, and will upload soon! |
|
Hey @imhotep, I pushed a new update, which should get rid of those zombies and give out more info about the other streams! |
|
@mrlt8 sorry for delay. I was on holiday. I just updated. So far no zombies. I will update here if the issue persists. |
I have two cameras: WyzeCam301 and WyzeCam302
Wyze-Bridge appears to be working, but it will not start my first camera (301). It starts the second camera (302) fine. Is the program looping through and only creating stream for the last camera it finds?
rtsp-server | 2021/06/27 19:53:30 I [0/0] rtsp-simple-server v0.16.3
rtsp-server | 2021/06/27 19:53:30 I [0/0] [RTSP] UDP/RTP listener opened on :8000
rtsp-server | 2021/06/27 19:53:30 I [0/0] [RTSP] UDP/RTCP listener opened on :8001
rtsp-server | 2021/06/27 19:53:30 I [0/0] [RTSP] TCP listener opened on :8554
rtsp-server | 2021/06/27 19:53:30 I [0/0] [RTMP] listener opened on :1935
rtsp-server | 2021/06/27 19:53:30 I [0/0] [HLS] listener opened on :8888
wyze-bridge | Traceback (most recent call last):
wyze-bridge | File "/opt/wyzecam/wyzecam-to-rtmp.py", line 42, in
wyze-bridge | main()
wyze-bridge | File "/opt/wyzecam/wyzecam-to-rtmp.py", line 18, in main
wyze-bridge | auth_info = login(user, password)
wyze-bridge | File "/usr/local/lib/python3.8/site-packages/wyzecam/api.py", line 47, in login
wyze-bridge | resp.raise_for_status()
wyze-bridge | File "/usr/local/lib/python3.8/site-packages/requests/models.py", line 943, in raise_for_status
wyze-bridge | raise HTTPError(http_error_msg, response=self)
wyze-bridge | requests.exceptions.HTTPError: 500 Server Error: Internal Server Error for url: https://auth-prod.api.wyze.com/user/login
wyze-bridge | ffmpeg version 4.1.6-1
deb10u1 Copyright (c) 2000-2020 the FFmpeg developersdeb10u1' --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-sharedwyze-bridge | built with gcc 8 (Debian 8.3.0-6)
wyze-bridge | configuration: --prefix=/usr --extra-version='1
wyze-bridge | libavutil 56. 22.100 / 56. 22.100
wyze-bridge | libavcodec 58. 35.100 / 58. 35.100
wyze-bridge | libavformat 58. 20.100 / 58. 20.100
wyze-bridge | libavdevice 58. 5.100 / 58. 5.100
wyze-bridge | libavfilter 7. 40.101 / 7. 40.101
wyze-bridge | libavresample 4. 0. 0 / 4. 0. 0
wyze-bridge | libswscale 5. 3.100 / 5. 3.100
wyze-bridge | libswresample 3. 3.100 / 3. 3.100
wyze-bridge | libpostproc 55. 3.100 / 55. 3.100
wyze-bridge | Input #0, h264, from 'pipe:':
wyze-bridge | Duration: N/A, bitrate: N/A
wyze-bridge | Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1920x1080, 20 fps, 20 tbr, 1200k tbn, 40 tbc
rtsp-server | 2021/06/27 19:53:48 I [0/0] [RTMP] [conn 172.18.0.2:43860] opened
wyze-bridge | Output #0, flv, to 'rtmp://rtsp-server:1935/wyzecam302':
wyze-bridge | Metadata:
wyze-bridge | encoder : Lavf58.20.100
rtsp-server | 2021/06/27 19:53:48 I [1/0] [RTMP] [conn 172.18.0.2:43860] is publishing to path 'wyzecam302', 1 track
wyze-bridge | Stream #0:0: Video: h264 (Main) ([7][0][0][0] / 0x0007), yuv420p(tv, bt709, progressive), 1920x1080, q=2-31, 20 fps, 20 tbr, 1k tbn, 1200k tbc
wyze-bridge | Stream mapping:
wyze-bridge | Stream #0:0 -> #0:0 (copy)
wyze-bridge | [flv @ 0x559918d50280] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
rtsp-server | 2021/06/27 19:54:08 I [1/0] [RTSP] [conn 192.168.1.69:64069] opened
rtsp-server | 2021/06/27 19:54:08 I [1/0] [RTSP] [conn 192.168.1.69:64069] ERR: no one is publishing to path 'wyzecam301'
rtsp-server | 2021/06/27 19:54:08 I [1/0] [RTSP] [conn 192.168.1.69:64069] closed
rtsp-server | 2021/06/27 19:54:13 I [1/0] [RTSP] [conn 192.168.1.69:64070] opened
rtsp-server | 2021/06/27 19:54:13 I [1/0] [RTSP] [session 2575826756] opened by 192.168.1.69:64070
rtsp-server | 2021/06/27 19:54:13 I [1/1] [RTSP] [session 2575826756] is reading from path 'wyzecam302', 1 track with TCP
rtsp-server | 2021/06/27 19:55:08 I [1/1] [RTSP] [conn 192.168.1.69:50625] opened
rtsp-server | 2021/06/27 19:55:08 I [1/1] [RTSP] [conn 192.168.1.69:50625] ERR: no one is publishing to path 'wyzecam301'
rtsp-server | 2021/06/27 19:55:08 I [1/1] [RTSP] [conn 192.168.1.69:50625] closed
The text was updated successfully, but these errors were encountered: