Time is everything: meetings, public transportation, religion, transactions: the whole world is working because the concept of “time” exists. Within a security (or any other) system this is not different: recording schedules, logging, authorizations, encryption keys, timelines, all of these concepts can exist because of time. As a result, time can either make or break a system: problems can appear only due to a time difference of a couple of seconds between two system components.
The attached document describes how time services can be configured in a BVMS environment.
When working with previous versions of BVMS, remote connectivity was cumbersome due to the amount of port mapping that needed to be configured. BVMS 7.5 provides a new method of remote connectivity utilizing Secure Shell (SSH) Tunnelling.
The attached document (attachments can be found on the bottom of the page) describes the set-up and configuration of the SSH functionality in BVMS.
In BVMS 10.1 we have added the capability for a management server (or DIVAR IP) to act as a bridge between a corporate network and a video network. We have described the configuration of this scenario in the BVMS 10.1 - Unteaming network interface cards document.
please find the release information about Configuration Manager 7.00.0111.
Configuration Manager 7.0 introduces a complete rework of the user interface, following the latest Bosch application style guide, with many improvements in readability, compactness and improved navigation for a better user experience.
Look-and-feel according to latest Bosch style guide, improvements on readability of form elements.
Screen space optimization due to higher density of presented information, optionally vertical navigation bar.
Scaling invariant user controls enable smooth support for high DPI screens.
Avoiding horizontal scrolling by adaptive column reduction.
New easy to use filters, supporting “Google”-like free text matching on various identifiers as well as down into device properties.
VCA pages with new sub-navigation, larger video presentation for easier task setup, improved calibration and Camera Trainer pages, in-field editing, object filter page, and providing tooltips and direct links to help pages.
Strong password demand during first start of the program. Working without password prompts extra warning pop-up and requires specific user action.
Certificate creation now allows including usage. This enables fully automated batch certificate creation for larger sets of devices. The creation dialog shows the progress of key creation.
Support for new AUTODOME IP 7000i and MIC IP 7100i with firmware 7.52, introducing changes and enhancements on picture settings and pre-position settings pages.
Setting an alternate home position is now possible for applicable moving cameras.
Support for new DINION and FLEXIDOME IP 3000i series with firmware 7.51.
An RCP+ message and/or a SNMP trap from cameras, if time sync fails, can be configured.
Assignment option for CHAP password on DSA E series storages added. Password must be from 12 to 16 characters long.
Playback permission is configurable for IP Matrix since decoder firmware 9.60.
Support for Bosch Video Client (BVC) and BVIP Lite Suite is excluded.
The configuration backup of the Configuration Repository is now referring to the MAC address of a device instead of the IP address.
Network scan is now also possible for IPv6 networks.
Context menu and some configuration pages cleaned-up for decoders.
Improved feedback on firmware upload status and errors.
The character ‘+’ is not allowed anymore for camera passwords since it is also blocked in cameras from firmware 7.50 onwards.
The image posting tab is moved from ‘Network’ to ‘Recording’, and a link to configure accounts was added.
Secure crypto-coprocessor version is now displayed on camera’s compatibility tab.
Configuration Manager 7.0 has excluded support for Bosch Video Client and BVIP Lite Suite. Installing it over an existing installation of a previous version will encrypt the database with strong encryption and thus render it unusable for the older software.
Please refer to the release notes for details:
The software package will be loaded into ST4 the next days and uploaded to the product catalogue with the next sync.
It has already been uploaded to DownloadStore as well.
The attached manual provides information for Mobile Video Service (MVS) within Bosch Video Management System. You can find:
- how to configure the router and Internet Information Service (IIS)
- how to add MVS to BVMS
- user guide
- some troubleshooting tips
The attached document describes the different components that Bosch Video Management System offers to to establish a connection between Bosch Video Management System and a 3rd party management system. This description helps you in writing your own commands for controlling Bosch VMS from inside your management system.
Connectivity problems after DIVAR Mobile Viewer APP upgrade from v3.0.0 to the new v3.1.0
As result of a software bug in the APP problems in the connectivity can occur in case the DIVAR hybrid/network is running firmware v3.0.0 or below. Running firmware v3.1.0 does not show the problem.
This problem exists for both Android and IOS app platfoms
DIVAR Mobile Viewer app 3.1.1 for both Android and iOS have been released and are available on the stores. This version is compatible with previous DIVAR hybrid/network firmware v3.0.0 and 3.1.0
Additional info for DIVAR AN 3000/5000
For the DIVAR AN 3000/5000 we just learned that the DIVAR Mobile Viewer app v3.1.1. can consume more than one session per device. This typically happens when in the Live Preview the "Device List" (top right icon) is used to open all cameras simultaneously. This seems only to happen as a first action when you open the app. This can result is a failing connection showing the message “System is busy”.
For the moment please apply these workarounds avoiding this connection problem: - Change the number of remote sessions allowed (default=4) in the DIVAR AN 3000/5000 configuration to 64 (Menu, Settings, Network, Max. connection) OR - Avoid the use of "Start Live Preview (16)" in "Device List" as an first action. By viewing one camera only as first action showed that new session consumption was prevented.
In case of occurring connection problem: close and restart the DIVAR Mobile Viewer app. This problem seems not to occur when using Android or for accessing DIVAR network/hybrid.
The attached document will provide a basic explanation and simple examples of the interfacing (scripting, calling functions by external applications) functionality in Bosch Video Management System. The interfacing functionality is based on Bosch VMS SDKs. The Bosch VMS SDKs contain all interfaces, object types and methods that are needed for automation and integration to and of Bosch VMS.
The document can be found in the attachments section on the bottom of the page or at the right side of the page. Please look for the attachment icon.
The attached document describes the settings you must perform after having installed BIS and BVMS on the different computers. Ensure that the installations of BIS Server and BVMS Management Server were performed successfully on separate computers. Additionally you must have purchased and activated an OPC Server License for BVMS.
The document can be found in the attachments section on the bottom of the page or the right side of the page. Please look for the attachment icon.
In many cases a minimum and maximum retention time needs to be defined in a video surveillance systems due to legal requirements. While the minimum retention time defines the time period for how long video recordings need to be stored, the maximum retention time defines after which period of time the recordings have to be deleted. Thus, the minimum retention time is going to influence the amount of storage needed. The higher the minimum retention time the more storage space is required.
Hence, the storage space needs to be large enough to store the recordings for the minimum retention. For the maximum retention time this doesn’t have to be the case. Still users might be confused why recordings gaps might appear sort-of randomly, if the system does not have enough storage space to keep all recordings until the maximum retention time is reached. To understand what is going on we have to remember the principle of the VRM block assignment first.
For each camera in the system the BOSCH Video Recording Manager (VRM) generates a list of recording blocks (LUNs) on which the camera can next record. Therefore, the VRM makes an estimation based on the data rate and the amount of data of each camera in the system (global optimization). Basically, the VRM predicts when which camera needs a new block and always lists the block which will be the oldest block at the time the camera needs to record on the next block. One could think of it as a “next oldest block” estimation done by the VRM. But the prediction of the VRM might differ from the reality (mainly because of variance in recording bitrate) and this can cause recording gaps if the storage space is not large enough to support the maximum retention time.
Let’s have a closer look on the following two cases:
Sufficient storage space for maximum retention time
Insufficient storage space for maximum retention time
Sufficient storage space for maximum retention time
In case of sufficient storage space to fulfill the maximum retention time for every camera in the system no random recording gaps will appear, because the VRM will always assign a block containing recordings, which are older than the maximum retention time. Thus, for each camera the recording blocks will be kept until the maximum retention time is reached as illustrated in Figure 1.
Figure 1: Enough storage space to cover the maximum retention time for each camera of the system
Insufficient storage space for maximum retention time
In case the system is designed such that the storage space is not large enough to store all recordings from all cameras until the maximum retention time is reached, the VRM will of course still do its estimation and predict the oldest recording block when a camera will ask for a new block. Assuming an ideal setup (with ideal network connection where each camera has the same data rate and all cameras record the same amount of video data simultaneously), the oldest block would always be assigned by the VRM. Hence, no recordings gaps should appear for recordings older than the minimum retention time, compare Figure 2. This is was most customers falsely assume or expect.
Figure 2: Customer expectation of the system behaviour in case of insufficient storage space to cover the maximum retention time for each camera of the system
However, in reality the stated assumptions do not apply. Network connection, data rate, amount of recorded video data, etc. varies. Thus, the “next oldest block” estimation of the VRM can differ from reality. Since each camera already got its block list from the VRM and records according to this block list, it can happen that not the truly oldest block is used and recording gaps appear as shown in Figure 3.
Figure 3: System behaviour in case of insufficient storage space to cover the maximum retention time for each camera of the system
How to avoid or minimize this effect
To avoid this effect of random recording gaps simply add enough storage to your system. To get the best out of your system in terms of storage usage, the optimum would be to set the maximum retention time to storage limit, see Figure 4, but that is almost impossible to realize in practice.
Figure 4: In principle a maximum retention time set to the storage limit would avoid random recording gaps
Option 1 to minimize the effect in practice is to estimate the maximum retention time so that it will not exceed the storage limit of the system as illustrated in Figure 5.
Figure 5: Maximum retention very close to the storage limit will minimize the random recording gaps
Another less recommended option is to set a smaller time difference between the minimum and maximum retention time. But especially when the minimum retention time is shifted closer to the maximum retention time that introduces the risk that the VRM cannot free up storage space in case the minimum retention time is reached, which might result in a recording stop. Thus, we recommend to go for the first option.
One last hint: Changing the retention time on a running system is not going to influence the retention time of already recorded blocks. but will of cousre only be applied to new recorded video footage. Hence, changing the retention time is no option for an immediate change of required storage.
Level confidentiality: external
Related Products: Video SDK
Analyzing issues with Video SDK based application is a challenging task. One needs to determine if the issue is based on wrong implementation of the Video SDK functionality, wrong programming practices, functionality and runtime behavior of the system with SDK functionality or Video SDK issues. In order to start troubleshoot Video SDK application support needs the following initial information and logging.
Please prove the following information to support.
2.VideoSDK issue description
What is the expected behavior?
What is the issue?
Which shared resources are accessed by SDK actions? (Dome cameras, decoders, etc.)
Do SDK components interact with an unreliable environment? (Unstable network, offline devices, offline PCs, etc.)
Do SDK components properly handle offline situations? (offline devices, configuration changes, ...)
Please provide source code and/or Log files
The optimal approach is to provide both source code and logging for the problematic Video SDK application.
1.Try to reproduce the issue with one of the Video SDK samples (Advanced C# Sample, Complete C# Sample, Simple C# Sample) and provide the result from the test.
Provide a little sample application that illustrates the Video SDK issue and list the reproduction steps.
Enable VideoSDK backdoor logging, reproduce the issue (note the date and time) and provide the Video SDK logs. How to collect Video SDK log files
Compared to hardware, in which it is relatively easy to define an end-of-support concept based on the expected lifetime, software behaves totally different. In theory, when the environment does not change, software can still be running ten years after it has been installed. As new versions of the software are released regularly, it is important for customers to know what they can expect from Bosch Building Technologies when the software is purchased. This document describes how Bosch Building Technologies handles the life-cycle of the BVMS, BIS, AMS, and APE, and in which state a specific release can reside. Additionally this document lists the up-to-date situation for all of those software packages.
The Activation Key provided from SLMS cannot be activated in BVMS.
During the introduction of BVMS 10.0 the BVMS Lite16, 32, and 64 base licenses were not introduced and succeeded by BVMS Lite 10.0 (8 channel base package). Existing BVMS Lite customers might still want to upgrade to BVMS 10.0.
The LIF file attached to this article (in the zip archive) can be imported in BVMS Lite 10.0 installations using the license manager (the license manager can be found in the "Tools" menu of the BVMS Configuration Client). Once imported, BVMS Lite 16, 32, 64 systems that are covered under SMA can be upgraded.
This article will guide you how to remedy invalid expansion licences on your Bosch Divar IP 5000 all in one.
Dispite that the registration of your additinal purchased licencens has been completed successfully. The licecens may become invalid after a following reboot. This behaivor is caused by switching the MAC address of your teaming interface.
In order to prevent such behavior or even to revoke your licences as they are already invalid,
please perform the follwing steps:
Download the attachment MacAddress.zip (2 KB) and provide it locally to your DIP all in one
Unzip the archiv, it should extract two files (setMacAddress.cmd / setMacAddress.vbs)
please do not alter or move the files!
Open the command promt (CMD) as adimistrator, e.g. right-click on the windows button and click on Command Promt (Admin)
Run the "setMacAddress.cmd", for this purpose navigate to the location where you have stored the unzipped files and call the "setMacAddress.cmd" file
YOURPATH\setMacAddress.cmd and hit enter
Press the spacebar to continue, after the cursor is blinking again you can close the CMD
Reboot your device, in order to complete the task.
During the introduction of BVMS 10.0 the BVMS Plus unmanaged site expansion licenses were not introduced, even though this functionality was announced to be available.
The LIF file attached to this article (in the zip archive) can be imported in BVMS Plus 10.0 installations using the license manager (the license manager can be found in the "Tools" menu of the BVMS Configuration Client). Once imported, the purchased licenses (MBV-XSITEPLU-100) can be activated.
BVMS Installer - Windows Pending Restart Message
The pop-up dialog window message: "Setup has detected a pending restart. Please reboot the system and rerun the installation" appears when attempting to run the valid BVMS windows installer package.
BVMS Installer Pending Restart Message
This is a known Windows specific problem when another (non-BVMS) installer does not properly manage its creation and deletion of the “PendingFileRenameOperations” registry key. The most common user created way for this key value to be left resident in the system is when an installation prompts for a restart, yet the system is not expeditiously restarted.
A. Restart the affected workstation
B. If the issue still persists, delete the orphaned "PendingFileRenameOperations" registry key value
Open a registry editor, such as Regedit.exe or Regedt32.exe.
Navigate to "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\"
In the right navigation pane, right-click the "PendingFileRenameOperations" key value and select delete
Close Registry Editor.
Run the software Installer again as Administrator
Note: This message is not a Bosch product failure message. This is a problem within windows and it's registry clean-up handling. This is a Windows work around.