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
Customers can upgrade the DIVAR firmware to v3.1.0, this will resolve the DIVAR Mobile Viewer v3.1.0 app connectivity problems.
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.
More Sites Up to 128 sites are now supported.
Easy Video Access Easy access and switch between your video views.
Remote Site Editing Configure and edit your sites from remote.
Faster Connectivity Access your sites and cameras faster than ever before.
BVMS, Operator Client
This article describes the initial information needed to start troubleshooting Operator Client Crash.
Needed information and logs from the customer:
1. Note down the events that lead to crash
2. Classify the crash
reproducible crashes that trigger Windows Error Reporting
crashes/hangs/freezes that are hard to reproduce, or take long before repeating
3. Provide the following logs:
Dump file from the crash – refer to the following article ( https://community.boschsecurity.com/t5/Security-Video/How-To-create-BVMS-memory-dump/ta-p/7326 )
ConfigCollection from the machine where the crashing Operator Client is running.