search

motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
3.93k stars 652 forks source link

Unable to open video device - RTSP stream works on other software #2295

Open valemaio2 opened 2 years ago

valemaio2 commented 2 years ago

Hi, I've got MotionEye (motioneye:master-amd64) running on Docker on top of Linux Mint Lubuntu 20.04. For the camera, I've got a generic surveillance camera streaming under RTSP protocol. Since a few days past, MotionEye will just display a grey picture with a laconic "Unable to open video device" error message. Trying to set up the camera once again only gives the error message "Connection reset by peer". The streaming works just fine on ONVIF device manager under Windows 10, so I can exclude a connection issue. The only workaround is to change the RTSP port on the camera settings, then it will start working again for 24 hours or so before giving the same error. What am I looking at? What log files should I be checking?

starbasessd commented 2 years ago

What URL are you using for the camera? Do you have the firewall enabled in Mint? Which version of Mint? When you lose connectivity, can you still ping the camera in Mint? If you have the full desktop installed in Mint, do you have VLC installed? If yes, when motionEye docker fails, are you able to see the RTSP video feed in VLC in Mint?

valemaio2 commented 2 years ago

What URL are you using for the camera?

rtsp://192.168.0.116:1027/11

Do you have the firewall enabled in Mint?

Yes, UFW is enabled and port 1027 is open. 1027 is also open on the router.

Which version of Mint?

My bad, I'm actually running Lubuntu 20.04 LTS, on kernel Linux 5.13.0-28-generic. If it makes any difference, Lubuntu runs on top of ProxMox 7.1-10

When you lose connectivity, can you still ping the camera in Mint?

Yes, I can indeed

vale@lubuntu:/$ ping 192.168.0.116 PING 192.168.0.116 (192.168.0.116) 56(84) bytes of data. 64 bytes from 192.168.0.116: icmp_seq=1 ttl=64 time=3.59 ms 64 bytes from 192.168.0.116: icmp_seq=2 ttl=64 time=4.77 ms 64 bytes from 192.168.0.116: icmp_seq=3 ttl=64 time=3.65 ms 64 bytes from 192.168.0.116: icmp_seq=4 ttl=64 time=3.65 ms 64 bytes from 192.168.0.116: icmp_seq=5 ttl=64 time=3.79 ms ^C --- 192.168.0.116 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4008ms rtt min/avg/max/mdev = 3.591/3.890/4.772/0.445 ms vale@lubuntu:/$

If you have the full desktop installed in Mint, do you have VLC installed? If yes, when motionEye docker fails, are you able to see the RTSP video feed in VLC in Mint?

My Lubuntu installation has both a desktop environment and VLC, but it cannot open the RTSP stream, neither can I on VLC for Windows 10. However, it works just fine with a different RTSP program for Windows 10, on which I can open the stream just fine.

In the picture below, there's the stream from that Windows program. I've just obscured the actual camera picture.

camera

starbasessd commented 2 years ago

The standard port for RTSP is 554. Is there anything available on port 554? MotionEye supports most of the cameras in the iSpyConnect database. I am surprised that VLC can't open the video stream. The 'other' program, is it a generic ONVIF, or specific to your camera. If you turn off the firewall (for testing) what is the status of access? Can your Win10 open the VLC RTSP stream?

valemaio2 commented 2 years ago

I've modified the port myself for "security" reasons (useles I know, but it puts me at ease). I could use port 554 but, again, it would only work for 24 hours or so.

The program on which it works under Windows 10 is just a generic ONVIF program, nothing special. I've attached a picture in my previous comment. Firewall makes no difference, either the router or Lubuntu ones. Strangely enough, the RTSP stream doesn't work either, but I think it's just because I can't find the correct address for it.

starbasessd commented 2 years ago

Please check if your camera is listed here

valemaio2 commented 2 years ago

It looks like it is, it's an ieGeeek 1080p model. I've tried the RTSP generated by that website in VLC and still no cigar, but again it baffles me how it just works under that generic ONVIF software for Windows.

Correction: it does work under VLC using the correct JPG link, but only for a split second.

starbasessd commented 2 years ago

The Windows machine probably doesn't have it's own firewall.

There is something that 'leaps in' and blocks it, then.

Is it the router firewall? How is the camera getting through to the network? Is there a separate Wifi router? Does it have a firewall? Are you using a Wifi Extender? Does it have a firewall?

valemaio2 commented 2 years ago

I think I should just go to sleep and stop pretending I know anything about IT...

So, the camera is on an IP ending in 116, but on the router I've opened the port for an IP ending in 115... Now, after opening the port for the correct IP, re-adding the camera works just fine. I'll keep it testing for tonight, and if by tomorrow it's still there I will consider this solved. BTW to answer your question, the camera is connected via ethernet to my router, a TP-Link Archer AX50, which then connects to the modem, a Netgear Nighthawk D7000 in modem only mode.

Thank you very much for now.

Very quick update: again, close but no cigar. I can add the camera now, but the stream has just stopped again with the "unable to open video device" error.

valemaio2 commented 2 years ago

MotionEye is still unable to open the stream, while other programs can. Also it would have been strange that, with the wrong port open, MotionEye would have been the only program to not being able to open the stream.

starbasessd commented 2 years ago

One last thing to try: Delete the camera, and re-add it, but in the last box, see if you can change RTSP/TCP Camera to RTSP/UDP Camera and see if that makes a difference.

valemaio2 commented 2 years ago

I've already tried that yesterday, and unfortunately selecting either TCP or UDP has no effect.

starbasessd commented 2 years ago

did you try the following URLs: http://ip_address/videostream.cgi http://ip_address/axis-cgi/mjpeg/video.cgi motionEye is not very 'forgiving' as to the RTSP protocol. Also, I am not sure it is motionEye, as you are reporting issues in anything but the ONVIF application and VLC is the most flexible video app out there.

valemaio2 commented 2 years ago

I've tried those 2 URLs just now. They both get recognized and they both give me the option of either TCP or UDP, but neither of them can stream the actual video feed. And yes, I've also completely removed MotionEye and its image and volume (including the /ect/motioneye folder), and still I'm getting no picture.

I'm really not sure what is going on at this point, I've tested Shinobi (another CCTV application) and I can see the video stream just fine.

starbasessd commented 2 years ago

I don't know what else to try. You've given conflicting info above, so I will leave this to see if anyone else can contribute...

bags-lights commented 2 years ago

I'm having the same issue. I'm the IT admin where I work and I've got motioneye and motion running in a Ubuntu Server 20.04LTS VM. The cameras I'm attempting to use in motioneye consist of 2 standalone rtsp ipcams and 16 analog cctv cams on a 16 channel Invid DVR that encodes all 16 inputs into RTSP streams. I'm getting the same inconsistent "Unable to open video device" or "Connection to camera lost" errors but only on the cameras from the DVR. The 2 standalone cameras have not had any issues whatsoever, they just work. What doesn't make sense is that I can use vlc to open an rtsp stream to any of those 16 cameras while motioneye isn't working. It's inconsistent too. They'll randomly just come back at times and then error out again a few minutes later. I've completely wiped out all my camera configs and started with an empty motioneye page. I'll start adding back cameras from the DVR and everything will work fine until I get to the 6th camera on the DVR. That 6th camera will start intermittently dropping video until all 6 of the cameras added from the DVR drop and stay dropped for some time. As I mentioned though, at the same time, I can consistently open all of them from vlc with no issues. I've tried TCP and UDP and that change has no effect. I've verified my rtsp syntax and it's solid. I also thought maybe I was running into a resource bottleneck on my Ubuntu VM so I bumped the RAM up to 8gb and gave it 4 processor cores and that didn't fix anything. I've used motioneye-os for years on RPis at my house for years without significant video erros like this so I'm starting to think motioneye doesn't like rtsp all that much. At the same time though, I'm still stumped on why the 2 standalone cameras work perfect over rtsp. I would just assume that it's our garbage DVR's fault but like I've said, I can raise any of those cameras through vlc. Idk, might not be the exact same problem but the failure mode seems identical. Got any ideas?

P.S. - Was half writing this comment out of frustration because all 6 of those cameras dropped AGAIN. I'm literally finishing writing the above comment when they come back on. Of course, smh

P.S.S. - JK, they died again while writing the first P.S.. Please help, my sanity is starting to develop runtime errors =)

bags-lights commented 2 years ago

Btw, I know you all think I'm nuts for trying to polish a turd with integrating my existing DVR/Camera gear into a motioneye deployment. For context, I'm trying to use motioneye in this manner for a couple reasons:

zagrim commented 2 years ago

@bags-lights One thing that came to my mind while reading your story: When you've ran vlc to check on the camera that fails in ME, have you ran that on that same Ubuntu VM ME is running on? If not, could you please try to run vlc there. This is to rule out any non-ME / non-Motion issue getting to that stream in proper fashion in that VM (like, network bottleneck or something like that). I didn't bother guessing how much bandwidth 6 cams would total, probably not too much, but perhaps there's a bad network device that does funny things when the amount traffic reaches some level and characteristics.