Problems detector in Xeoma
Large-scale video surveillance systems, ones of corporate level, utilize hundreds, even thousands of cameras. In such conditions it’s hard to keep tabs on whether all cameras are always online, or if the video surveillance system is functioning well.
That’s when automated video analytics of the so-called sabotage detectors come in especially handy – notifying operators and administrators about the threat or a criminal act in progress.
First victims of vandalizing are usually cameras themselves. Criminals try their best not to be filmed (that’s why it’s essential to project their placement right in the first place) and, if that’s hard, tend to eliminate the threat.
Vandalizing or breaking the cameras is the most frequent offenders’ choice. This might not be the cheapest scenario for video surveillance system’s owners, but on the plus side, operators will detect that camera was disabled that very instant, and take urgent measures. However, this is not the case for VSS that run for years and years without human supervision: not only is equipment damaged, valuables stolen, without any evidence of who did it, but also videos of other episodes can go missing before it is detected that the system isn’t working.
Another scenario includes more tech-savvy criminals who cut the cords for the cameras, for example, Ethernet wire where the camera stops sending its stream and the image freezes. Camera itself is not vandalized which is a plus, but on the other hand, the last received frame of such “frozen” cameras would hang on the display like it’s all good for a long time, without giving away that the cams have been tampered with, allowing wrongdoers operate from the comfort of a blind spot and then leave the scene unnoticed with their loot.
Best case, from the point of view of video surveillance system’s owners, would be if the camera is turned – simply pointed in another direction, blinded with a flash of light (for example, with car’ headlights) or obscured, for example, with a piece of cloth or a bag. The only damage here is what the criminals will take from the guarded site while the cameras are not watching. Technically, cameras are fine – they are monitoring a site all right, but not the site they should. If there are many cameras to monitor, operators may miss this little change and, consequently, miss the criminal act that was going on right under their nose, just like in a classic spy movie. No records and no evidence to prosecute.
“Problems detector” module in Xeoma
To provide unsupervised system health monitoring Xeoma offers not just edge-cutting on-screen diagnostics but also the “Problems Detector” module. Video analytics behind this sabotage detector provide automatic notifications of the form of choice about the scene changes (when camera is being tampered with) or when system’s “health” is involved.
Enhanced video analytics, flexible configuration and modular structure help you set up the system to give notifications for certain cameras when you want them. For example, you could send a notification to the system administrator when signal from one camera is lost but when it’s another camera – guarding the safe – trigger an alarm at once. Several types of notifications can be connected to the same camera.
Let’s take a closer look at the module’s settings.
Whenever you click on the module, you’ll be able to enter its module’s settings. In the “Problems detector” you will find the following options:
Trigger if there are no problems – if there are no problems being detected from the selected ones, then the module will pass the signal to the following modules in the modules chain
Trigger always – the module is always in the “Triggered” mode, i.e. it is passing signal to the following modules in the modules chain
Trigger if there are problems – if there is at least one problem being detected from the selected ones, then the module will pass the signal to the following modules in the modules chain
This option is used to track the issues that are not connected with your camera, even if the camera itself is not working (or there’s no camera at all). In this case all problems that are not connected with camera (issues with disk, RAM etc.) will be detected in any case.
Camera timeout slider
These options detect when there’s no update of the camera image and no audio from the camera. By means of the camera timeout slider, you can choose the time to trigger. I.e. if you set the slider to 10 seconds, then all “absence of video/sound” that are shorter as 10 seconds will not be detected.
Camera timeout slider
This checkbox detects full disconnection of the camera (e.g. when the camera is not responding/streaming at all). The camera timeout slider is used to set up the trigger time, e.g. you can set a necessary time to disregard the case when the camera is not responding for a short period of time to avoid false alarms.
Focus level slider
This option allows you to track whenever the image gets out of focus (blurry).
Brightness change tolerance, % slider
Lower limit of brightness, in % slider
Upper limit of brightness, in % slider
This option allows you to track whenever the image from the camera is too dark or too bright. E.g. when the camera is covered or flashed with a flashlight. Using the sliders, you can adjust necessary brightness that should be taken into consideration.
Image change threshold, % slider
This checkbox allows you to detect when your camera is turned based on the pixel offset of the camera image. The image change threshold allows you to set a value that will trigger the module.
This option allows you to detect the unstable camera work (loss of packets/camera streaming data). Most of the time such issues indicate network problems.
Space left less than slider
This option detects the amount of disk space left less than configured on the slider.
Remaining RAM info – information about RAM available
RAM left less than slider
This option detects memory (RAM) leak.
Higher than slider
Xeoma’s “Problems detector” can also monitor CPU load. You can configure necessary load to detect by the module with the slider.
Address of a network resource field
Interval of availability check slider
This option allows you to specify the IP address of any network device, Internet resource (website), etc.
For example, you can detect problems with Internet access on the server or track issues when there’s no access to a network device (automatic gate barrier, relay, etc.).
This option allows tracking server crash. This option will get triggered if the server was crashed and then restarted incorrectly.
This checkbox allows you to track issues with the archive database in Xeoma (archive.db – database that contains metadata from various filter-modules).
Incoming traffic, GB slider
Reset traffic counter interval drop-box
This option detects exceeding network limits.
Custom name of this filter for log
This option allows you to store all problems in a log file. You can specify the path for storing the log file in the following format: C:\Users\Public\Documents\Xeoma\Logs\ProblemsDetector.log (Windows)
Logs are stored by default in the “Logs” folder in the settings folder.
Error messages are also shown on-screen. With the right font size you will not miss Xeoma’s warnings:
You can adjust font size via “Layouts menu” (“squares/window” icon on the lower panel in the main window (all cameras view mode)) – Window settings – Font size for camera names (12 pt by default).
As mentioned earlier, “Problem Detector” can also save information to a log file. The log file is named ProblemsDetector.log. It can be found in the Logs folder in Xeoma’s folder. There are many messages the log may contain about scene change or system health issues, here is the full list:
- RAM is running out
- The RAM problem is resolved
- The server was restarted incorrectly
- Disk space is running out
- The disk space problem is resolved
- No free disk space left
- Camera image too dark
- Video stream is no longer too dark
- Video stream is no longer too bright
- Camera image too bright
- Camera turned or obscured
- Camera is no longer being turned
- Database update error
- Database reading error
- Database writing error
- Audio stream received
- Video stream received
- Camera image is missing or isn’t changing
- The network resource is not available anymore
- The network resource is available again
- High processor load
- Processor load normalized
- Image is not refreshed
- No camera stream (video or audio) entirely
ProblemsDetector.log:
|
Starting with beta version Xeoma 20.10.13 we added the ability to work in combination with filter modules (for example, with the “Scheduler”).
Starting with beta version Xeoma 23.3.22 we added the option to download the log file through the Client. Now the log file can be obtained even with a remote connection.
Starting with beta version Xeoma 23.3.22 we added new parameters to fine-tune the “Camera image too dark” option, which will help you get notified if the camera has been covered.
|
April 16, 2015, updated: March 27, 2023
Read also:
Frequently Asked Questions about Xeoma software
Complete Xeoma User Manual
How to define vandalism and prevent defacement and criminal damage with video security software with video security software