I have used this binding with great success on an Intel NUC with plenty of horsepower. Now I am looking to get the binding working with two cameras and a RaspberryPi 3 B. Everything works fine until the Pi begins to generate a GIF after a motion alarm. The system appears to run out of resources while the GIF is being created. As soon as the GIF creation process finishes, the Pi comes back to life. So I wonder - do I have things mis-configured, and FFMPEG is working overtime? Is this normal?
I would be perfectly happy using a snapshot instead of a GIF (I am using Pushover to send an image to my iOS device so I can see what generated the motion alarm), but Pushover is looking for a file location for the snapshot image, and I am not sure where on the file system the snapshots are stored. GIF would be better, but snapshot would be fine as well.
If anyone has any ideas of where to start, I would very much appreciate it.
I would start with a new thread and include some TRACE log output when the gif is being created and please disable all cameras except 1 during this time to make the log easier to follow.
I would also suggest you try using gifPreroll of 1, as this will cause the snapshots to be the source for the GIF and you wont be firiing up FFmpeg and streaming RTSP to do the same job.
Two points also to comment.
Some cameras can only handle X number of streams open at the same time. This needs to be considered if you have both the NUC and the PI trying to talk to the camera as well as maybe a NVR or another server. It can also be an issue if the binding is opening multiple RTSP streams up because you are wanting a GIF, and a number of other features all at the same time. The gifPreroll trick may solve this for you by reducing the number of used streams.
The Pi3 has a weakness in its design for camera uses. The network card is attached via USB2 and if your using a SSD or any other USB devices also on the USB2 bus, it could be hitting a bottleneck. If the binding is requesting multiple RTSP streams they will be adding up and filling this bottleneck and a SSD will make the issue worse. The CPU is also very weak for some of the tasks the binding does, in Linux use the command ‘top’ or ‘htop’ (worth googling how to install htop as it is much nicer) to see in realtime what the CPU is doing and how close you are to hitting 100% usage. The PI4 was a big step up in design from the 3, but even the Pi4 is probably not enough in some use cases if you ‘want it all’.
Thanks Matt. I will do that tomorrow. There is only one camera hooked up to the system at the moment. When you say start a new thread, you mean create a whole separate topic in the community outside of this IpCamera binding thread?
Definitely will try that. I would be perfectly happy with a single frame and definitely do not need to fire up FFmpeg and stream RTSP just to send a single snapshot by Pushover.
Yeah - I remember this was an issue, especially with the DB-1. In this case, the only thing requesting streams is the RasPI. This is a completely separate installation from the NUC installation. So it is not a multiple open stream issue.
Thanks for this info. I did not know that. Good to know the Pi4 might not even be enough. This installation will only have two cameras.
Anyway, I have really been banging my head against the wall with this. I am going to strip thing back to the very basics and see what I can find out. I will post what I come up with.
Thank You for explanations on the logs! Over weekend will go with my own thread then (and trace logs included).
The above url is working from browser (asking for password and giving the image0>
Camera is UniView IPC2122LR3. It is behind firewall, but my laptop with browser is on same network as the rpi - if it works from browser, should be working from rpi as well … though I could test out curl from rpi for sake of experiment.
Thank You and see you in new thread!
Your laptop has a different IP to your Pi, a firewall could allow the laptop to work and block the PI so yes good idea to use curl to test with. I have made a fix to help stop the memory/channels running away like that in the next build, but we need to work out what the root cause is instead of treating the symptom.
So i have to remove the binding file and all the small additional files from addon folder and only install the binding from paperui or with textual config?
Now i removed it in the things-file. But still the recorded video file is only 5 seconds…
In the log i can see, that the email is sent after about 22 seconds from start of the recording. But the recorded file is only 1 mb (formerly it was about 5mb). And the recorded file is only 5 seconds.
I can see in the video time stamp, that i only get about the last 5 seconds of the recorded time. The first about 15 seconds are not there…
Any idea?
Maybe my things file is not compatible with the new binding anymore? I already used the latest test bindings before - with success.
Thanks for reporting, that is a bug and I fixed it and uploaded a new build for you to try. Will have to wait till V3 most likely to fix it as 2.5.9 may be the last release.
I have a (maybe) stupid question: is the „mp4Preroll“ channel still working/part of the binding? I can’t get that to work and there is no mention of that in the documentation.
It is not implemented yet and if/when it is, it will not be done via a channel but via an action. As soon as github has been switched over to have V3 as the main branch I will have to do a cleanup, so thanks for reporting any thing you notice.
020-09-22 18:15:54.390 [WARN ] [me.config.core.internal.ConfigMapper] - Could not set field value for field ‘updateImageWhen’: Can not set java.lang.String field org.openhab.binding.ipcamera.internal.CameraConfig.updateImageWhen to java.math.BigDecimal
java.lang.IllegalArgumentException: Can not set java.lang.String field org.openhab.binding.ipcamera.internal.CameraConfig.updateImageWhen to java.math.BigDecimal
