´óÏó´«Ã½

We launched new functionality for the Freesat Sport Multiscreen service last week. The new service is designed so that the ´óÏó´«Ã½ Sport team can make available extra audio streams to allow you (for example) to choose between audio commentaries during a sporting event, like the Six Nations rugby. However, reports came in from call centres and online communities like that something wasn't quite right...

The updated application changed the way audio was handled for the sports streams and it seemed that some set top boxes were having difficulty with this. As user aw01949 states:

For the past week or so, I have had a problem with selecting streams from the Sport Multiscreen menu. What happens is that the video changes almost immediately but it takes two or three minutes for the audio to be acquired and for the "Please wait ..." to go away. In the meantime there is some clicking on the audio.

We couldn't reproduce the problem internally on our dedicated Freesat play out systems even on the same set top boxes that were exhibiting the problem on live broadcasts. After inspecting our code we found a potential issue. As we posted on the Digital Spy forum, here's how the system works step by step:

• When you tune to a multiscreen video (i.e. select a video from the Sport Multiscreen, page 3001), the application asks the set top box to tune to the video stream you've selected.
• Sport Multiscreen videos can potentially have a number of audio "tracks", or streams, carried along with each video.
• The application turns off the "default" audio track for the stream, which may or may not be the suggested audio track as selected by the ´óÏó´«Ã½ Sport team.
• It then reads its configuration to see what ´óÏó´«Ã½ Sport have identified as the default audio track to accompany the video.
• Then it cycles through the available audio tracks for one which matches the one chosen and enables it.
• The problem was that this cycling was taking about a minute on some set top boxes because the application couldn't find the correct audio track.

Inspecting the code logic showed that the cycling code could end up in a state where it was forever calling "get next audio" in streams that did not carry multiple audio tracks. But we couldn't recreate the excessive delay seen on live broadcasts. In-house it was taking much less than a second, meaning the cycling was still finding what it needed.

We changed the code to prevent it from performing any audio track selection operations for videos with a single audio track. This fix was released today and happily the forum users have reported it has alleviated the problem. Great news as the audio switching will be available on Freesat for Wales vs. France tomorrow night. We'll take a look at why the problem didn't get picked up before transmission — broadcasting can be pretty tricky and minor differences can cause hard to replicate problems.

I hope you enjoy the new service and thanks to awo1949, Snoods, Lengster and the fine people on the Digital Spy forums for their help. Please feel free to engage with us here, on Twitter (@´óÏó´«Ã½RedButton) and on Digital Spy forums. If there's anywhere else where people discuss the Red Button that you want to point us to, please do.

Simon Lumb is a Senior Software Engineer for the ´óÏó´«Ã½ Red Button Service

• Bookmark with:
• |
• |
• |
• |
• - What's this?