Xmeye Cameras Not Working

[Karina Edling]

Initiallythe system worked flawlessly for months but recently the cameras go offline on the app and cloud (displaying the error 'The device is not online, try the other'). Meanwhile the system is still working and saving locally to the internal hard drive as usual.

I found powering down the router and cameras system then powering back on, then re-adding the system to the cloud (via barcode or manually typing in the serial no.) works for a few days, it eventually goes offline again.

Hi, I don't understand why would one ip camera dealer say I need to purchase an NVR that is Xmeye.com compatible for the motion detection to work with their ip cameras. Another seller tells me their NVRs had to be nvsip.com compatible, meaning, they say, it needs to be one with a Jovision chip. I'm confused. Does this have anything to do with variations of ONVIF implementations from different manufacturers?

The reason I'm asking, I don't want to set up my whole system, have the NVR break down and find out I can't get a replacement NVR for motion detection to work in my ip cameras because the company making the NVR no longer exist, if that's the case. I'm just being cautious because my crappy DVR stopped working properly after only six months of low usage (I'm changing from DVR to NVR for other reasons). Thank you for any response.

Setting up a camera to connect to your internet is usually easy these days, but if something goes wrong then it can get very complicated, very quickly. This article is intended to help people determine the cause of any connection issues when using one of our Wi-Fi or wired bird box cameras.

This is a list of the most common error codes that are displayed by the XMEye or iCSee apps, and their meanings. These apps are incredibly popular because they are used with cameras sold by a huge number of different companies; the 'brains' of the cameras are made by the same company (Xiongmai), thus the underlying technology is the same, so the cameras are all compatible with the same apps.

This article has become popular recently, so it seems that information on these error codes is limited. If you try one of these solutions and it does not work, or you have any comments at all, please provide some feedback.

This error probably means that the account you are using to log into the camera (not the account for the app) has limited permissions, and the action that was just attempted is not allowed on that account.

If none of these solutions resolve your issue, it may help to reset the camera and reconnect it, especially if it was working well previously. You can also create a support ticket on our help site to ask for advice from one of our Helpdesk team.

All of them have the same problem: initially, Security Spy will display a clear stream via the ONVIF profile. At an unpredictable point the stream will become garbled, in many different ways. With some its blocky colored artifact-rows, with others its mostly a grey image with a couple of coloured vertical stripes one will see. Sometimes the stream will recover by itself, sometimes not. This goes for H.264 and H.265 streaming XM cameras. I have tried to play around with advanced settings in Security Spy - to no avail.

Then I deployed the infamous XMEYE software "VMS" for Mac (Yes, I run Little Snitch and have blocked all phone-home domains of XMEYE in the router - you can not not run XMEYE Mac otherwise - or you shouldnt.) Turns out the stream is stable and clear. I noticed that XMEYE installer drops a couple of libraries on the Mac that seem to correspond with H.265 and 264. But I just get that from looking at the file names of the files that XMEYE installer places on the Mac.

If Security Spy relies on MacOS video decoding and, say, XMEYE does so, too - why has the one a garbled stream and the other a clear one? Sufficient to note that these cameras work all well on Windows and Linux. I was unable to connect to these cams using VLC, so I dont know whether its a MacOS problem or Security Spy specific one.

Anybody here in the forum who got XM cameras working with Security Spy? It would be a pretty good enhancement of Security Spy, as XM cams are really low cost, some of which still featuring very good low cost assembly quality, especially some PTZ ones. XM cams make up for most of the aliexpress IP cam stock, for example. When securely fenced off from phoning home, they could be used as low cost Security Spy connected cameras in areas that are vandalism prone and were cams get simply removed or smashed, for example.

SecuritySpy uses the macOS "VideoToolbox" framework for video decoding, which offers good compatibility and hardware-accelerated performance. But it's possible that the XMEYE software doesn't. Instead, it could use its own libraries for video decoding, or some standard library such as libavcodec, which is what VLC uses.

One thing that we have seen is some cameras alter their stream encoding parameters at regular intervals while streaming - these parameters are required for correct decoding of the stream. To check whether this is in fact the problem here, go to Preferences > Cameras > Device > Advanced Device Settings in SecuritySpy, and turn ON the option "Detect and adjust for video stream format changes". Does this resolve the issue?

No, it doesnt, the stream still scrambles out. I have the impression it does it specifically when there is a lot of motion ongoing. But not always, it also scrambles at night, with rather still images with a lot relatively "solid" black.

I have a relating question: I noticed that SecSpy does not stop recording when the screen goes to sleep. While, for example, that horrible XMEYE VMS software does. It disconnects the camera and doesnt record a thing when the screen is asleep. Is that down to VideoToolbox vs other libraries?

As for the screen sleeping issue with the XMEYE software - this won't be down to what particular decoder is in use, this could be something like App Nap (the suspension of apps by the system) or some other issue that SecuritySpy can cope with but the other software cannot.

When I set the advanced option "Detect and adjust for video stream format changes", SecSpy will display the live window mostly ok, although, sometimes, there will be the odd breakdown on the picture into blocks and artifacts. However, when I close the live view window with all cameras in it because I want to lower energy consumption of my Mac when it runs headless, the scrambling returns in the recorded video. That was the recording without re-encoding by SecSpy.

When I do the same but set SecSpy to re-encode the video stream, the recorded video stream will be ok only if I leave the live window open. When I close the live window and leave it running like that, for many hours, there will be no recorded video at all for this camera. Looks like SecSpy simply doesnt encode and write out recordings when the scrambling or format change occurs.

So by the looks, only a very energy intense work around seems to work for Xiongmai cams: that is setting "Detect and adjust for video stream format changes" in the advanced settings and set it to re-encode and leave the live window open and the screen active (I am using a DVI dongle that seems to keep the screen alive). For pure live monitoring that would be ok. But for remote headless recording its not. Is there any way to address this? Closing the live window will lower CPU impact by around a third, the MacMini goes noteably down in noise, with slower fan speeds and drops to lower energy consumption when I close the live window. Lower CPU impact translates into more cameras that I can set to higher quality.

Hi @uanoex, do you have the option "Decompress incoming video frames only when required" turned on in SecuritySpy's Preferences? If so, turn it off. Does this then allow you better recording success when the main video window is closed?

Unfortunately, that is working as designed. All Wyze products are cloud based and need access to their servers in order to work. You can access them using workarounds when the internet connection is down or missing but not using the Wyze app.

First, unless you are mounting that camera fairly low and around the rear bumper, there is no way you could compensate for the loss in lens angle to provide you a clear view of your vehicle rear. These cameras are not designed to be used in automotive applications. Latency is due to a wifi-connection which never mimic or compensate for lower throughput which is the reason why rear-view cameras are generally hard wired (my last four vehicles which came with OEM rear view cameras were all wired)

As Customer already pointed out, it is too dangerous to rely on these cameras in the applications they are not designed for.

After testing RTSP, it was found - in the absence of the Internet (you can see the camera constantly tries to connect to the cloud once a minute), the video transmission also stops (according to the protocol, it is similar to timing in 6 seconds, like a disconnection). Depending on the software (its own timeout is added), the video stops from 5 to 40 seconds. The program with the minimum time, has a video playback delay of 2 seconds.

I have a couple questions i'd like to ask to shed more light on the buffering issue. Were you experiencing any buffering issues before upgrading to the premier plan? Are you trying to view live streams on all 7 cameras at the same time when you experience the buffering? You could try reducing the quality of the camera feed for each camera. For example from "best video" to "best battery life". It sounds like it could be a bandwidth limitation with your internet connection or router. You can read more about the bandwidth requirements for each camera here.

3a8082e126