Practical considerations for Hybrid Radio

[Ben Poor]

Dear All,

I'd like to follow through a thought experiment and draw upon your various experiences, in order to check we've got the right tools in the RadioEPG specification.

Take a theoretical Hybrid Radio with the ability to receive Broadcast (FM, DAB, etc.) and IP. This radio periodically scans the Broadcast bands in order to 'discover' stations, presenting the stations in a unified station list to the user.

In UK and Mainland Europe you may expect there to be around 15-20 FM stations. On DAB in the UK you can have 50 stations available. In the US, you may have 40 FM stations.

For each of these stations, a device may use the Broadcast Parameters and perform a RadioDNS lookup to discover an available RadioEPG service. This would result in an XSI file for each station.

This may then result in a fair number of XSI files to retrieve/ingest - lets say a list of 64 stations on FM and a digital bearer. What challenges does this present for a device? I'm thinking static devices like a desktop radio, as well as more mobile ones such as a smartphone, or car radio. We need to consider whether we're  making fair expectations on devices, as well as ensuring the process is simple and easy for Broadcasters to provide at a range of technical levels.

Like anything, the process can be optimised, so starting off with the prospect of having to retrieve/ingest 64 large XSI documents, let me raise some things in the specification I think will reduce this number:

1. Multiple stations from the same provider

Sometimes, multiple stations in a territory will be provided by the same group. For example, in the UK you may expect a majority of the stations on a scan to be provided by a few big commercial companies (Global, Bauer, etc.) and the public service broadcaster (BBC).

This is largely dependant on how the Broadcaster arranges its RadioEPG services, but for Global, the XSI URL for Classic FM (national) is the same as any of the local Heart and Capital stations, and regional DAB services. 

Thus, retrieving the XSI for any of the Global stations would mean the device would not need to retrieve/ingest additional XSI documents for subsequent stations from Global.

This would either be by recognising that the bearers from multiple stations all resolve to the same XSI document URL, or by matching up bearers contained in an XSI file with the list of scanned bearers to be resolved.

2. Compressing XSI files

The XSI for Global is reasonably comprehensive at 300Kb, but compresses to a more manageable 13Kb. This can be read and (correct me if I'm wrong) inflated and read in as an XML stream without requiring a device to hold the entire document in memory. Each service could then be stored in a more memory-efficient format on the device. 

3. Bearer Filtering

When making an XSI request, bearer information can be optionally supplied in the querystring (as given in Section 3.4 of the RadioEPG Specification. This allows for a Broadcaster to send a more appropriate XSI document to the device. This could be a subset of the more complete XSI and contain just the details for that station.

This is by no means a complete list, and there are also various suggestions floating around for different ways in which the specification can be adjusted to ensure that we still allow devices with resource limitations to keep pace with the level of metadata. 

I'd like to hear any ideas or suggestions you have - or any comments on my suggestions above. I would particularly like input from Device Manufacturers, across a range of device types. The RadioEPG group strives to create a specification that allows devices and Broadcaster and aggregators of all sizes to participate effectively. Feel free to reply to this, or contact me privately.

My next step will be to create a whitepaper for wider discussion containing some more developed scenarios.

Ben

[Robin Cooksey]

Hi Ben,

 

When experimenting with RadioEPG device-side implementations, we’ve taken an approach similar to the one you describe.  I.e., we construct a list of bearer URIs, representing services we can currently see.

We then perform RadioDNS lookups, and retrieve the XSI document for the first URI in the list.  Each time we retrieve an XSI document, we process it, and remove each bearer URI that we find in it from the list – and update our details for each service.

In this way, we should only request each XSI document once – provided that the XSI document does actually contain all of the bearers that resolve to it.

 

Also, I think you’re right – that it should be possible to decompress and parse the EPG XML as a stream – without needing to have the entire file in memory at once.

 

Best regards,

Robin

 

 

--
You received this message because you are subscribed to the Google Groups "RadioEPG developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioepg-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ben Poor]

Hi Robin,

Many thanks for that, its good to know the theory is useful in practice! In various conversations over the last few weeks, the same process has come up, so it seems we're not the only ones to have arisen at this solution.

Its probably also the worse case situation to have to sift through a list of XSI documents, being most applicable on initial tuner scan where no cached services exist.

Ben