TurboPlayer

TurboPlayer

Dependencies

• DigaSQL.dll 3.20.3500.0 (recommended)

• MultiRec4 4.8.339.0 (recommended)

• OnAIR TrackMixer 2.9.802.0 (recommended)

• DigaStory.ocx 1.5.87.0 (recommended)

Fixed Issues 

• It could happen that TurboPlayer unloaded a show just a few second before the show should start. Now there is a protection: if the current time is in an interval of 60 seconds before and 30 seconds after a know show start, TurboPlayer does not unload any show. (CCD-44131)

• When two TurboPlayers did simultaneously run a show and a group had controls, which should be executed at the start/stop of the group, these controls were executed by both computers. Now only the first computer to start an element in a group will execute the start controls and only the computer, which has executed the start controls (or which has started the group) will execute the stop controls. (CCD-43520)

• When a played element was copied from a rundown list to another stack-rundown in clipboard mode, the internal state “played” was not removed and as a consequence this element was not preloaded.

• The macro command TP_UpdateEvents() never worked. (Only the old command TP_ActualizeEvents() with the “denglish” usage of word “actualize” worked.) (CCD-44085)

• An element in the rundown with flag “Time_Overlaid” being set but without the otherwise necessary start attributes, could make TurboPlayer be blocked in a loop, trying to correct this invalid situation. BCS notifications and internal states were no longer handled correctly. This affected the GUI, too. (CCD-43302)

• When an exception happened while handling a macro, the internal structures for macro handling were not cleaned up properly. This could lead to problems with further macro executions. Also no stack dump was written. (CCD-43288)

• A show was not automatically unloaded if it was the single loaded and single available show and the show metadata were changed so that the show did fall through the show filter. (CCD-43919)

• If a setting like “TurboPlayer\GUI\Windows\CFM\1” appeared in the local and in the global registry, TurboPlayer created the corresponding window twice. (CCD-43536)

• Fixed multiple problems of handling EndpointStories and play state synchronization:

  • When TurboPlayer advanced the list of loaded shows into the future, it could happen that stacks in Endpoint-mode were not loaded correctly together with the show list.

  • The synchronization of pause, restart after pause and stop worked only for the very first element of each endpoint but not for further, sequenced elements.

  • If an element in a rundown in stack mode “Endpoints” was stopped, this could cause other elements of the same EndpointStory to stop, too, though such a synchronization should work only from the master (neutral) element to a regional element.

  • Play-/remain time info in the rundown view was not displayed if no player window was configured to display remote play-/remain times.

• Fixed a memory leak in TP-GUI. It occurred when waveforms should be displayed in the player windows instead of progress bars and when the waveform had to be generated from the original audio files because a waveform file was not referenced in the metadata of elements. This memory leak was present since version 6.0.2409.0. (CCD-43840)

• In TurboPlayerWrapper(2).dll the function GetJingleGroup did call GetTrack at the engine instead of GetJingleGroup.

New features

• Added code to the engine to calculate times for the time info windows in the GUIs. This is part of a longer project to move these calculations from the GUI to the engine. So far, the time info types “Next fixed”, “Remain time till next fixed”, “Sum of durations” and “Crossover counter” were implemented and the corresponding time info windows can be configured to make use of the times form the engine. This feature is neither complete nor fully tested. Therefore, don’t make use of it in productive environments!

• The key shortcut to move the soundhead / playout position in OTM supports the new property “SoundheadPosition" of OTM if the version of OTM is 2.9.797.0 or higher. (CCD-44002)

• Added logging output for the waveform reading of the GUI. This might help in case the waveform is not displayed sometimes. You need to activate this log output by adding the keyword “FileAccess” to the parameter: TurboPlayer\Logging\DebugLog. (Hint: this parameter and the keyword existed already, but now the generated output has been extended around the waveform reading.) (CCD-43635)

• A new parameter is available: TurboPlayer\MoveFadersAfterFaderStart. It can be set to true to achieve that TurboPlayer executes any fades in the first part of an element, which was started via fader-start. By default, this is not done. For more information, please see the parameter documentation in DigParam.rtf. (CCD-43150+43861)

Changes

• As MultiPlayer can have problems in handling fade commands, which are sent too short after a start command, TurboPlayer does now make use of the possibility to specify fade values direct with the start message for Multiplayer. This is only done for the very first fade values, for the begin part, which is defined to last until the first time when the level is no longer climbing. (CCD-44118)
  

Fixed Issues

• It could happen that TurboPlayer unloaded a show just a few second before the show should start. Now there is a protection: if the current time is in an interval of 60 seconds before and 30 seconds after a know show start, TurboPlayer does not unload any show. (CCD-44131)

• When two TurboPlayers did simultaneously run a show and a group had controls, which should be executed at the start/stop of the group, these controls were executed by both computers. Now only the first computer to start an element in a group will execute the start controls and only the computer, which has executed the start controls (or which has started the group) will execute the stop controls. (CCD-43520)

• The macro command TP_UpdateEvents() never worked. (Only the old command TP_ActualizeEvents() with the “denglish” usage of word “actualize” worked.) (CCD-44085)

• When an exception happened while handling a macro, the internal structures for macro handling were not cleaned up properly. This could lead to problems with further macro executions. Also no stack dump was written. (CCD-43288)

• DistributionEndpoints, which were defined in the global and in the local registry, were displayed twice in the corresponding combo box.

• A show was not automatically unloaded if it was the single loaded and single available show and the show metadata were changed so that the show did fall through the show filter. (CCD-43919)

• If a setting like “TurboPlayer\GUI\Windows\CFM\1” appeared in the local and in the global registry, TurboPlayer created the corresponding window twice. (CCD-43536)

• Fixed multiple problems of handling EndpointStories and play state synchronization:

  • When TurboPlayer advanced the list of loaded shows into the future, it could happen that stacks in Endpoint-mode were not loaded correctly together with the show list.

  • The synchronization of pause, restart after pause and stop worked only for the very first element of each endpoint but not for further, sequenced elements.

  • If an element in a rundown in stack mode “Endpoints” was stopped, this could cause other elements of the same EndpointStory to stop, too, though such a synchronization should work only from the master (neutral) element to a regional element.

  • Play-/remain time info in the rundown view was not displayed if no player window was configured to display remote play-/remain times.

• Fixed a memory leak in TP-GUI. It occurred when waveforms should be displayed in the player windows instead of progress bars and when the waveform had to be generated from the original audio files because a waveform file was not referenced in the metadata of elements. This memory leak was present since version 6.0.2409.0. (CCD-43840)

Changes

• As MultiPlayer can have problems in handling fade commands, which are sent too short after a start command, TurboPlayer does now make use of the possibility to specify fade values direct with the start message for Multiplayer. This is only done for the very first fade values, for the begin part, which is defined to last until the first time when the level is no longer climbing. (CCD-44118)