I found a work around for one of my cameras (Amcrest 841 PTZ model non version 3) as it will return with a http error 500 code (Internal Server Error) often when you ask for a snapshot. This happens when you ask with any web browser, even at slow refresh rates. Since this camera appears to be made by Dahua, other cameras that share the same firmware code may find this useful.
After applying at least 3 different firmware updates, each time this fault and fix is still needed and works each time…
Set camera to take snapshots at 1 second intervals.
Setup the schedule to always be able to take snapshots, Note there is no green here so only when an alarm goes off the snapshots are set to be taken at 1 second intervals.
This step also needs to be done, you need to supply a destination for the snapshots, I have tried both FTP and NAS boxes ticked and they both work. You can have the nas/ftp disabled on the next TAB page so they don’t get sent, however it only works if you tick a box here.
Thanks a lot for that information!
Funny thing is, even without the green bar (no schedule for “General”), it still writes snapshots every second to the destination for “Scheduled”, if it exists. This is either strange or I do not understand it.
Since I do have configured a NAS, I have set the destination for “Scheduled” to SD card, which I don’t have.
For anyone who finds this. I’ve confirmed this also works for Dahua Cameras (at least the version shown). Note: There’s an odd caveat with this firmware, when selecting the storage destination for Snapshots, it will not let you mix and match between NAS,FTP, or Local. It’s all one or the other. This camera has a SD card, so I set it to a non enabled/existent FTP server.
I found this thread while trying to troubleshoot a newly acquired Amcrest IP4M-4051.
I have the snapshot frequency set to 1s, the General schedule enabled, and I have ticked a box for FTP for the snapshot. But I’m still getting the 500 server error.
2023-01-12 23:13:26.257 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:13:31.204 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:13:31.245 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:13:41.311 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:10.0.0.126 gave a reply with a response code of :500
2023-01-12 23:13:46.278 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:10.0.0.126 gave a reply with a response code of :500
Your middle picture is of the RECORD schedule, you need to setup the SNAPSHOT Schedule which is the next tab over. You will have to experiment to find what works but if you are only getting the 500 error when a snapshot is requested then this will be the reason why.
The log you have posted is showing 3 of what I expect is 4 requests for a snapshot. With DIGEST auth, you will see the request happen twice for each snapshot. You can see the snapshot is requested 5 seconds apart, then the error 500 occurs 5 seconds apart as well.
2023-01-12 23:45:45.408 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:45:45.468 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:45:50.446 [WARN ] [amera.internal.servlet.CameraServlet] - ipcamera.jpg was requested but there was no jpg in ram to send.
2023-01-12 23:45:50.455 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:45:50.486 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://10.0.0.126:80/cgi-bin/snapshot.cgi?channel=1
2023-01-12 23:46:00.499 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:10.0.0.126 gave a reply with a response code of :500
2023-01-12 23:46:05.518 [DEBUG] [ipcamera.internal.MyNettyAuthHandler] - Camera at IP:10.0.0.126 gave a reply with a response code of :500
When you say I will need to experiment to find what works, with which parameters should I experiment?
Yes. I am trying to use the Clickable Camera Widget, with the snapshot as the small view and the MJPEG as the larger, click view. If I can’t do both on this camera, I will return it and try another.
I returned the secondary video to H.264. That makes the snapshot work, but, of course, now the streaming doesn’t work when I click on it. I have an older Foscam that supports both, but as you probably are aware, the newer Foscam’s don’t support MJPEG, so I was trying a different brand.
Thanks, I saw that. But since I’m getting a new camera anyway, I would prefer to get one that provides both without consuming the CPU power needed for this workaround. Are there any cameras you would recommend that provide both streams?
I don’t know a good one. I also have Unifi cameras and they also only provide RTSP.
But why use MJPEG? You can use HLS, right? Converting RTSP to HLS does not cost much CPU. The binding can do it, I think, or for example Restreamer. Restreamer also provides a ready to use web page with video.js to show HLS.
My Amcrest can do both at the same time. Perhaps your camera is hitting 100% CPU usage which you can see with Onvif Device Manager program by looking at the events. Often companies create newer firmwares for 30+ cameras in a range at the same time, and if the CPU is too small for the newer features, you may find you need to disable somethings to get another one working. You may need to try a few different things and also contact Amcrest support to tell them you’re not happy and ask why it occurs. My HIK cameras require features to be disabled if you enable h265 or the 3rd stream for example, at least they do make this clear in manuals and warnings in the UI when you try to turn them on.
Mjpeg is far more compatible. I use HLS for some of mine and it works fine on a pc with a browser, but not on my android phone, whilst it works on my android tablet from memory.
That may help if the browser does not support HLS directly. It would be possible to create a widget that uses video.js to do the same thing, however it needs to be sideloaded as js scripts can not be run due to security reasons.
I didn’t find anything helpful in the Onvif Device Manager, so I decided to try a different approach. After re-reviewing the binding documentation, I decided to try using ffmpeg. I was a little concerned about the potential demand on CPU capacity, but I’m using a Pi 4B, so I thought I would give it a try.
I entered ffmpg in the MJPEG URL box in the UI. It didn’t work immediately. I think I had to disable / enable the thing or perhaps restart the binding, but then it worked. I’m now using the widget and get the snapshot on the small box which opens to the larger streaming box. It looks like the CPU is working a little harder, but is still below 50%.
