Unifi G3 Flex picture tearing
I'm not quite sure how to describe this, but every 10 seconds or so a part of the frame smears / tears on two of my Flex cameras. I have the latest build of SS, and I can see this occurring on both the Mac and the App.
I have just removed a couple of Hickvision cameras that were quite old, but I must admit didn't do this!
At the moment I don't have the Protect controller running so these were both in their standalone mode with everything set to max.
They were set up with the Unifi profile
Also every now and again the picture is delayed by 5-10 seconds....
If I monitor them directly in a browser they are perfect.
I have a third Hickvision bullet camera also running and that is perfectly stable
Before I start a load of testing, has anyone seen anything similar, or got any suggestions where to start?
Thanks
I have just removed a couple of Hickvision cameras that were quite old, but I must admit didn't do this!
At the moment I don't have the Protect controller running so these were both in their standalone mode with everything set to max.
They were set up with the Unifi profile
Also every now and again the picture is delayed by 5-10 seconds....
If I monitor them directly in a browser they are perfect.
I have a third Hickvision bullet camera also running and that is perfectly stable
Before I start a load of testing, has anyone seen anything similar, or got any suggestions where to start?
Thanks
Comments
A network issue is a common cause of these types of problem. How is your Mac and this camera connected? Ideally they should both be wired into the same Gigabit Ethernet switch, is this the case?
Also got a UDM pro coming so will run protect and then try streaming from protect, that may work better?
I can confirm I've now added UDM Pro and I still see it if I bump up the frame rate, its annoying mostly because it triggers the movement alert
I’ve got three G3 cameras and display the time on the screens and can often see one camera in particular be 40 seconds plus delayed. I’m using a quad core Mac Mini and it doesn’t appear to have high cpu usage. Any suggestions?
@evansgo are all your cameras the "G3 Flex" model?
@jeff444 do you also have the "Flex" cameras, or some other G3 model?
In addition I have tried running from theRSTP stream in unifi protect and using the camera in standalone mode with the same issues. makes no sense to me at all why this should not work in a stable way? Also tried 2 separate cameras with same results. its weird.
UVC-G3-Bullet / UVC-G3-AF
• 1080p Full HD, 30 FPS
• EFL 3.6 mm, ƒ/1.8
• Outdoor Weather Resistant
• 802.3af PoE or 24V Passive PoE
• Built-in Microphone
• Wall, Ceiling, or Pole Mount
• High-Power IR Range Extender
As far as we can tell this is not something that SecuritySpy is doing - the actual data coming in is compromised at this point, and nothing can be done to decode it properly.
One solution we have found is to use UDP transport rather than TCP transport. TCP is usually more reliable, but we do come across cameras from time to time that have problems with TCP for whatever reason, and operate much more reliably over UDP. UDP should work well provided you have a fast, reliable, wired network in place (not WiFi).
So, in the latest 5.2.4b12 beta version of SecuritySpy, we have enabled an "RTSP UDP" Format option, which can be selected under Preferences -> Cameras -> Setup.
So could you please all try this and report back.
I am connecting via Unifi Protect though and not with the Cams in standalone mode, not sure if thats making the difference.
The only format I can get to work is RTSP-over-HTTP, RTSP on its own doesn't work either, maybe I have something incorrectly set up?
IP is the UDM Pro
HTTP set to 7447
RTSP set to 554
USername and password are correct
Manual Config
Format is RTSP-overoHTTP
Request has the designated code in it.
Normally the daily report highlights the packet loss so will wait to see what it throws up over the next reporting period. Thanks.
- 105 movie files recorded
- 0 image files recorded
- 609 MB of data recorded
- 29 errors
- 99.8% camera uptime
Camera 2 Beta with release 12 UDP
- 178 movie files recorded
- 0 image files recorded
- 1.6 GB of data recorded
- 34 errors
- 99.6% camera uptime
Beta Release 10 and running on TCP
Camera 1
- 67 movie files recorded
- 0 image files recorded
- 246 MB of data recorded
- 63 errors
- 99.7% camera uptime
Camera 2
- 251 movie files recorded
- 0 image files recorded
- 1.0 GB of data recorded
- 60 errors
- 99.9% camera uptime
- 6 of 6 cameras currently online
- 5605 movie files recorded in total
- 0 image files recorded in total
- 51.7 GB of data recorded in total
- 99.9% software uptime
- 12% average CPU usage
- Normal memory pressure
A decrease in ERRORS and both have remained in clock sync - will have a real 24 hour result tomorrow
Looking much better so far!
The best way to compare is to use the Dashboard feature (either in SecuritySpy's macOS interface itself or via its web interface) and look at packet loss for these specific cameras when using TCP vs. using UDP. Are you both seeing a significant difference here? We certainly are with our test camera.
motion capture mode has been disarmed. (Failed to record video frame 5575,818 The key frame interval from the network device is too high, locate and change this setting in the device (may be called I-frame interval / I-frame rate / GOV length / Intra frame period))
Regards
30FPS and 6Mb connection perfect.
I may be doing something incorrect?
Really weird, seeing as the camera works at 6Mb within a unifi CCTV. I suspect the RSTP feed maybe lowered in this config hence always looks ok in a unifi setup
I'm running 15 UniFi cameras currently, a mix of G3, G3 Micro and G3 Dome, with a single G3 Pro and G3 Flex. They run in managed mode with Protect running on a UCKG2+.
I started with SS 3.x and three cheapo Foscams, but moved to UniFi after being impressed with their network gear, starting with a couple of cameras and building out. I tried them standalone connected directly to SS on my late 2012 Mac mini with 2.5GHz CPU and 8GB RAM, but at least back then (SS4 and no UniFi profile) it wasn't great and the cameras didn't let me use some functionality in standalone mode.
Soon after, I hooked them up to a UniFi NVR and Ben helped me set up an RTSP feed from there on port 7447 using RTSP (video and audio). It was rock solid and over time I've upgraded to the latest versions of everything involved.
I forget the sequence, but I've moved from UniFi NVR and UniFI Video to Protect on the CloudKey+, and SS of course moved to V5, which I upgraded to literally within minutes of seeing it released. The AI motion detection was an awesome improvement.
Aside the Micros which are WiFi only my cameras are all connected to one of 3 UniFi gigabit switches, except one camera (that also happens to be a Micro) which is in a different building that connects over a wireless PTP bridge of about 115m distance back to the main building. I get about 190Mbps each way over that link.
I had zero issues until 5.2.2 when I started to get several emails a day about excessive packet loss, pretty much from any camera. It was just bearable enough I could ignore it, but it 100% for sure started immediately after the upgrade to 5.2.2.
This past Sunday I upgraded to 5.2.3, and immediately I started getting slammed with hundreds of excessive packet loss emails within the first day - almost a round robin around my 15 cameras with something from 1 - 20 minutes between emails. I also started to get spurious alerts of vehicle motion from both G3 Domes in my closed and locked garage, or from the "remote" Micro.
While I absolutely have nothing but respect for the SS product and I have found Ben extremely patient and helpful this second issue was once more an immediate impact of the SS upgrade - nothing changed about the UniFi setup at all.
Anyway I just downloaded 5.2.4b12 and I had no interrupted connections nor any issue switching to use UDP, so I'll run that for a period and see what difference it brings, and of course report back here.
I had turned off email error notifications and will quickly know if part of the issue is resolved having re-enabled them just now. Nothing for a few minutes so far so fingers crossed...
I moved 14 of the cameras over to UDP, leaving one as it was previously (presumably using TCP?). I received on email about excessive packet loss around 30 minutes ago, and it was from the camera that has not ben moved over to UDP.
I also have had no spurious alerts / motion detections in that period.
Although early days that is very powerful evidence that the issue is resolved by using UDP as I had most definitely seen multiple issues within any 15 hour period since I updated to 5.2.3.
I have now moved the G3 Dome that was generating most of the spurious motion detections back to a TCP RTSP stream to see if it reverts to previous behaviour and will report back later.
Further to the above as I didn't hit the post button apparently, I have had a couple of email alerts and one spurious motion detection from the G3 Dome, way better than it had been over the previous 3 days, but still not as it should be.
I think therefore that 5.2.4b12 seems less noisy with the cameras running in TCP than 5.2.3 was, but with UDP in place of TCP it seems to be spot on.
What is odd is that it was an SS update that made a step change in the behaviour, not a UniFi one. Anyway, thanks Ben for your awesome support in assisting the two users above to confirm the fix which seems to have resolved my issue entirely.