Media handling in regionalization setup

As there is a possibility to schedule elements from a remote site the media handling becomes important for a radio station.

As always BUS is responsible for copying the corresponding media files of scheduled elements to the primary media directory and the local caching folders of all assigned TurboPlayers.

Therefore the BUS PC needs access to the media directories of all tables in the corporate network. It then will copy the files via WAN to the primary media directory and further to the OnAir directories.

As this actions could stress the corporate network the regionaization concept includes a method to prefer material of the local system instead of copying it via the WAN. This makes e.g. sense for tables which are aligned between all regional sites.

For example tables like music, jingles or even news can be replicated using auto-replication in DigaReplicator. In such workflow all material is synchronized at all stations of the corporate network.

Now it is up to BUS to find the corresponding database entries. To have an unique identifier one of these three database fields must contain unique IDs per element:

- MusicID
- Motive
- MEDIUMNAME

In most cases content is acquired at the main station. Here at least one of these fields must be filled out with the unique identifier using typical DigaSystem rules like MusicID = RefNr!

In BUS you need to specify a File check task as normally but you need to fill out the lower part of the window. First you need to enter the path to DigaSQL.dll. Second you need to specify all tables which should be scanned. And then you can specify which classes should be handled by this method.

If now someone creates a new element in a table called Jingles in city A DigaReplicator will automatically replicate this element to all other cities. If someone in city A schedules this element for city B BUS will detect a corresponding database entry inside the local database and it will decide to copy this file instead of transferring a file via the WAN.

Port communication between local and remote TurboPlayer

Through the BCS regionalzation concept it is possible to send start commands for relative linked elements from one main TurboPlayer to one or more other locations. Therefore the main TurboPlayer must know the connected remote TurboPlayers to establish the TCP/IP communication.

This is done by adding the following parameters per connection:

Local Settings \ TurboPlayer \ Communication \ RemoteTurboPlayers \ ...

... = Name of the new connection, e.g. "TP City 2"

Parameters:

Active = TRUE
Address = IP-Address=192.168.0.1:5000
Name = displayed name of connection
PingInterval (Integer) = 5 (Keep alive ping)
Port (Integer) = 9941

For both, address and port a valid TCP/IP communication port must be present.

Both connected TurboPlayers must be configured to work on the same IP port for this communication.

Important hint: Each communication must work on a unique TCP/IP port. It is not possible to use a port for two or more communications!

By having remote TurboPlayers it is possible to trigger a slaved TurboPlayer following the main TurboPlayer regarding the selected show.

This means that a user can select another show in his master TurboPlayer. Then the remote TurboPlayers will follow this selection.

To activate this feature you need to set a parameter on all affected remote TurboPlayers:

Local Settings \ TurboPlayer : SlavedShowLoading = TRUE

The value for the master TurboPlayer can be set to FALSE. In this case it remains in the loaded show even if someone selects another show at a regional studio.