Possible causes and solution(s)
The Dicentis does not need any additional encryption to be set via the OMNEO Firmware Upload Tool. (OFUT)
If you have set this by accident it could lead to that you can not see or update your units with the OFUT any more.
stop the Firmware Upload Tool
delete the following file C:\Program Files\Bosch\OMNEO\Firmware Upload Tool\FirmwareUploadHIConfig.ini
start the Firmware Upload Tool
Encrypted devices did not show up and you can not update them anymore. Do not set a password for default!
Open and delete this file C:\Program Files\Bosch\OMNEO\Firmware Upload Tool\FirmwareUploadHIConfig.ini
Open the OFUT and units will appear again.
After upgrading to DICENTIS Conference system 3.60, TLS1.0 is disabled for security reasons, and TLS1.2 is enabled. Since the Multimedia device does not support TLS1.2, it does not show logo and participant images anymore.
In some cases it could be necessary that you need to maintain the Microsoft SQL database which DICENTIS is using to save participants, user, seats and settings.
In the next steps I will explain some of the basics commands.
Connection between DCN server and operator client will disconnect. This is occuring when using windows 10 PC's with SSD-disks.
After restart of the DCN services it will work for a while.
Also windows 10 has the 'fast startup' option enabled. This option will store settings and running services to have a fast startup. Because of this our services will start to fast and are not properly connected to the other services.
And the use of SSD-disk in the server PC can cause a start up that is to fast for the services.
In windows 10 there is the option enabled to store some services when the system has been shut down and start up again. This can cause problems with our services:
1: disable fast start-up option in the win 10 PC:
go to the control panel of windows
then go to 'power options'
then click on 'choose what the power buttons do'
then click on 'Change settings that are currently unavailable'
then disable 'Turn on fast startup'
Also the use of an SSD disk in the server PC can cause some startup problems with our DCN-NG software. You can fix this by doing the following:
go to the services
right-click on 'DCN-SW Server'
click on 'Properties'
Change startup type to 'Automatic (Delayed start)'
Now restart the PC and test with these settings.
Symptoms: When a meeting is recorded and the recording software (either Meeting Recorder or Open Interface connection) is shut down, the microphone control mode switches to "Open", independent of what it was before.
The RESTful API of the CCS1000D is used in order to get a clear view of the state of the discussion devices’ microphones (amongst other things). However, when a Priority call is made, the other speakers still show as active even though they are muted in reality.
This is actually as it' supposed to work. The reason the speakers still show as active is because they remain in the speaker list while the priority call comes through (in this case, the chairperson making an announcement overruling all other parties) is that in the system there’s a difference between speakers being muted and speakers being removed from the speaker list.
In this case, after the priority call ends, the speakers are unmuted and can resume the discussion.
It’s also possible to configure the system to stop all speakers and remove all waiting participants from the request list. If the system is setup in this way and the chairperson starts speaking, the system will indeed erase all other speakers and waiting speakers.
The API can be used to create a custom interface. This means that logic can be added so the preferred outcome is created. In this case it means that the custom interface needs to poll for the speakers list but also needs to take in account that when a priority call comes through (also pollable) this means the others are muted. Using these two givens can then be used to for example change the icons of the speakers to a ‘muted’ state in the custom interface.
Product(s) affected: DCN-NG systems with master & slave CCU set-up
A DCN-NG system will be installed in a building which uses different VLANs for different floors in the building. They want to be able to have interpreters on one floor (in one VLAN) and the rest of the system on another floor (in another VLAN). To this end they have connected their Master CCU to another VLAN than their Slave CCU. This set-up does not work.
Question is; should this work and if not, why not?
This cannot work in a DCN-NG system because of the way the system is designed.
The communication between the CCU’s, at start-up of the system, uses broadcast messages which are not routed by network devices. These messages have a time-to-live (TTL) of 1, which means that once they attempt to cross into another (V)LAN, the messages are not propagated by the routing (L3) switch.
The reason is that the TTL of the packet is decreased every time it traverses from one network to another. When the TTL’s value reaches 0, the packet is dropped by the routing device.
Therefore, the broadcast packet will never reach the other CCU, resulting in error messages like “No Master CCU” on the Slave CCU.
Therefore the system should be installed on the same (V)LAN. This usually does not pose any technical problems as (V)LANs can be distributed over multiple network devices without issue, it’s just that the predictability of where a device is physically located is less in this instance.
DCN-NG is set-up in a multi-PC environment, all required licenses are installed. When trying to connect to the server from the secondary PC, the Operator Application takes a long time to start and once it does, the screen is simply blank and the server icon mouse-over shows the application is disconnected. When pinging the server from the secondary PC, the ping goes through without issues.
When upgrading from a previous DICENTIS version that supports DANTE (V2.20 – V3.00) to the latest version 3.10, the following problem will occur; The DICENTIS system is not visible anymore in the Audinate’s DANTE controller software, where it was visible before the upgrade.
The APS in question was running on v1.12 and needed to be upgraded to v2.60 and any firmware updates would continually fail (even other intermediate versions). The below procedure is not specific to this update and can also be used for updating from other older versions.