WideOrbit Integration Troubleshooting - for Futuri Mobile & Tether

WideOrbit did not delete the losing songs in my "UPick"-style voting session.

There are several possible causes for this:

• The session was changed after it opened - If something in the voting session was changed after the UPickStart played, there is a good chance that the losing songs will not be deleted correctly. We would advise not changing anything in between the LDR Vote Options Start and LDR Vote Options End if the UPickStart has already played.
• The UPickStart did not play - If this earlier Memo was skipped or deleted before it could play, the voting session would never have opened, and therefore Echo would not have made an attempt to delete the losing songs.
• There is a timing issue between the Echo PC, the CS, and the studio PC - It is possible that if these computers are out of sync, Echo will attempt to delete the losing songs, but do it too late. Make sure that something is in place to keep these computers' times synced as closely as possible.
• WideOrbit is in Manual mode - In order for the automatic song deletion to work properly, we would recommend keeping WideOrbit in Auto mode during voting sessions.
• An event within 60 seconds before the LDR Vote Options Start was segued out or synced out at the last moment - See below for more info on this.

By default, Echo is configured to delete the losing songs 30-60 seconds before the end of the voting session. This is based on the schedule that we receive periodically from WideOrbit's API. If the schedule changes at the last moment, Echo may not receive that change fast enough to react. The most common reasons for this include segueing out of an element early (for example, a 2-minute music bed that is played for 30 seconds and then segued out of) or placing the winning song too close to a TOH sync command.

If this becomes a recurring issue on your station, there are some steps that can be taken to prevent it:

• In Echo's wideorbit.xml file, you can adjust the XML. The default values are 30 and 60, and when stations want to adjust for this particular issue, we typically suggest lowering the minimum to 5. Echo will still try to delete the losers 60 seconds ahead of time, but it will continue to make an attempt if it suddenly finds out that it has at least 5 seconds to react.
• When you make the change above, the element that plays before the LDR Vote Options Start should be at least 1 second longer than the value and should NEVER be segued early or synced out. For example, if that value is set for 5 seconds, the preceding audio should be 6 seconds or longer. That way, the worst-case scenario is that the losing songs will be deleted when that piece of audio starts to play. A practical example of this would be executing your TOH sync, then playing a 6-second Legal ID as a buffer, and then playing the winner after that.

WideOrbit is not inserting winning songs in my Top Song, Takeover, or FaceOff sessions.

There are several possible causes for this:

• The winning song does not exist or is invalid - Futuri VIP Support can help you confirm whether this is the case. If so, you may want to review the song choices available in the voting window to make sure they're all still active in WideOrbit.
• There is a timing issue between the Echo PC, the CS, and the studio PC - It is possible that if these computers are out of sync, Echo will attempt to delete the losing songs but do it too late. Make sure that something is in place to keep these computers' times synced as closely as possible.
• WideOrbit is in Manual mode - In order for the automatic song insertion to work properly, we would recommend keeping WideOrbit in Auto mode during Top Song, Takeover, and/or FaceOff.
• An event within 60 seconds before the Empty Song Slot was segued out or synced out at the last moment - See below for more info on this.

By default, Echo is configured to insert winning songs 30-60 seconds before the Empty Song Slot. This is based on the schedule that we receive periodically from WideOrbit's API. If the schedule changes at the last moment, Echo may not receive that change fast enough to react. The most common reasons for this include segueing out of an element early (for example, a 2-minute music bed that is played for 30 seconds and then segued out of) and placing the winning song too close to a TOH sync command.

If this becomes a recurring issue on your station, there are some steps that can be taken to prevent it:

• In Echo's wideorbit.xml file, you can adjust the XML. The default values are 30 and 60, and when stations want to adjust for this particular issue, we typically suggest lowering the minimum to 5. Echo will still try to insert songs 60 seconds ahead of time, but it will continue to make an attempt if it suddenly finds out that it has at least 5 seconds to react.
• The element that plays before the Empty Song Slot should be at least 1 second longer than the value and should NEVER be segued early or synced out. For example, if that value is set for 5 seconds, the preceding audio should be 6 seconds or longer. That way, the worst-case scenario is that the winning song will be inserted when that piece of audio starts to play. A practical example of this would be executing your TOH sync, then playing a 6-second Legal ID as a buffer, and then playing the winner after that.

I received an email from Futuri VIP Support saying "No Logs Received."

If you use Top Song, Takeover, or FaceOff, your music logs are used for forward separation (to make sure we don't insert a song into WideOrbit that is already pre-scheduled).

For all stations, music logs also help us to send listener alerts BEFORE users' requests play on air (so they have time to turn on the radio).

If you receive a "No Logs Received" email from Futuri VIP Support, here are some suggestions to fix the problem:

• Confirm that Echo is running.
• Navigate in Echo to WideOrbit > Send Schedule to LDR > Today (or Tomorrow, if you are trying to send tomorrow's log).
• It is normal to see some benign errors right after sending a schedule, but Futuri VIP Support can confirm whether the log was uploaded successfully.