Ipcamera streams not automatically updating / cached

Sonntagskiter · November 20, 2022, 1:27pm

Hi,

i use ipCamera binding for my Unifi Protect Doorbell G4. Mjpeg und HLS Streams work, but are not updating if i go to my camera page in openhab again.

so i have a constantly open and running openhab on my tablets at home and when going to the camera page where i include the mjpg / hls streams, it loads. e.g. a 4h old stream when i watched last time. page reloads makes reload the videos and show the live streams. it seems its cached or something like that.

any idea how i can fix this?

also i notice that after some time my binding seems to stop working. disabling and enabling the Thing fixes this. but this happens regularly. in the same time i can open the streams from the native apps of the cameras, so they are online.

happy to hear you thoughts.
mathias

matt1 · November 21, 2022, 12:02am

The binding does not cache any video streams, however it does hold the last snapshot in ram to help start mjpeg streams created from snapshots faster. If you’re seeing the clock tick over or the picture is not fully static then it will be your camera giving an old stream.

The binding can be operating in either a proxy mode where it passes the cameras stream on, or it can also create the mjpeg streams from snapshots, knowing which URL you’re trying to open and where the camera is sourcing it from will be helpful. The logs will show this as especially when the camera is ONVIF, the camera can auto find urls to use and does not need them given in the setup.

In the bindings documentation at the very start it tells you how to get debug and trace level logs for asking help with. That will be helpful to see what is happening.

Sonntagskiter · November 21, 2022, 8:44am

thanks for the insights. i just figured out that i have very low wifi singal stregth (around -75dbm) so i guess i have packet losses etc. i first try to fix this and retest. if the problem persists i will try to get trace logs etc. thanks.

also thanks for last snapshot info. the time is static so its the last shot i see and somehow the binding doesnt get the new mjpeg stream (via proxy)…

Sonntagskiter · November 22, 2022, 7:46am

hi @matt1

first of all thanks you help all the time with this great binding.
I was able to fix some things. it was not because of bad wifi, but my mjpeg stream was constantly running on 2 tablets and i guess used all ressources and basically openhab crashed but didnt show it immediately.

however, i lowered the resolution of the rtsp stream and also changed my code so the stream is only showed on demand for my doorbell. this works and is not showing old snapshots any more.

so i am fine with mjpeg.

on another page i still have a problem that i was not able to solve.
its a openhab main ui page whre i have 3 HLS Streams included. they are not running all the time. so no problem with ressources etc. but i can always reproduce the following:

1 of the streams is always “old” and shows an ealrlier date/time. it runs some second and then stops loading. the other 2 streams load the live stream. this was random with the 3 videos. than i changed to “manual” start of the videos and i can reproduce the following: the first video i start is old, the next 2 ones get the fresh stream.

here the logs

openhab> log:tail camera.internal
08:30:35.487 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.m3u8, received from 192.168.0.110
08:30:35.489 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-hide_banner -loglevel warning                            -rtsp_transport tcp -i rtsps://192.168.0.240:7441/i9ol0KM1lD8Oro2P?enableSrtp -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcode                           c copy -hls_flags delete_segments -hls_time 2 -hls_list_size 4 /var/lib/openhab/ipcamera/f0dc14d199/ipcamera.m3u8
08:30:35.576 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.m3u8, received from 192.168.0.110
08:30:35.576 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-hide_banner -loglevel warning                            -rtsp_transport tcp -i rtsps://192.168.0.240:7441/ID7RV6HdEZWz6UGS?enableSrtp -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcode                           c copy -hls_flags delete_segments -hls_time 2 -hls_list_size 4 /var/lib/openhab/ipcamera/165b42c7f9/ipcamera.m3u8
08:30:35.586 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.m3u8, received from 192.168.0.110
08:30:35.587 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-hide_banner -loglevel warning                            -rtsp_transport tcp -i rtsps://192.168.0.240:7441/AqXJBDLE5RGyxMOC?enableSrtp -strict -2 -f lavfi -i aevalsrc=0 -acodec aac -vcode                           c copy -hls_flags delete_segments -hls_time 2 -hls_list_size 4 /var/lib/openhab/ipcamera/aa63b2a7ff/ipcamera.m3u8
08:30:37.830 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [rtsp @ 0x56315b8d9a40] Thread message queue blocking; consider rais                           ing the thread_queue_size option (current value: 8)
08:30:37.973 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [rtsp @ 0x55768dc53a40] Thread message queue blocking; consider rais                           ing the thread_queue_size option (current value: 8)
08:30:38.088 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [rtsp @ 0x557235e52a40] Thread message queue blocking; consider rais                           ing the thread_queue_size option (current value: 8)
08:30:41.007 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.m3u8, received from 192.168.0.110
08:30:41.374 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera19.ts, received from 192.168.0.110
08:30:42.495 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera20.ts, received from 192.168.0.110
08:30:42.916 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera21.ts, received from 192.168.0.110
08:30:43.275 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera22.ts, received from 192.168.0.110
08:30:45.013 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.m3u8, received from 192.168.0.110

Can you help me with this? the only problem i see is thread_queue_size option which i guess has to do again wieth resources - but there should be enough free resources as before nothing was running from ipcamera.

what i also noticed is that log entries already apear when the page loads, and not only when i hit play. so i guess auto-play or manual play is not really a difference. its just easier to reproduce the problem for me.

regarding my setup: I use a unifi nvr. so all rtsp streams come from 1 server and not different cams/ips. dont know if this may be problematic for the binding? (so ip is always same, but stream urls are different of course).

for the hls streams i also lowered the resolution of the incoming rtsp stream

hope you can help with this. however my major problem was with mjpeg which i could solce.

or what logs /data etc. could i look into more? regarding the thread_queue_size option i didnt find anything useful except ressource issues but as said, before starting the video streams - no other video is running and other stuff in my server consume like nothing … server is also a real virtual server with enough resources an not raspberry.

also i was wondering why the logs mention the ip 192.168.0.110 as i dont use it. my nvr is 192.168.0.240 and cameras also have other ips. so what is this ip in the log?

mathias

matt1 · November 22, 2022, 11:40am

That IP should be the machine that your asking to watch the HLS stream from. It should be one of your tablets if that is what your using to open the stream with. Your able to use the whitelist if you want to limit only certain IP’s from getting access to the streams.

Yes I can reproduce this so I do not need logs from your sysrem. It takes time for FFmpeg to start creating the HLS stream and some times the ipcamera.m3u8 file is sent back old if it has not fully started creating the stream. I may be able to improve this as I was using delays in replying to the requesting browser to give it time to open the camera and produce the stream, there are limitations on what can be done as a web browser expects a reply within a certain time frame…

As for a work around, you can create the HLS stream non stop so it is always being created, or you can just press refresh on the browser to get the updated stream after a few seconds has passed to give it some time to fully create the stream.

Sonntagskiter · November 22, 2022, 11:44am

thanks, all clear!

Sonntagskiter · December 6, 2022, 10:55am

@matt1

Hi, i now observed the last day and tried to reproduce the remaining problems. now i think i can explain it clearly. I hope you can help me with it or point to the correct settings.

Problem: I have 2 tablets running with displays continuously ON. so they stay on 1 openhab page which is only refreshed when i refresh manually. on this openhab page i open a popup when an event occurs. if the popup opens i start the mjpeg stream (so it is not running all the time on this page, but only when I open the popup).

This basically works after setup but i observed the following:

if the camera loses power / restarts. it is not working any more. page reload in openhab is also not enough. i have to disable and then enable the ip camera THING. then it is working again.
when everything is running for a longer period of time (lets say some hours, i dont have a specific number here). it is also not working any more. also reloading the openhab page is not enough. i have to again disable and enable the ipcamera thing.

After disabling and enabling the thing, i have also to reload the openhab page on the tablet so it is working again.

in the logs i see only the following when it is a scenario of not working:

2022-12-06 11:14:42.102 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.120
2022-12-06 11:14:42.310 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.106

so 2 tablets are requesting the stream but nothing happens.

if i restart everything, the working log entries look like this

2022-12-06 11:31:15.381 [DEBUG] [amera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
2022-12-06 11:31:15.381 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -hide_banner -loglevel warning -i rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp -q:v 5 -r 2 -vf scale=640:-2 -update 1 http://127.0.0.1:8080/ipcamera/aa63b2a7ff/ipcamera.jpg
2022-12-06 11:31:15.451 [DEBUG] [amera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.120
2022-12-06 11:31:18.295 [DEBUG] [hab.binding.ipcamera.internal.Ffmpeg] - [swscaler @ 0x55febf46d880] deprecated pixel format used, make sure you did set range correctly
2022-12-06 11:31:25.040 [DEBUG] [amera.internal.servlet.CameraServlet] - Now there are 1 ipcamera.mjpeg streams open.

etc...

do you have any idea what i can do to improve this? as i have my doorbellcam connected to the tablet i need this scenarios working.

one time you mentioned i can have the mjpeg stream open all the time so it loads quicker - altough i dont think thats a solution for the problem above - i am also interested in how i can realize this as i would like to test it.

thanks for your help so much!!

matt1 · December 6, 2022, 10:08pm

EDIT: Sorry must be lack of sleep thought this was in the other thread. I’ll take a look at all your posts and see what I notice later this evening.

matt1 · December 7, 2022, 7:59am

Ok so you are using FFmpeg to create the mjpeg stream from a RTSP source. Trace output would be more helpful to help work this out if you pause your other cameras so only 1 is active when the logs are getting created…

I suspect this issue is similar to what I fixed for the alarms and snapshots here:
[ipcamera] FFmpeg based alarms will now auto restart if stopped by Skinah · Pull Request #13446 · openhab/openhab-addons (github.com)

The issue was that FFmpeg was crashing/freezing and never returns and it was able to be reproduced when you run ffmpeg from the command line and reboot the camera. The result was it never comes back to the command line in your terminal.

The fix was applied to snapshot generating and the ffmpeg based alarm streams, but it was not applied to the mjpeg conversion so most likely I can create a new build for you to try that has the same fix in it.

First can you confirm that you never see the result of this line in your logs?

logger.debug("Stopping ffmpeg {} now when keepalive is:{}", format, keepAlive);

Do you see it when you close both your tablets from watching the stream?
Do you see it when you have the tablets open and you reboot the camera?

Sonntagskiter · December 7, 2022, 10:46am

@matt1 thanks for the again quick reply. i was just about to create a new thread i am really trying to go through the forum first, create logs etc. and make posts as specific as possible but i can really understand you guys making cool things for free and people asking stupid questions. so I can just assure i give my best but may also produce something useless

unfortunately i will only have in some days the time to make the tests you suggested but i will check this! as i already watched the logs for a long time i can pretty surely say i never saw this line in the log. but i will recheck and let you know.

would be really happy to test a new build and i think your conclusion makes sense and it really sounds like the other problem…

i will post as soon as i checked. thanks!

matt1 · December 7, 2022, 11:34am

I tried to reproduce this by doing the following:

Setup and Instar camera and setup the mjpeg to over ride and use ffmpeg to create the stream.
Open the ipcamera.mjpeg stream in a tab.
Pull network cable, wait till camera was offline and then plug it back in.
Watch the stream in the tab and it came back and worked with no action needed.
Repeated this by pulling power out of the camera, same result it worked perfectly.
Repeated again by telling camera to reboot, once again it worked and ffmpeg restarted and the stream kept working without needing an action to be taken.

So I then used the same camera and setup as Onvif thing type, and once again it worked without issues.

It is possible that this error was a bug in ffmpeg and it is now solved in the version I am using which is this one. I can not find the version that I was using when the terminal would lock up when a camera was rebooted in the middle of accessing a rtsp stream. Check you have installed all updates as the binding does not check if the thread has locked up so I can try and create this build that does in a day or twos time.

ffmpeg version 4.1.10-0+deb10u1 Copyright (c) 2000-2022 the FFmpeg developers

4.1.10 was released on 2022-10-22

This release date is after the PR I made, so it would seem they made a newer release since my testing showed it locked up.

Sonntagskiter · December 7, 2022, 12:03pm

hi @matt1

wow! thanks for your effort. this would also make sense. so first i will try to update the ffmpeg version which i am sure is older than 2022-10-22. hope this works.

if not, will also make the tests you mentioned above and try to gather more data…

i will also need some days to do this an will let you know about the result!

mathias

Sonntagskiter · December 9, 2022, 9:44am

hi @matt1

unfortunately its still not working, but i gathered some new data:

i also tested if my normal hls streams are working when i restart the camera and the answer is YES. so pretty sure the problem is with ffmpeg as you already thought.
my ffmpeg version is:

ffmpeg version 4.3.5-0+deb11u1 Copyright (c) 2000-2022 the FFmpeg developers

and it seems its the newest

i gathered some logs what happens when an mjpeg stream is running and i restart the camera

10:16:34.553 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.231
10:16:34.554 [DEBUG] [camera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
10:16:34.555 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -hide_banner -loglevel warning -i rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp -q:v 5 -r 2 -vf scale=640:-2 -update 1 http://127.0.0.1:8080/ipcamera/aa63b2a7ff/ipcamera.jpg
10:16:36.253 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [swscaler @ 0x55a54912c400] deprecated pixel format used, make sure you did set range correctly
10:17:14.830 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x5590255b0b40] Error in the pull function.
10:17:14.833 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x55a548bccac0] Error in the pull function.
10:17:14.835 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x55a548bccac0] The specified session has been invalidated for some reason.
10:17:14.842 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x5590255b0b40] The specified session has been invalidated for some reason.
10:17:14.847 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] -     Last message repeated 4 times
10:17:14.853 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x5590255b0b40] The specified session has been invalidated for some reason.
10:17:14.857 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x55a548bccac0] The specified session has been invalidated for some reason.
10:17:18.578 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -threads 1 -skip_frame nokey -hide_banner -loglevel warning -i rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp -an -vsync vfr -q:v 2 -update 1 http://127.0.0.1:8080/ipcamera/aa63b2a7ff/snapshot.jpg
10:17:18.713 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x55b07300fb40] Error in the pull function.
10:17:18.714 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp: Invalid data found when processing input
10:17:26.579 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -threads 1 -skip_frame nokey -hide_banner -loglevel warning -i rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp -an -vsync vfr -q:v 2 -update 1 http://127.0.0.1:8080/ipcamera/aa63b2a7ff/snapshot.jpg
10:17:26.727 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [tls @ 0x55d7ccaf7b40] Error in the pull function.
10:17:26.728 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp: Invalid data found when processing input

-> and this goes one until the camera is offline. when it comes online again, the logs stop, so no "starting...." is generated any more. it just stops showing logs

if I then reload my open hab mjpeg url i just get the following lines, as already shown in posts above:

10:23:06.598 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.231
10:23:33.802 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.231

then I checked if i see your mentioned logging line in normal running mode and i see a Stopping ffmpeg MJPEG now when keepalive is:8 every time when the stream stops. did you look for this? what does this mean?

openhab> log:tail camera.internal
10:31:34.486 [DEBUG] [camera.internal.servlet.CameraServlet] - Now there are 0 ipcamera.mjpeg streams open.
10:31:34.492 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Stopping ffmpeg MJPEG now when keepalive is:8
10:31:34.493 [DEBUG] [camera.internal.servlet.CameraServlet] - All ipcamera.mjpeg streams have stopped.
10:31:34.528 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.231
10:31:34.529 [DEBUG] [camera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
10:31:34.530 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -hide_banner -loglevel warning -i rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp -q:v 5 -r 2 -vf scale=640:-2 -update 1 http://127.0.0.1:8080/ipcamera/aa63b2a7ff/ipcamera.jpg
10:31:37.753 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [swscaler @ 0x560534c20440] deprecated pixel format used, make sure you did set range correctly
10:32:52.601 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.231
10:32:52.707 [DEBUG] [camera.internal.servlet.CameraServlet] - Now there are 1 ipcamera.mjpeg streams open.
10:33:13.757 [DEBUG] [camera.internal.servlet.CameraServlet] - Now there are 0 ipcamera.mjpeg streams open.
10:33:13.758 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Stopping ffmpeg MJPEG now when keepalive is:8
10:33:13.758 [DEBUG] [camera.internal.servlet.CameraServlet] - All ipcamera.mjpeg streams have stopped.
10:33:29.310 [DEBUG] [camera.internal.servlet.CameraServlet] - GET:/ipcamera.mjpeg, received from 192.168.0.231
10:33:29.310 [DEBUG] [camera.internal.servlet.CameraServlet] - First stream requested, opening up stream from camera
10:33:29.311 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Starting ffmpeg with this command now:-rtsp_transport tcp -hide_banner -loglevel warning -i rtsps://192.168.0.240:7441/jXjd0HKFPfygQXQP?enableSrtp -q:v 5 -r 2 -vf scale=640:-2 -update 1 http://127.0.0.1:8080/ipcamera/aa63b2a7ff/ipcamera.jpg
10:33:32.851 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - [swscaler @ 0x55b1149993c0] deprecated pixel format used, make sure you did set range correctly
10:33:41.986 [DEBUG] [camera.internal.servlet.CameraServlet] - Now there are 0 ipcamera.mjpeg streams open.
10:33:41.987 [DEBUG] [nhab.binding.ipcamera.internal.Ffmpeg] - Stopping ffmpeg MJPEG now when keepalive is:8
10:33:41.988 [DEBUG] [camera.internal.servlet.CameraServlet] - All ipcamera.mjpeg streams have stopped.

above is how my debug log looks like when mjpeg is working and is start/stop the stream.

do you have any idea where i could look next? or would jo provide a new .jar to test if you see a problem here? or should i do some logging with ffmpeg?

(in the beginning i mentioned 2 problems, because i also noticed this behaviour not only after restart but also after a few days running - but i guess both are the same so i would first concentrate on this reproducable one.)

by the way: these are my mjpeg options in the binding, but i think i didnt change this from your standard. can i maybe tune something here?

-q:v 5 -r 2 -vf scale=640:-2 -update 1

And also by the way: my ipcamera binding version is 3.3.0 - this is which is installed directly from openhab.

matt1 · December 10, 2022, 6:26am

Does this mean you’re using openHAB 3.3 Stable?

Please try the binding found here:
Index of /openhab/IpCameraBinding/ (pcmus.com)
Unzip it to your addons folder, uninstall the merged binding and install the Telstick binding to provide the missing dependencies.

This binding will check if the FFmpeg thread is crashed and will auto restart it. When this occurs the logs will have this line…

MJPEG was not being produced by FFmpeg when it should have been, restarting FFmpeg now.

Since I can not reproduce the issue, I can not test if this fixes the issue.

Great thanks for reporting it restarts, the only other 2 that need testing are GIF and MP4 recording to see what happens if the camera restarts in the middle of a recording. The rest should auto fix when the camera reboots if this works for mjpeg.

This just means that the FFmpeg thread that creates the mjpeg stream from RTSP is killed/stopped. When it is missing it means the thread that was started is probably frozen/crashed and the binding thinks it is opperating correctly and will not know it is not functioning.

The new binding will move all ffmpeg output to TRACE log level and will create more lines of text which the binding uses to know if the thread has crashed. No output from FFmpeg and the crash detection will know and kill the thread then auto restart it if it is still needed. At least that is what should happen since I can not test it here.

Sonntagskiter · December 10, 2022, 8:52am

@matt1

wow, thanks it works!

and yes i am using 3.3 stable. sorry i didnt think about the fact that the bindings are merged into the openhab version, thats why i didnt find some binding version

regarding tellstick binding: why do i need this? is this also a binding of yours and has some code needed?

i will now observe the behaviour the next days to see if it also somehow goes wrong when power is not away, but i am pretty sure your ffmpeg fix corrected this.

so can i just use this binding till openhab 3.4. is released and then this will be part of standard? is it a problem that i have this trace logging on in the binding?

thanks again so much. if you were a support compony you would get 5 star rating from me on google with your response time

matt1 · December 10, 2022, 10:16am

Great thanks for confirming it is a fix for your fault. Even if newer versions of FFmpeg do not freeze, its still a good idea to merge this in case another cause does the same thing.

Yes that is my thoughts, let me know if the long running issue is solved, but it should be as it now checks that FFmpeg is actually working and producing output to the terminal to confirm all is well.

Not my binding, but yes it shares the same libraries/ dependencies and this saves me from supplying multiple jar files and saves me time. When these changes get merged you will not need to install that binding and you can then delete the jar file from your addons folder.

I do not have control over if it will get merged before 3.4 Stable the time frame is very tight to get it in before then, however you having confirmed it is a fix for a bug is going to help it get approved quicker.

Put the logging back to INFO level is what I would recommend as it lowers the load on your system and stops the logs filling up as quickly. Only if your looking to find clues as to why an issue is occurring should you change it away from INFO.

matt1 · December 10, 2022, 10:38am

I’m just reviewing the code changes and it seems like this would only be an issue if the camera was not detected as OFFLINE, can you tell me does your camera go OFFLINE when it does a reboot? or does openHAB not detect it as OFFLINE when the camera is rebooting?

This may only be an issue if the camera does a soft reboot and does not shut down its http server.

This may be the reason why I can not reproduce it and you can. My camera goes OFFLINE so other code takes care of what is needed, but in your case if my hunch is correct yours has the issue.

Sonntagskiter · December 10, 2022, 11:08am

Hi @matt1

Your are correct my camera thing is not going offline in case of power outage or reset because i use kind ob a hub which stays online. (Unifi protect camera)

So sounds like good improvement for the binding;) even though edge case… thanks again for help. I will also change logs to info mode.

Mathias

matt1 · December 11, 2022, 2:45am

The fix has been merged and will be in the next milestone due out any day now.

jwiseman · December 11, 2022, 8:59pm

Can you provide the exact file name so I can manually pull it since jFrog doesn’t like browser downloads anymore

Here’s the syntax I’m using on the last snapshot.

curl --output org.openhab.binding.ipcamera-3.4.0-SNAPSHOT.jar https://openhab.jfrog.io/artifactory/libs-pullrequest-local/org/openhab/addons/bundles/org.openhab.binding.ipcamera/3.4.0-SNAPSHOT/org.openhab.binding.ipcamera-3.4.0-SNAPSHOT.jar

Best, Jay