See braking changes in a previous post
SNAPSHOT_URL_OVERIDE Is now
See braking changes in a previous post
I did read that, but missed this difference.
Still it’s odd that the old version with the single ‘R’ still works if you supply the user/pswd to the URL.
That will be the onvif finding the URL for you as you do not need to supply the URL if onvif works on your camera. My guess is a reboot and onvif made it work.
Hello @matt1 I just wanted to say thank you for this binding. I played a few days with it and my foscam camera and it works well. You work is very much appreciated
I got it working but it in chrome there is a pop up for user and password which comes as soon as I refresh the page. How can I get rid of this.
This is the entry in my Sitemap:
Video url=“http://XXX:XXX@192.168.188.77/cgi-bin/mjpg/video.cgi?subtype=1” encoding=“mjpeg”
That sitemap you posted shows you are not using the binding but are trying to get the camera to send directly. For cameras like foscam that place the user and pass into the URL query string it works, but for other cameras it will not work. The issue is most if not all browsers are discontinuing the embedded user and pass that you are trying to do. This is because of security concerns and the standards specify it should not be done hence why browsers are removing support for something that used to work.
See the readme file for this binding as it guides you through what to do. You will need to remove the xxx:xxx@ from your URL with the binding.
I have set the ONVIF encoder profile to 1, which should be the DAHUA substream profile.
CPU is very very high though, with a Quad core Xeon. How can I verify its definitely using the substream profile? Cheers
Thing ipcamera:DAHUA:FrontYard [IPADDRESS="192.168.0.249", PASSWORD="camuser2018", USERNAME="camuser", POLL_CAMERA_MS=2000, SERVER_PORT=54321, IP_WHITELIST="(192.168.0.10)(192.168.0.3)", IMAGE_UPDATE_EVENTS=0, ONVIF_MEDIA_PROFILE=1]
Further, lots of these errors:
[io.netty.channel.nio.NioEventLoop ] - Selector.select() returned prematurely 512 times in a row; rebuilding Selector io.netty.channel.nio.SelectedSelectionKeySetSelector@52f424a3
It will be as this is the line that is hardcoded into the binding for Dahua. It would not work if it was not using a substream that is setup for mjpeg.
videoUri = "/cgi-bin/mjpg/video.cgi?channel=" + nvrChannel + "&subtype=" + selectedMediaProfile;
Ok that probably explains the high CPU usage, there is an open issue for a similar report at the Netty github and they are not able to reproduce it, but the error is the same as yours and reports of high CPU. I can not reproduce it as it has been working fine here for weeks but I have not tested with multiple cameras at the same time. You will need to strip it back to a single camera and try changing different things until you find the cause. There is a newer version of Netty that I can upgrade to next time I am building a jar to see if it fixes. Also try cleaning the cache and tmp folders and turning your server off and back on again.
Ok, then im using the right substream and its a netty issue thats causing the CPU.
Ill clear the folders and restart. Stopping the binding fixes the issue with CPU
Cool, ill look forward to your next binding update
sorry another question. Does the frame rate in the ‘thing’ need to match the actual camera? I have the cameras defined at 25FPS, but I’m happy to have them set to 10 in the thing configuration.
Or, should both match?
New build 2019-04-07 has these changes:
- Doorbird API has now begun to be added, needs testing as probably got some stuff wrong.
- Dahua/Amcrest changes for NVR pictures.
- New Netty 4.1.34 is now used. I have noticed my CPU usage has dropped since making this change.
Have no idea what you are asking, there is no video frame rate options in the thing definition.
Either do I! Ignore me.
It would be great if you could test your Doorbird with this new version of the binding as I had to guess at a number of things with the Alarm stream. If it does not work I just need some feedback on what the camera sends to this url in any browser:
I dont use Motion on the doorbird, I’ve got it turned off. I was able to pull a video stream from the doorbird just fine though. What did you want me to do, thrown that URL into a browser?
If you could and just tell me what appears on the screen when the doorbell is pushed down and what occurs when it is not pushed down. Same for motion if you could turn it on temporarily for testing. The binding may already react to doorbell and motion events. The binding wont mess with any of your settings as the alarm stream is handled differently in the binding to how I have seen people using the REST api.
OK, ill do my best
I’ve been not using your binding for a while since it somehow was breaking my openhab, twice.
It has to be connected somehow with out of heap space that appears always when I use this binding nevertheless I increased memory following some guidance in this community. I have had therefore to stop using the binding and use direct commands that Foscam FI9826W/P cameras supports. Don’t take me wrong, I very, very, very appreciate your work as this is an amazing and very important binding, however I haven’t time to deal with the issues I suffered.
Now I’m back again since I’ve installed 6th camera which is Hikvision DS-2CD2143G0-IS that unfortunately uses basic login credentials that are not supported by web browsers anymore.
So I hoped your binding can help with that and I will try this time to resolve issues with heap space and others.
Now I have a problem. I configured everything as in your description and I’ve got video stream from the binding. However the video stream drops connection pretty often i.e. 15m, 0,5h, 1h etc. I solved the same problem with my foscam cameras by refreshing stream every 5m. However it doesn’t work with the stream from this binding. After refresh the camera does not reconnect. Only restarting webpage or browser helps.
I use tablets in my house with installed latest habpanelviewer on them and streams are put into Image widgets with embedded refresh feature. Also I use carousel widget with refresh. The issue is the same regardless of solution used.
Can you help me understand why this happens and how can I resolve it?
If you used an Intel QuickSYNC GPU enabled system for OH2 (Say an Intel NUC with Intel Iris GFX), would your binding take advantage of the hardware decoding to reduce CPU usage? Even with 9 cameras at 350x230, 10FPS Substream MJPEG the CPU usage is high.
If you ever used the Android app, see this thread. I suspect the leak you refer to having issues with in the past is in the displaying of images and is not part of my binding but the core of Openhab or the a app and the way it handles the image data…
I run only a single camera currently for weeks on end with no issues, however I don’t run the camera on a tablet non stop like you appear to be doing. I did do some testing where I ran the new stream non stop for over two hours watching the heap to see if it grew whilst monitoring memory/threads and objects, did not find any issues. The stream ran without stopping for over 2 hours when I got sick of watching and stopped it.
In regards to your stream stopping, does this happen only on Foscams or is it happening on the Hikvision as well? If on both it may be a network issue and worth fault finding if it may be a bad cable or something that is simple to replace.
The binding copies the stream and will not stop the stream from the camera to the binding if you are watching it on multiple tablets, this could be the reason why the same band aid fix of doing a refresh does not work. It only stops the stream if you stop or refresh when only 1 tablet is showing the stream. Having the camera going to two tablets would mean the original connection to the camera never stops and your work around fix would not work if the camera to the binding develops an issue.
I’ll run some tests and look at what logging is in the binding to see if a trace would turn up more info.
The binding does not give me high CPU so if you have that occurring it is an issue on your system which no one else has reported and I have not seen it happen here. So I suspect you would not see any difference by changing to a QuickSYNC system as currently the binding does not do any transcoding. In the future the binding may do transcoding and when that is the case QuickSYNC will help for sure.
OK, something doesnt add up.
Without the binding, its fine, with it the CPU runs high when I display the cameras. The binding may not given you high CPU because you’re only running 1 camera right?