Broadcast Server - BCS

Dependencies

• DigaSQL.dll 3.21.3518.0 or newer (recommended)

• DigaSQL64.dll 3.21.3518.0or newer (recommended) - for use with BCS64.exe

New/Changes/Fixed Issues

for 6.4.

Build 6.4.460.1

• OIA-2850: Intermediate bug of version 6.4.460.0 was fixed (additional line breaks were added to generic broadcast messages. which caused clients to not react on these messages).

Build 6.4.460.0

• Bugfix: CCD-44901,44906,44676/OIA-6710: It could happen that a backup BCS running in a buddy cluster was not synchronized correctly. This was the case when a client of the master made operations on a day, which was never opened before. The notification about applying the corresponding day template was sent to the buddy much too late and did then overwrite the original operation of the client. Especially, when the operation was an import of full shows, a lot of data - and even the whole show structure - could get lost. Hint: this was only a problem for BCS version 6.x.

• New: The new command line parameter -startupdelay or -sd allows to delay the startup of BCS for the specified time in seconds. This works for a BCS running as a Windows service, too, and can help to lower the possibility of starting two BCS buddies at the same time.

Build 6.4.461.0

• Change: CCD-44854/OIA-6953: BCS used the last element of a group with a real stop time to determine the stop time of a group - even if this element was completely overlapped by main elements, but did not have the Overlaid flag set. Now BCS takes the last stop time of all played elements in a group to determine the stop time of a group.

• Bugfix: CCD-45243/OIA-7205: The function, which should check regularly, whether both sides of BCS buddies are running in master mode did not work correctly anymore. This was a new bug since version 6.0.400.0. As a consequence, it could happen that in such a setup either both servers were running in master mode or that terminating the right server did not work.

Build 6.4.462.0

• Bugfix: When the send state of multiple elements was changed, BCS marked these elements in the resulting UpdateNodeTree notification as "no action for the fulltext index necessary". This was wrong, because BCSSearch can search for the send state very well and as a result the data in the fulltext index was not updated by BUS.

Build 6.4.463.0

• New: CCD-45205/OIA-7412: BCS supports to assign a combination of the special endpoint "TurboPlayer" with other endpoints for one element. Handling of start attributes and the time computation for this case was modified. Spoken more generally, the case of elements, which have multiple endpoints assigned to them, is handled slightly differently, because BCS builds up a sequence of elements for each individual endpoint name now.

Build 6.4.464.0

• Bugfix: CCD-45362/OIA-7572: A BUS Index task, which was crawling the BCS tree for changes, did lead to data loss in the BCS tree. This affected every first existing day of each month, but not for days, which were permanetly loaded into BCS memory (which is the case for current days). As a result, the shows of these days contained only an empty default track 0 and an empty pool. This bug was only happening in the 32-bit variant of BCS and is probably existing since version 6.2.440.0.

Build 6.4.465.0

• Bugfix: CCD-45373+45358/OIA-7598+7599: It seems to happen sometimes that BCS is no longer able to send data to its SeplProtocol clients - though the connections are still existing. This results typically in error 0x20000580 being reported. As the reason for this problem is completely unclear, only a workaround could be made.
  You can set the new parameter BroadcastServer\<config>\General\RestartOnError=SPSendData.
  Then BCS will restart itself when the error occurs for more than 5 times in 1 minute.
  Hint: for debugging purposes it would be good to additionally set parameter: WriteMemoryDumpBeforeRestart=TRUE.

Build 6.4.466.0

• Bugfix: The configured sync-start ID field was not part of the fields, which were distributed with an UpdateNodeTreePartially notification.
  This could result in the situation that clients were not informed about a sync-start ID if it was implicitly set by BCS. For TurboPlayer this meant that a sync-start was not executed.

• Bugfix: CCD-45205/OIA-7412: Fixed multiple small issues around the possibility to combine the special distribution endpoint TurboPlayer
  together with other endpoints/regions for one element (which was implemented in build 463).

• Change: CCD-45403/OIA-7650: BCS does now take the duration of an element with SendState=Placeholder and MediaType=Unknown into account.This was already the case in versions before 6.2.440.0 of 2023-04-17, but since the mentioned version this was no longer the case. (This was a side effect of the corrected inheritance of values from a group/story to its children).

• New: CCD-45364/OIA-7472: If the start mode or start type of an individual element/story/endpoint-story is modified with a single UpdateNodeData request and the
  modified node is the first child of a story/endpoint-story/group, BCS does now copy the start mode/type to the parent node(s). This is a "reverse inheritance", but it follows the setting BroadcastServer\Default\Settings\StartAttributeInheritance, nevertheless.

Build 6.4.467.0

• Bugfix: CCD-45462/OIA-7885: When switching from a master BCS to its buddy and then back again, data loss could occur (days/show files were deleted).
  The reason is still unclear but it seems that a buddy running as slave cannot be synchronized when shows are created on the master.

  • Therefore, the logging around the synchronization was extended, especially when a slave handles notifications of the master.

  • A slave BCS will now regularly check, whether the XML data tree of the master contains more dirs/files than its own XML data tree.
    If a discrepancy is detected and remains for some minutes, the slave triggers a self-restart. During startup a full synchronization on file level will then take place. The new parameter "BroadcastServer\<Config>\Timer\BuddyFileCheckInterval" (in minutes, default is 30) can be used to configure the interval or to switch the feature off (=0) in case of problems.

  • When saving XML files, BCS will now make up to 20 attemps in ~5 seconds to access a file if the file is locked by another process.

Build 6.4.468.0

IMPORTANT HINT: Version 6.4 will be the last one to be available in 32-bit and with a support of the old SeplProtocol. Version 6.5 will only be available in 64-bit and with a support for WebSockets only.
You should make sure that all your clients are using WebSockets before the next upgrade!

• Change: OIA-8031: So far, BCS needed carriage-return & line-feed characters behind the separator "<<<<DATA>>>>" of XML WebSocket messages.
  In order to facilitate cross-platform interoperability the CRLF is no longer needed.

• Change: CCD-45364/CCD-45526/OIA-7472: The implementation for this case in version 6.4.466.0 proved to be too "aggressive", meaning:
  a reverse inheritance was done in too many cases. Therefore, the implementation has been replaced.
  Now a client needs to explicitly send the metadata Time_OnAirStartType="" or Time_OnAirStartMode=""
  to trigger the reverse inheritance of the start type/mode to parent nodes.

• Bugfix: CCD-45462/CCD-45367/OIA-8046: When switching from a master BCS to its buddy and then back again, data loss could occur (days/show files were deleted).
  Reason is a de-synchronization of the slave BCS when a day template is applied to a day.
  This happened when (1) a day is requested by a client for the first time and the corresponding day template is not yet applicable and when (2) the corresponding day template was then applied later and the template already contained a day pool and a trash. This was a bug since version 6.0.400.0.

for 6.3.

Build 6.3.457.3

• Bugfix: CCD-45362/OIA-7572: A BUS Index task, which was crawling the BCS tree for changes, did lead to data loss in the BCS tree.
  This affected every first existing day of each month, but not for days, which were permanetly loaded
  into BCS memory (which is the case for current days). As a result, the shows of these days contained
  only an empty default track 0 and an empty pool.
  This bug was only happening in the 32-bit variant of BCS and is probably existing since version 6.2.440.0.

Build 6.3.457.4

• Bugfix: CCD-45373+45358/OIA-7598+7599: It seems to happen sometimes that BCS is no longer able to send data to its SeplProtocol clients -
  though the connections are still existing. This results typically in error 0x20000580 being reported.
  As the reason for this problem is completely unclear, only a workaround could be made.
  You can set the new parameter BroadcastServer\<config>\General\RestartOnError=SPSendData.
  Then BCS will restart itself when the error occurs for more than 5 times in 1 minute.
  Hint: for debugging purposes it would be good to additionally set parameter WriteMemoryDumpBeforeRestart=TRUE.

Build 6.3.457.5

• Change: CCD-45403/OIA-7650: BCS does now take the duration of an element with SendState=Placeholder and MediaType=Unknown into account.
  This was already the case in versions before 6.2.440.0 of 2023-04-17, but since the mentioned version this was no longer the case. (This was a side effect of the corrected inheritance of values from a group/story to its children).

Build 6.3.457.6

• Bugfix: CCD-45462/OIA-7885: When switching from a master BCS to its buddy and then back again, data loss could occur (days/show files were deleted).
  The reason is still unclear but it seems that a buddy running as slave cannot be synchronized when shows are created on the master.

  • Therefore, the logging around the synchronization was extended, especially when a slave handles notifications of the master.

  • A slave BCS will now regulary check, whether the XML data tree of the master contains more dirs/files then its own XML data tree.
    If a discrepancy is detected and remains for some minutes, the slave triggers a self-restart. During startup a full synchronization on file level will then take place. The new parameter "BroadcastServer\<Config>\Timer\BuddyFileCheckInterval" (in minutes, default is 30) can be used to configure the interval or to switch the feature off (=0) in case of problems.

  • When saving XML files, BCS will now make up to 20 attemps in ~5 seconds to access a file if the file is locked by another process.

Build 6.3.457.7

• Bugfix: CCD-45462/CCD-45367/OIA-8046: When switching from a master BCS to its buddy and then back again, data loss could occur (days/show files were deleted).
  Reason is a de-synchronization of the slave BCS when a day template is applied to a day.
  This happened when (1) a day is requested by a client for the first time and the corresponding day template is not yet applicable and when (2) the corresponding day template was then applied later and the template already contained a day pool and a trash. This was a bug since version 6.0.400.0.