Vettester
Getting comfortable
- Feb 5, 2017
- 799
- 814
Yet Another Free Extension for Blue Iris Adding AI Object Dectection/Reduction in False Alarms/Enhanced Notification of Activity/On Guard
- Thread starter Ken98045
- Start date
Version 2.0.1 has been released on Github as an official (not pre-release) version. This version automatically fixes a Version 2.0.0 issue where the database/SQL connection string for older versions was not compatible with the newer Microsoft software used by version 2.0.x.
There is also a new release 1.8.2.3 that fixes a reported issue where the application would crash if AI settings data was not as expected or corrupt. This will probably be the last release of 1.8.x since the majority of the effort will be directed to Version 2.0. However, if there are major problems with the 2.0.x release that are causing people to be unable to run it, and there are some 1.8.x bugs that are reasonably straightforward, there may be some 1.8.x bug fixes.
Note that Version 2.0.x adds the ability to be notified via email or MQTT if all your AI connections die.
Note that the 2.0.x version optionally supports using an XML for storing the application settings in addition to the previous Windows Registry mode. If desired you can move the camera settings to XML by starting the application in the standard Registry (non-XML mode), changing the settings mode to XML, and re-saving the camera settings. While this can be done for most other application settings it cannot be done for the AI location settings. Those would need to be re-entered manually. Using only XML for the application settings is expected to be the long term direction since it is more compatible with other platforms (Linux, Android). Linux support for the UI is probably quite a while off, but I'm working in that direction. Also, the XML settings file makes it easier to move settings between Windows computers.
There is also a new release 1.8.2.3 that fixes a reported issue where the application would crash if AI settings data was not as expected or corrupt. This will probably be the last release of 1.8.x since the majority of the effort will be directed to Version 2.0. However, if there are major problems with the 2.0.x release that are causing people to be unable to run it, and there are some 1.8.x bugs that are reasonably straightforward, there may be some 1.8.x bug fixes.
Note that Version 2.0.x adds the ability to be notified via email or MQTT if all your AI connections die.
Note that the 2.0.x version optionally supports using an XML for storing the application settings in addition to the previous Windows Registry mode. If desired you can move the camera settings to XML by starting the application in the standard Registry (non-XML mode), changing the settings mode to XML, and re-saving the camera settings. While this can be done for most other application settings it cannot be done for the AI location settings. Those would need to be re-entered manually. Using only XML for the application settings is expected to be the long term direction since it is more compatible with other platforms (Linux, Android). Linux support for the UI is probably quite a while off, but I'm working in that direction. Also, the XML settings file makes it easier to move settings between Windows computers.
Vettester
Getting comfortable
- Feb 5, 2017
- 799
- 814
Awesome, thanks Ken! This release resolved the error messages I was seeing in the alpha version.
I have released version 2.0.3. The primary change in this release is that there are user configurable limits on the size of picture attachments on a per email recipient basis.
I've personally had several issues running into the Comcast 25MB attachment size limit and my MMS limit of 3.5MB. If you run into the limits you set, that fact will be logged and the offending pictures won't be added.
I've personally had several issues running into the Comcast 25MB attachment size limit and my MMS limit of 3.5MB. If you run into the limits you set, that fact will be logged and the offending pictures won't be added.
At this point I'm assuming that no news is good news. So, if anyone has any new features they'd like included in the next release let me know.
My tentative plans include supporting cameras that use ONVIF for pan/tilt/zoom . ONVIF is the closest thing to a standard available for network cameras these days. This should allow more people to bypass Blue Iris and just use their camera's built in motion detection and On Guard.
I am going to make a pass at supporting direction of travel (arriving/departing) for areas.
My tentative plans include supporting cameras that use ONVIF for pan/tilt/zoom . ONVIF is the closest thing to a standard available for network cameras these days. This should allow more people to bypass Blue Iris and just use their camera's built in motion detection and On Guard.
I am going to make a pass at supporting direction of travel (arriving/departing) for areas.
Another feature I'm considering:
Say you have a security camera that can take pictures with a resolution ranging from 640x480 to 2560x1920. If you have Blue Iris taking pictures at 2560x1920 these pictures (1) take up a lot of disk space (2) take up Blue Iris processing power (on my machine Blue Iris takes 25 to 40% CPU with 4 cameras) (3) higher resolution pictures take considerable time processing with DeepStack.
What I propose is that (1) Blue Iris (or your camera directly) takes "standard" pictures at 640x480 (2) On Guard processes the "motion" picture and sees something potentially interesting - people, car.... (3) On Guard takes control and starts outputting pictures at full resolution at a (presumably higher) frame rate. (4) interesting motion stops and On Guard stops taking high res pictures.
The advantages are (1) lower disk space (2) lower Blue Iris CPU usage (3) faster DeepStack processing time (4) better resolution for pictures you might care about (5) interesting pictures are taken at a frame rate different from non-interesting ones. The potential disadvantages (1) I don't know if DeepStack will be as reliable in noticing motion in lower resolution pictures - TBD (2) The difference between motion and non motion pictures may be a little jarring as you scroll through pictures in your working set (3) You may miss detail you want in pictures On Guard (DeepStack) doesn't determine to be interesting.
Let me know what you think!
Say you have a security camera that can take pictures with a resolution ranging from 640x480 to 2560x1920. If you have Blue Iris taking pictures at 2560x1920 these pictures (1) take up a lot of disk space (2) take up Blue Iris processing power (on my machine Blue Iris takes 25 to 40% CPU with 4 cameras) (3) higher resolution pictures take considerable time processing with DeepStack.
What I propose is that (1) Blue Iris (or your camera directly) takes "standard" pictures at 640x480 (2) On Guard processes the "motion" picture and sees something potentially interesting - people, car.... (3) On Guard takes control and starts outputting pictures at full resolution at a (presumably higher) frame rate. (4) interesting motion stops and On Guard stops taking high res pictures.
The advantages are (1) lower disk space (2) lower Blue Iris CPU usage (3) faster DeepStack processing time (4) better resolution for pictures you might care about (5) interesting pictures are taken at a frame rate different from non-interesting ones. The potential disadvantages (1) I don't know if DeepStack will be as reliable in noticing motion in lower resolution pictures - TBD (2) The difference between motion and non motion pictures may be a little jarring as you scroll through pictures in your working set (3) You may miss detail you want in pictures On Guard (DeepStack) doesn't determine to be interesting.
Let me know what you think!
shannondalebreaux
Getting the hang of it
"On Guard" is another 3rd party add-on using the Deepstack AI to perform AI analysis on camera images. Several are out there, each with pros and cons. And Blue Iris just recently added Deepstack integration to the program.
shannondalebreaux
Getting the hang of it
So you can use on guard and deep stack both do the same objective? I did notice deep stack was recently integrated with Bi now. I tried it before it was added. Has it become easier since it's now added to Bi?
On Guard, AI Tools, etc. all use the DeepStack engine as the basis for AI. It is certainly easier with BI now that it is integrated, but several members that have ran a 3rd party add-on have been running both the 3rd party and the DeepStack integration and feel like the 3rd party is better, especially at night....but that is for the moment as BI has had several updates almost daily or multiple times a day with improvements to the DeepStack integration.
There are certainly more bells and whistles that the 3rd party can do...and one that most like the 3rd party for right now is that you can specify more photos to send to DeepStack for analysis and right now that is limited to 5 images per event in Blue Iris.
shannondalebreaux
Getting the hang of it
It isn't really bugs, more like adding features. BI introduced Deepstack Integration and then a day or two later added facial recognition. So it is continually being improved as people start running it and we see what it is capable of and I suspect BI didn't want to wait until everything was added.
shannondalebreaux
Getting the hang of it
Gotcha it's nice AI has been integrated now instead of just relying on motion, Pixel changes with all the Ai software possibilities now out there.
I'm running v2.0.3 on the same machine as BI 5.3.7.11 with trigged images being writing to a NAS share by BI and subsequently read by OnGuard from the SAN share. Things seem to be working from what I can by stepping through earlier triggered images and analyzing them but my OnGuard logs are flooded with the same repeated messages shown below which are causing the logs to grow in size very quickly and ultimately make OnGuard unresponsive or crash. Does anyone know how to resolve this?
2021.04.07 23:09:17:0042 - DirectoryMonitory - File System Watcher Error! The parameter is incorrect.
2021.04.07 23:09:17:0042 - Attempting to recreate the DirectoryMonitor
2021.04.07 23:09:17:0496 - DirectoryMonitory - File System Watcher Error! The parameter is incorrect.
2021.04.07 23:09:17:0496 - Attempting to recreate the DirectoryMonitor
Thanks,
Joni
2021.04.07 23:09:17:0042 - DirectoryMonitory - File System Watcher Error! The parameter is incorrect.
2021.04.07 23:09:17:0042 - Attempting to recreate the DirectoryMonitor
2021.04.07 23:09:17:0496 - DirectoryMonitory - File System Watcher Error! The parameter is incorrect.
2021.04.07 23:09:17:0496 - Attempting to recreate the DirectoryMonitor
Thanks,
Joni
Try quitting and restarting. If that doesn't work then probably one or more of your cameras has in invalid directory. If all cameras appear to be using a valid directory, then I'm not sure what the specific problem is. I've never seen it, but here is a description of the errors that can be caught (On Guard comments in parenthesis, the rest from Microsoft):
This event is raised whenever something prevents the FileSystemWatcher object (the software that is looking for new possible motion frames) from monitoring changes. For example, if the object is monitoring changes in a remote directory and the connection to that directory is lost, the Error event is raised.
The system notifies you of file changes, and it stores those changes in a buffer that the component creates and passes to the APIs. If there are many changes in a short time, the buffer can overflow. (On Guard has increased the default buffer size significantly, but it is possible that this isn't large enough for you particular installation).
So, probably the directory isn't valid, or you have a lot of changes going on in the directory you are monitoring. I'd be careful not to have the camera directory be the directly where videos are stored (per the manual). In theory that shouldn't matter, but it might. If you are taking pictures at a very high frame rate (settings are in Blue Iris), you could try slowing that down. If you have multiple cameras in one directory, you could put each camera in a separate directory. Also, if you have pile of pictures (multiple tens or hundreds of thousands) in a folder you should probably cleanup the non-motion pictures at the very least.
You mentioned that you are on a NAS share. So, it seems likely that you've lost the connection to the NAS or Microsoft isn't handling monitoring the NAS well. I have used On Guard to monitor files on a remote Windows machine, but never on a NAS. There may well be a problem if the NAS is running Linux internally. That would not surprise me in the slightest. If possible, store the motion .jpg files on a local disk, even if the videos aren't local.
In any event, this error is not a good thing, and will likely cause significant problems.
Last edited:
I've been looking at the BI DeepStack integration. So far I haven't had a problem. Even with BI using DeepStack I still think that On Guard offers things that BI doesn't (and in reverse). We'll see. Maybe projects like On Guard will become less relevant over time.
Thanks Ken for the quick reply and two awesome software packages! The issue ended up being that this folder was on a NAS share (Linux-based Windows share essentially). I also dug up this old thread which seems relevant still unfortunately.
I was able to resolve my issue by creating a local folder on the BI machine and having BI post snapshots there which OnGuard is monitoring. This all seems to work nicely with my POC - OG's configured on one camera out of 15 (which I think rules out the high rate and folder issues you'd also suggested might be a concern).
The only thing I can think of at this point is since the log file growing sufficiently large seems to have caused stability issues with OG, NAS share aside, is there/can there be a way to either periodically rotate/delete log files and/or configure logging levels? I see there's an option to enable MORE detail but even the minimal log level seems a bit chatty. If I'm getting MQTT and email notifications, I don't want to log every time a MQTT message or email is sent nor do I want to log the result of each picture analysis (x interesting objects found). These log entries are invaluable for troubleshooting as I've found but once things are steady state, it would be nice to stop or turn down the logging level so the log size doesn't grow over time and create performance issues.
Thank you again!
-joni-
Right now there are 2 log file settings, detailed, and not. I've tried to balance things so that the detailed gives you enough detail to track down problems and the non-detailed to generally tell you what is going on when detecting objects and serious errors. I could try adding some finer grain control - 3 or 4 levels of detail. I have considered automatically deleting older log entries, but that becomes an issue if something happened 3 or 4 days ago and you just now noticed it. You can always manually delete the entire log file from within the Help menu. If you think that a large log file is causing problems you can always change your log file viewer application. The default, Notepad, was designed a long time ago, so it is possible it isn't handling large files well. You could try WordPad or NotePad++ (I would try downloading that first I think).
It is a balancing act between having enough data and not, and coming from the IT Operations world I completely understand and relate to the benefit of having had something logging and capturing log data when something happens/happened vs enabling logging after the fact and having to wait until it happens again (if you're lucky) and capturing logs that lead you to a solution.
The issue isn't notepad in this case. When my logs were growing rapidly it wasn't that notepad was crashing (it wouldn't even open but that's not the issue) it was OnGuard itself that was bogging down - perhaps because the writes started taking so long that the OS was blocking the app (OnGuard) from running? I was too focused on the error message to think of checking CPU metrics to look at I/O wait times and see if they were excessive or not.
For my two cents, I think a 3rd logging level of 'no logging' would solve the problem. From my experience with BI and now (limited) with OnGuard, if there is an issue be it code or user error, it happens regularly enough and is reproducible enough that had I been set to run without any logging that I could enable logging after having a crash or problem and still be able to get meaningful log data to troubleshoot.
Thanks,
Joni
Sorry for the delay in a response. I've been working on other things for quite a while now. I haven't noticed this particular problem. However, I guess I can see how it might happen. The log file gets written/closed after every write. I haven't noticed it myself, but this could definitely bogged things down. I'll change things for the next release.