I agree. I can’t pinpoint exactly what the trigger is for it failing, though I do use the Wyze app as a backup/verification tool. If iVideon does not notify me when the Wyze app notifies me, I know that I need to give the Wyze cam a restart for RTSP. That said, it does not happen often.
Running Linux with ZoneMinder in a Docker Container with the latest RTSP beta firmware (flashed the beta but sure it was network settings) with sold stream with slight artifacting with high motion. Check your WiFi AP MMS settings and Airtime Fairness. Turn OFF Airtime Fairness and try changing WMM (ON worked for me) to see if it changes your reliability.
Did you try the test I suggested a few days back, i.e. :
@InnocentBystander I don’t think I said I was running Zoneminder. I am trying to use iVideoN Server. Not Zoneminder.
Thanks
@fryguy I’m not using Zoneminder. I find it difficult to install and setup. I’m trying to use iVideoN Server which is much more user friendly.
I’m not sure what you mean by this:
If these ^^ are Zoneminder settings it might explain why I don’t understand.
Thanks
It’s the WiFi AP settings. I know you’re not using ZoneMinder it’s what I’ve been currently testing out. I was having dropout issues with VLC and others until changing WiFi AP settings.
Gotcha. It doesn’t appear that my Google WiFi mesh supports Fairness or WMM.
Sorry about the zoneminder vs iVideon confusion.
You may still want to try the test of running vlc from the machine where you’re running iVideon.
If vlc can hold the connection then you’ll know the issue is specific to iVideo. If vlc can’t hold the connection, it may give you some information that helps us to understand what’s going on, or you could try running vlc from a second machine to confirm that it’s neither iVideon nor the machine and is really something specific to your Wyze cam or to your wifi network.
VLC does have the best performance, but from a OSx machine on the same network. (Can’t get VLC installed on particular Linux box). But I’ll try getting it onto another Linux box just to follow your troubleshooting method.
Cool. If you already know that vlc from an OSx machine on the same network has acceptable performance, then you already know that the problems are not due to the Wyze cam itself, or to the wireless network that the Wyze cam is connected to. That leaves iVideon, linux, or the specific machine on which you’re running iVideon as possible culprits.
just for the record I bough one Wyze camera as an experiment to try the RTSP function. It works great for me. I also have a 128 MB SD card installed that acts as a “backup” record.
I have since bought 4 more based on that one - simply due to the RTSP capability. I do have some concerns for the future:
- due to WiFi only there must be a point where I will eventually run out of AP bandwidth (note: all of the cameras are not on the same AP at present, but if I keep adding them, then…). I would prefer a wired POE solution. Willing to pay more for that. WiFi is also prone to jamming in “extreme” security cases.
- direct download access to the SD card contents over the link would be good in cases I need to access the SD card contents in a “mass” way.
Is it just me or does there appear to be a limit of 3 cams before the RTSP stream becomes completely unstable? I have setup my cams using Zoneminder, Motioneye, iSpy, and Blue Iris. In docker setups as well as blueiris on a windows PC. I have played with nearly every single router setting with these setups over the past couple of weeks and I have noticed that once the third feed is introduced everything goes to hell in a handbasket.
I have an ORBI setup at home and I have carted these four cams to work with me and the results appear to be the same regardless of platform, bandwidth etc…
Initially I thought the poor performance was due to my initial setup using motioneye through a docker container. I installed the first two cams and everything was fine overnight. I woke up the next morning and added the thrid cam and I had 5 hours of “No Signal” messages. I switched to non-docker implementation, then Zoneminder. After a few days of frustration I switched to a windows setup and pretty much received the same results. Mesh network or otherwise, same issue.
I had issues since my first RTSP cam… I now have 3.
Using blueiris, i can see how many lost connections happen, the 2nd cam drops the least, maybe 20 times in a few days, camera 1 and 3 drop hundreds of times…
they reconnect after few seconds.
with my 3 cameras it is very usable but not perfect.
my mesh wifi system has very few options. nothing that can help.
I am currently using blueiris now. When I connect just two cameras, it is rock solid. I set up some pinwheels outside to make sure the motion is constant and not some weird lag.
When I connect the third camera, all the signal immediately drops to all 3 cameras and then 2 will come back up. After less than a minutes 1 cam will no longer have an actual feed, but blueiris doesn’t show the dropped signal for about 15 seconds. Then the process continues non-stop…
I even started up my linux box with motioneye on it and ran it simultaneously with my windows box running blueiris. Once the cam on my linux box connects the other cams drop off, and when one of the Blueiris cams connects then the linux cam will drop. I am at a loss.
1 Like
I do not use the “recommended settings” from the forum mod. I do not have UTP port checked.
when i tried it, it crashed my 3 streams.
in blue iris > camera properties > video > UTP port UNCHECKED (each camera)
@lootiejay thank you for your post! I’m glad somebody finally gave RTSP a good run across multiple platforms as you appear to have done and provided comprehensive feedback.
Using Google WiFi mesh, I have tried iSpy, iVideoN, IPCamViewer (smartphone) & TinyCAM (smartphone) and seen wildly different behavior across those. Some have commented that if it works well in VLC, then it should be acceptable. I don’t agree. A good RTSP feed should be stable across many platforms. The sentiment I’ve seen all along is that there is a lot of instability, underperformance and unexplained behavior which just doesn’t meet the need for any CCTV system. Good progress has been made to get to this stage, but RTSP is still unusable.
I am hoping Wyze R&D will make some comprehensive reply to all of this soon.
1 Like
I hope so as well. A good friend of mine has a kennel and wants to provide customers the ability to view their dogs “realtime”. Wyze Cams are a good option because they are inexpensive and easily configurable. I told them I would run a test regarding the reliability of the stream because I honestly thought that it would be a valid option(I still hope they will). I am hoping that they will provide some form of update regaarding whether they hae made any progress or if it is basically just a take it or leave it as is. Either way, I plan to use the cams moving forward.
Last night, across multiple platforms I utilized four feeds from each cam. Flawless for over 3 hours. I injected a third camera, just one extra feed and it bombed. I am sure that there isn’t a three cam limit for RTSP but it just seems very strange.
3 Likes
Limits won’t work. I need to run at least nine or ten cams.
1 Like
9 or 10 cams is a fair amount for any WiFi router if it’s possible they’ll all be seeing activity at the same time. Have you been running this many cameras while you’ve been encountering your RTSP problems, and does Google WiFi allow you to see the CPU utilization on the router?
Also, do you live in close enough proximity to others, that you can see many other WiFi networks on your phone? If there are many of them they will also limit the performance you can get.
maybe a dumb question, but does anyone know the compression that this RTSP stream is using? (e.g. h264, mpeg4, mjpeg/jpeg)
Im running my cams as 1080p 15fps through MotionEye, and they report through the wifi as using 2Mbps each. Not sure whether changing the resolution or fps within MotionEye actually changes the stream parameters and results in different bandwidth, or the stream is the same regardless and just transformed as it hits MotionEye.
So far I have never had any dropouts and needed to reset the cams. The worst that I get is stuttering every now and then where I will miss 1-2 seconds of movement on the compressed output.
On that as well, through MotionEye I cant get anywhere near the compression or quality I get in other applications. The best compression I can get is around 1MB/s in the video file, using MPEG2. Strangely, H264 and H265 HEVC have less efficient compression. What is everyone else using and what compression do you get?