Broadcast Server

Component

Version

BCS.EXE

BCSGUI.EXE

6.2.442.0 (32 bit)

BCS64.EXE

BCSGUI64.EXE

6.2.442.0 (64 bit)

Dependencies

CCD-43817: When BCS created a year, a month or a day node without copying from a template then the field GUID was missing.
CCD-43937/CCD-43401: In new mode StartAttributeInheritance=Regular the start mode "Relative" was not inherited.
BCS inherited start types and start modes from groups/stories to unplayable children - especially to info elements.
BCS did send an ExtraDeleteInfo notification and a corresponding UpdateNodeTree notification in the wrong order.
CCD-43937/CCD-43401: The implementation regarding start attribute inheritance of the last build had the new bug that the time calculation for groups and stories did not work correctly.
CCD-43878: BCS did not remove the information about the active on-air client (stored per program and track number) when a client did disconnect before giving up his on-air activation.
Clients, which requested extended UpdateNodeTree info, did not receive partial UpdateNodeTree notifications with new time info for some operations. This was a new bug since the last build.
The option "QueryChangeTime" for the GetNode call did not work when the requested node was one, which can appear in a rundown node (Group, Story, EndpointStory, Element). An error was always returned.
Fixed a crash when using the function to copy a node behind an existing node. This was only a problem of the not yet released version 6.2.

In order to better support an upgrade of BCS v5 -> v6 it is possible now to configure a replacement of remote link data in the registry values: BroadcastServer\ <config>\RemoteLoginData\UseInstead. This allows e.g. to keep remote link data using the old SeplProtocol in the metadata of shows/tracks, but BCS will build up remote conncections with WebSockets instead.
A new option "QueryChangeTime" for a call of function GetNode is available. It signals that a client is only interested in the change-timestamps of nodes. BCS will read this information directly from hard disk for nodes, which are not in memory. This is faster than fully loading these nodes, it does not increase the memory load and does not disturb other clients.
When a client requests notifications, the flag <RequestExtendedTreeInfo> can be specified. BCS will the send all notifications of type UpdateNodeTree with the special field <PD_UNT_INFO> set in each node. This flag signals to the client, whether the node is new or old, kept the position or was moved and whether the metadata is unchanged, changed or changed without relevance for a fulltext index.
The new command line parameters -b and -bm make BCS execute a batch file before starting. This allows to map drive letters when BCS runs as a Windows service.

BCS does no longer send extra delete info for deleted days. The resulting XML could have been much too big (many 100 MBytes).

Component

Version

BCS.EXE

BCS64.EXE

BCSGUI.EXE

BCSGUI64.EXE

6.1.434.4 (Patch)

CCD-43817: When BCS created a year, a month or a day node without copying from a template then the field GUID was missing.
CCD-43937/CCD-43401: In new mode StartAttributeInheritance=Regular the start mode "Relative" was not inherited.
BCS inherited start types and start modes from groups/stories to unplayable children - especially to info elements.
CCD-43937/CCD-43401: The implementation regarding start attribute inheritance of the last build had the new bug that the time calculation for groups and stories did not work correctly.
CCD-43878: BCS did not remove the information about the active on-air client (stored per program and track number) when a client did disconnect before giving up his on-air activation.

In order to better support an upgrade of BCS v5 -> v6 it is possible now to configure a replacement of remote link data in the registry values: BroadcastServer\<config>\RemoteLoginData\UseInstead. This allows e.g. to keep remote link data using the old SeplProtocol in the metadata of shows/tracks, but BCS will build up remote conncections with WebSockets instead.