Most of today’s automation systems will output metadata with the current on-air event and some will also send a few next events. When next events are available they are used to pre-stage artwork for digital receivers, web sites, and streaming services, etc.
There are 3 conditions for capturing and posting metadata. Communications (how is the metadata received), the format (what does the data look like) and filtering (how are the events defined). When all 3 conditions are met the correct metadata will be formatted and posted as required.
There are 3 options for capturing metadata from automation systems and satellite services IP, Serial or via a metadata file.
To configure the system for an IP link we configure the automation system to send the metadata to the IP of the CSRDS computer and select the port. We then configure CSRDS with the IP of the automation system using the same port assigned in the automation system. This is usually a TCP/IP connection where one PC is the “server” and all other PC’s are the Client. It does not matter which PC is the server as long as one is set as the server. As the server, the application opens the selected port and “listens” for a connection request. When received the link is established and both systems can send and receive data. In most cases the automation system is the server so CSRDS defaults as the Client. In a few cases like the NextGen the automation system is the client so we need to set the “Input Source is the Client” in the CSRDS configuration and CSRDS becomes the server.
The most common issues with the TCP/IP method is establishing the link. The computers must be on the same network or routed so we often use dual NIC cards. We also need to ensure the port is used by another application or blocked by the PC’s security, Network Permissions, group policies, etc. We can establish the ability to communicate using the Windows “Ping” command but even if we can Ping the PC the port may still be an issue blocking the communication. This most often generates a “Forcefully” rejected error when CSRDS tries to connect to the IP and Port.
Since this can be a normal situation as computers are re-booted or when windows updates are applied, CSRDS has a number of built in error trapping routines that will monitor the connection and will automatically reconnect when the system is available. However, in some cases an error is not generated so data stops coming. As a workaround for dropped connections, we can set the persistent connection option in CSRDS. Once set, if we do not receive data for an extended period the connection is reset.
Some older systems and most satellite feeds use a serial connection to output now playing data. Most automation systems have opted for IP or creating a metadata File. However, most satellite services still provide metadata via the serial port on the satellite receiver. As most computers no longer have a serial port we can either add an after market Serial Card or opt for a USB to serial connector. If using a USB to Serial connector we should select a high end unit with drivers designed for the O/S we are using. Issues can be difficult to trace as temporary communications work fine but we need a reliable connection that will monitor the system and receive data every few minutes 24×7.
The file method is often the most reliable as it is not subject to the same network issues as IP or Serial. When using the file method it is recommended to configure the on-air PC to create the file in a special read only shared directory on the on-air PC where the login user on the CSRDS computer can access the file. Placing the file on the on-air PC can eliminate on-air issues if there are network issues. Regardless of the method CSRDS is a read only application that captured data from the automation system but does not send data back so the security can be maintained regardless of the communications method.
Unfortunately there are no standards for how metadata should be formatted for use in data casting and some systems provide everything but the kitchen sink while others may be as little as artist and title. When configuring CSRDS we have a number of options that are named for the automation system normally associated with a specific format. However, if you have an automation system with a user definable format we can configure for one of the supported formats and select that system. In other words the selected system tells CSRDS where to look for the information within the metadata feed. When configuring a metadata format the key items are the Artist Name, Song Title, Duration, Cart/CutID, and Type (Category) of event and status (playing or in the queue). Automation systems often send a lot of information we do not want such as voice tracks, legal ID’s, Promos, PSA’s, etc. To filter these out we simply tell CSRDS what “categories” are music and commercial and CSRDS will ignore the rest. If the stations has HD Radio and doing the Artist Experience, it is helpful to have up to the next 5 events. When available, CSRDS will pre-stage the artwork for the next song while the current song is playing so it shows within a few seconds of starting.
There are so many different automation systems all with there own formats and some user definable formats we have included a generic option that will scan the metadata for the common tags to get the information. If we can find enough usable data the metadata will be posted.
In addition to automation systems and satellite services that support live Now Playing metadata we also capture metadata from other sources such as Web Services like PRSS’s MetaPub, NPR’s Composer or other sites with live now playing data or a play list (metadata log) which we download and link to our CSRAS (Radio Automation Simulator) application that imports the play list and sends metadata to CSRDS based on the schedule. The suite also includes our CSLogIt application with the tools to post now playing data on-the-fly, preload a song list to send if a song si played or to create a play list (metadata log) for CSRAS.