bundle:list -s | grep camera
351 x Active x 80 x 2.5.9.202009191215 x org.openhab.binding.ipcamera
And here is TRACE log with freshly started openhab and ipcamera.things been just saved ipcamera_20200919.log (826.5 KB)
What else I noticed - mjpeg stream is working (I have a feeling it is not working after frst .things refresh, but on second attempt it is). I mean, using default sitemap file from examples
Text label="Cameras Mjpeg Stream" icon="camera"{Video url="http://192.168.66.116:54321/ipcamera.mjpeg" encoding="mjpeg"}
But ipcamera.jpg request is giving the same ‘was requested but there is no jpg in ram to send.’
Another observation - as I’m clicking around on camera’s sitemap, I see buudaipcamera0.ts and other files been created inside /etc/openhab2/html/cameras folder, but not /etc/openhab2/html/cameras/buuda as specified in ffmpegOutput parameter (though an empty folder ‘buuda’ itself been created there)
UPDATE: this particular I ‘solved’ … by reading the github readme … was not ending it with a slash
Run this to clean out your cache and tmo folders. The behaviour is not normal and the logs don’t seem to match up the way they should which can happen if the cache is an issue. Also power cycle the camera after doing this.
Do you have a password with weird characters in it? Can you try changing the password and only use standard English characters to see if it is a glitch of the binding not handling a different character set. This is the only theory I have that the camera must be refusing the user/pass combination and that causes the binding to try again.
If you enter in ffmpeg instead of the snapshot URL, does everything work fine?
hmm, interesting thought … I don’t have anything weird per-se, but an “!” at end of it … took me a while with curl to figure out I need to quote the password, otherwise was not working. will give it a try in the evening, when get back home and let you know.
p.s.
attaching a little shorter version of log from morning’s session ipcamera_20200919_short.log (104.7 KB)
those tons of “Sending camera: GET:” per second - is it also because camera refusing the access?
It’s only a guess but it is the only thing that makes sense. The way DIGEST auth works is you send a request, a 401 error is produced and the binding instantly resends with the auth. If the camera was refusing and sending 401 errors every time it could go out of control.
Does the camera give the choice of basic authentication, can you switch the camera to use that instead?
Soooo, here are two logs. I also changed password to (regular)letters, numbers and “-” instead of “!” (UniView interface did not let me change to letters&numbers only:( and I can not also change to just basic auth).
I don’t see much change in the behavior with ffmpeg … just a little different error when trying to get the snapshot
2020-09-20 22:23:28.010 [DEBUG] [era.internal.handler.IpCameraHandler] - Binding has no snapshot url. Will use your CPU and FFmpeg to create snapshots from the cameras RTSP.
2020-09-20 22:23:28.030 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -threads 1 -skip_frame nokey -hide_banner -loglevel warning -i rtsp://admin:*****@192.168.60.250/media/video1 -an -vsync vfr -update 1 http://127.0.0.1:54321/snapshot.jpg
2020-09-20 22:24:03.629 [DEBUG] [pcamera.internal.StreamServerHandler] - Stream Server recieved request GET:/snapshots.jpg
2020-09-20 22:24:03.650 [INFO ] [pcamera.internal.StreamServerHandler] - IpCameras file server could not find the requested file. This may happen if ffmpeg is still creating the file.
If I enter completely wrong password in the .things, then I can see: Camera is not reachable on ONVIF port:80 or the port may be wrong.
Not sure if it proves it is not a password issue or does not prove anything:)
Last, but not least, it again made openhab slow and karaf irresponsive … didn’t await till memory exception, just commented out things and restarted openhab and all was back normal.
OK I have found some issues in your logs when you were trying to create the snapshots with ffmpeg…
You were asking for snapshots.jpg when you need to ask for /snapshots.mjpeg or ipcamera.jpg
You appear to have deleted the FFmpeg Install Location, it should be /usr/bin/ffmpeg under Linux in most cases… This log looks wrong hence why I suspect this to be the issue…
Starting ffmpeg with this command now:-rtsp_transport tcp -threads 1
As for the original issue, I think it is best I create a custom build for you that has more logging in it to diagnose the issue. I put the wrong password on my camera that has digest and I could not reproduce this but if the camera did not follow the digest standard 100% I can see this being the result. Actually it is pretty simple to check this with curl…
Can you post the output of what happens when you use the wrong password with this?
Another thought I had - could some timeouts cause it? I am seeing 1-2seconds (on rare cases even 5) to download the snapshot with wget - maybe it’s taking too long?
root cause for longer than expected responses (I think) is point to point wifi to camera location and few obstacles in line of sight. Plan is to fix it on long run, but for time beeing have to live w it:(
sooo, here is trace log with these in .things
ffmpegLocation="/usr/bin/ffmpeg",
snapshotUrl=“ffmpeg”, ipcamera_20200921_ffmpeg.log (881.4 KB)
and /snapshots.mjpeg and /ipcamera.jpg is actually showing something (I got a feeling mjpeg is a single image, but it’s already more than nothing :))
apologies for being very verbal/text-rich tonight:)
upgraded to latest binding.
cleared cache, restarted.
Also was poking around camera config menus and found authentication type … changed rtsp to basic and http to none (was either digest or none) and /ipcamera.jpg and /snapshots.mjpeg are working!!!
wow … trace log attached ipcamera_200921_basic.log (196.5 KB)
I suspect your camera may only recognise headers that start with a capital. Netty uses lowercase by default which is correct but it is common for devices to not recognise lowercase. I think it is worth making a build with this change in it for you to try but it may take a day for me to get the time to do it.
Good news that basic is working as that gets you working in the meantime.
I am happy to try it when u have it ready. No rush
I guess, it is http=none which made it working (no ‘basic’ option on http).
somehow not been able to get the gif(s) yet, but will re-read github and examples to see if I’m not missing smtg.
Thank You so much for your time and support!
