Broadcast Server
Component | Version |
|---|---|
BCS.EXE | 6.1.434.0 6.0.417.4 (Patch) |
Dependencies
DigaSQL.dll 3.20.3498.0 (recommended)
Known problems
For BCSService and WebDigAIRange no new version is available. A support for the new node type EndpointStory is not ready yet.
New Features (only 6.1.434.0)
BCS does now support a login with a DPE token (classic + secure). For more information please see: BCSTechManual Chapter 6.4.7 "BCS and DPE Tokens" and/or BCS programmers manual chapter 2.6 "Login/Logout" and/or DigParam.rtf description for parameter "BroadcastServer\...\General\DPETokenUrl". (OIA-1704)
Implemented support for the new node type (=tagname) "EndpointStory" and the new start mode "SyncStart". They are implemented for regionalization and for multi-channel distribution. In an EndpointStory individual elements for different distribution endpoints or regions can be scheduled. (OIA-2275)
So far, the start type Floating and the start modes Manual and Sequenced were not inherited from a group or story to its children. A new experimental parameter (→BroadcastServer\Default\Setting\StartAttributeInheritance) has been added. If set to "Regular" these start attributes are inherited, too. Hint: for a correct workflow the clients must be aware of this new behaviour of BCS. This is only the case for clients of the release 6.1. (CCD-43401/OIA-2180)
Fixed Issues (both, 6.1.434.0 and 6.0.417.4)
When the parameter BroadcastServer\...\IP\OwnIPAddress was used (set to something different than 0.0.0.0) together with (secure) WebSockets, then the background worker "AutoInsertFutureDays" did no longer work, because it could not get a connection to the own BCS server. (OIA-1750)
When a WebSocket-connected buddy BCS did disconnect without a proper logout, the master BCS did still think that a buddy is connected and it did reject new connection attempts of a buddy server with the error code -7 (CCD-43366)
BCSGUI: When switching between master and buddy BCS, the upper view with the list of connected clients was not updated but was empty.
When a client inserted a node directly to a day trash, BCS always deleted the delete info (like the user or the delete timestamp).
Mitigation of the still unsolved problem that sometimes (in very rare cases) the root node looses its tagname.