Broadcast Server

Dependencies

• DigaSQL.dll 3.19.3492.0 (recommended)

Compatibility with BCS v6 - READ CAREFULLY!

Compatibility

• The 32-bit V6.x BCS is backward-compatible with all old clients. The 64-bit BCS can only talk with clients, which speak the new WebSocket based protocol. This is true for all V6 clients, with one exception - see next point.
• IMPORTANT EXCEPTION: DigaMOS is not yet able to use WebSockets for the BCS communication. Therefore: don't use 64-bit BCS if you are running DigaMOS for synchronizing rundown with BCS!
• Even in 64-bit the XML files on harddisk are still stored as UTF-8 XML. Therefore, you can always change between 64-bit and 32-bit or between 5.x and 6.x versions without data loss.
• For users of generic broadcast messages (used for inter-client communication, e.g. between DigAIRange and BUS to trigger a task or between TurboPlayers for exchanging macro commands or start reports): The support of 64-bit/IPv6 for generic broadcast messages could not be implemented with full backward compatibility. In a mixed enviroment with BCS servers of version 6 and pre-6 ones it will happen that some generic broadcast messages will be received multiple times by a client, others not at all. Therefore: if you rely on these messages, do not use mixed enviroments. All BCS servers, which can build up remote links should be upgraded to version 6! A mixture of 32-bit and 64-bit BCS servers is supported.

New key features

• BCS as a 64-bit version. This allows to hold more data in memory. For example: multiple full-time services on one BCS are supported now.

• Improved threading model and data locking in order to handle more simultaneous client connections.
• Support for OIDC (OpenID Connect) for authentication of web clients.
• WebSocket communication instead of the proprietary SeplProtocol via IP. "WebSockets" is a standard way of communication and the format of all exchanged data is documented now in the new BCSProgrammersManual.
• Support for IPv6 and support for TLS / secure WebSockets. (These features have not been a primary goal, but they come "for free" because of the used library boost::asio for the sockets.)
• Real-time play information for playing elements can now be sent by TurboPlayer, distributed to all clients by BCS and can be displayed by TurboPlayer ("real" remote player windows) and DigAIRange.

• Results of BUS ConsistencyCheck task can now be stored in BCS and be displayed in DigAIRange:

Breaking Changes

• In order to reduce the network traffic, BCS does no longer always send generic broadcast messages to all clients. If a receiver application type is specified in the XML of the message, the message is only sent to connections with the corresponding client application type.
• SGU-4940: When a client makes use of recursively setting a node lock, now a lock notification is only sent with the first lock and the last unlock request.
• SGU-4944: The file "LastSaveTime.txt" in the root directory of the XML storage is now only updated if at least one XML file was updated, too. So far this file was updated even when no XML files was written.
• CCD-42817: If a node has a relative start and the referenced node gets deleted without deleting the relative node, too, BCS sets the start attributes of the relative node now to Manual/Floating instead of StartOnTime/FixedStart.
• For security reasons a login with method "AD" is only allowed for an ActiveDirectory-synced user now and a login with method "HMAC" is only allowed for a user, who is not AD-synced. A login with method "RC5" is still possible for both types of users, but for both user types a password must be transmitted.
• The BCSGUI.exe does no longer read the extra registry parameter "BroadcastServer\<Config>\IP\ServerAddress". Instead, the parameter of BCS "OwnIPAddress" is evaluated (together with the port numbers). Alternatively, the BCS to connect to can be specified via command line parameter now: "/BCS=<protocol>:<address>:<port>" whileas <protocol> can be "SP", "WS" or "WSS". This overrides the registry parameters.

New features

• Implementation of a plain and secure WebSocket communication with clients using boost::asio, OpenSSL and zLib libraries. A new XML-based protocol on top of WebSockets was defined. This protocol is documented now in BCSProgrammersManual.

• BCS is now available as a 64 bit application, too: "BCS64.exe"/"BCSGUI64.exe". These modules support only the new WebSocket protocol but not the old SeplProtocol. There is also no support for DigaReportServer (deprecated) and not yet a support for BCS plugin dlls (called for new entries).
• The 64-bit version got a new advanced lock for the metadata tree. Whileas the old lock always locks the whole tree and cannot distinguish between read and write access, the new lock can be set on some individual tree nodes and it allows multiple readers at the same time. This advanced lock allows that more than a single processor core can access the data and therefore it can be a performance boost if you have many cores or many clients or host multiple programs in one BCS. The advanced lock must be activated with registry value BroadcastServer\...\General\UseAdvancedTreeLock=Yes.
• SGU-4188: Clients using the new WebSocket communication can perform a login with an OIDC token (=JSON Web Token) now. BCS can verify these tokens internally. Therefore it is required to define one or more locations, where BCS can retrieve public keys for the verification (JSON Web Keys) in the DigaSystem registry, in the new key "BroadcastServer\...\JWK". For more information see BCSTechManual chapter and the parameter description in DigParam.rtf.
• Added the parameter BroadcastServer\<Config name>\RemoteLoginData\LoginMethod. It is only needed in very rare occasion of using a DigaSQL login for BCS itself and having the remote BCS using a different set of registry files. See parameter description for more information.
• SGU-4450/CCD-41438: Jingle groups can have an access control list (ACL) now. If an ACL is empty, everyone has write rights, otherwise a user/group must be listed in the ACL to have write rights. "Higher" rights, like the manage right supersede an ACL. You need DigAIRange version 5.9.801.0 or newer to have an extended manage dialog for jingle groups in order to set an ACL.
• SGU-1734: BCS can received play state and play time messages from TurboPlayers via the WebSocket interface now. This information is stored internally and synchronized with other connected servers (buddy, remote BCS). Clients can request play info notifications and BCS will send out these notifications whenever an element starts, pauses or stops. In addition BCS sends out time information once per second.
• A new node type <ConcistencyCheckResults> with ID 00000005 below nodes <Program> has been introduced. BUS task ConsistencyCheck can store its reports in this new node. See BCSTechManual chapter 2 for more information. Cleanup of old reports is done by BCS in the background. By default, reports for shows, which ended more than 10 minutes in the past, are deleted. This interval can be configured in parameter: BroadcastServer\<Config name>\Settings\MaxAgeForConsistencyCheckResults in minutes.
• SGU-5535: When a show is being deleted, BCS automatically removes now all consistency check reports for this show.
• The information returned by GetDayStatusList includes now the last change timestamp for each day.
• The surrounding node returned by GetShowList includes now the date of the requested day.
• CCD-41858/SGU-4546: Added extended log output when writing to the XML files or when synchronizing the XML files between master and buddy BCS. This affects only protocol level 3 or higher.
• The log output when writing to the XML files was extended. Log level 5 gives most information.
• In the log output for a successfull login the login method is given now.

Fixed Issues

• When a day was created and filled from the day templates, no new GUIDs were created for the child nodes.
• CCD-42062: The computation of new node IDs and GUIDs did not always work correctly. There was especially the problem that the links for relative starts were destroyed in this computation. Another problem was that a clients request to compute new IDs was not transferred to a remote BCS.
• When deleting nodes with the flag to automatically remove referencing nodes, this did not work when sub-nodes of the specified nodes were referenced.
• SGU-4945: When a show XML file on the disk was deleted, BCS did no longer allow to open the affected day. This state remained forever. Now BCS can recreate the missing show from scratch/from the day templates.
• Specifying the data for the command line parameters “-c” and -"k" after a space (e.g. “-c nameofconfig”) did not work.
• In insert and update operations the node ID of nodes with fixed ID (like a track 0 of a show or a day trash) was not kept / not set to the fixed ID. This was a new bug since version 6.0.405.0.
• CCD-42807: When a remote GUI was connected and then a client tried to log in (or the BCS itself when checking its own availability) BCS could run into a deadlock situation, in which most of the threads were blocked and did not work anymore.
• CCD-41237/42889: When one client had a short-time lock set for a node and another client wanted to perform an operation with one of the locked nodes, it could happen that BCS crashed. This was a problem since version 5.5.340.0 of 2018-08-13.
• When a client did an UpdateNodeTree operation, existing node locks for children of the updated node got lost.
• When a client did a MoveBlock operation and one of the specified child nodes was short-time locked by another client, BCS returned the wrong error: "A node was deleted while waiting for the node to become lock-free.""
• CCD-42992: When inserting new days (content), shows or tracks, BCS computes new IDs for the nodes since version 5.9.379.0. This happens for track nodes, too, but this turned out to interfere with remote links to tracks. Now BCS tries to keep the IDs of track nodes whenever possible. Ideally, use this patch together with DigAIRange 6.0. or newer, because there is a patch in DigAIRange, too. It helps to keep the ID of track nodes and remote link information in insert shows/track operations.
• BCS did not allow to delete a track node with a dead remote link (to a no longer existing remote track).
• CCD-42929: Day templates, which were specified for a weekday and in addition for a single specific target date were used for other days with the same weekday but a different date.
• OIA-490: Prevention to write a Root.xml file with empty root tagname and automatic correction of that situation.
• CCD-43160: When performing a data update of an element with start attributes inherited from a parent group, BCS did not check, whether the inherited start attributes were still present after the update.