Service following on LG Stylus 2 with IRT hybrid radio app

[Ulrik Brinck]

Dear friends,
I would like to ask - has someone outside of Germany had any luck with service following from DAB+ to IP stream on Institut für Rundfunktechnik's hybrid radio app on the LG Stylus 2 smartphone?

For our DAB+ services from Kanal Plus here in Denmark I have tried to set up service following, but so far without success in the app. Unfortunately I don't have any other devices/receivers to test it on, so I don't know whether it's a problem with the app or it is me who is doing something wrong in my XSI and PI files.

If I set up a small mmbtools test transmitter in the lab, using the GCC, EId, SId and SCIds of a german radio station (I the test, I used those of SR 1 from Saarland) and tune it in on the hybrid radio app, to simulate reception of that station, and then shut the test transmitter off, the app immediately switches over to the IP stream of the real SR 1. So the service following works well for the german station in the app, but I have no luck with the same thing for our own services - and I can't figure out why.

I have created my files from the example files in the documentation on radiodns.org, and the EPG itself is working and is shown on the phone, so the DNS lookup is working and the XSI file is found. Only the service following doesn't work.

I have asked IRT's support, and they have confirmed that the app is supposed to work also outside of Germany as long as you pick your country in the app preferences.

So - has someone successfully made service following work in the app outside of Germany? And if some of you would take a look at my files and see if I'm doing something wrong, it will be much appreciated. :)

My XSI file can be found here:
http://www.kanalplus.fm/radiodns/epg/XSI.xml

And PI files of each service:
http://www.kanalplus.fm/radiodns/epg/dab/9e1/9101/9103/0/20170809_PI.xml
http://www.kanalplus.fm/radiodns/epg/dab/9e1/9101/9102/0/20170809_PI.xml
http://www.kanalplus.fm/radiodns/epg/dab/9e1/9101/910b/0/20170809_PI.xml
(if link is dead, change the date - the files are being generated and deleted automatically).

P.S. I am aware that these files are of the old standard, which is officially outdated. But IRT's app currently only supports the old standard, so that's what I'm working with right now, and I think that in the real world, a service provider will have to support both the old and the new standards anyway, to ensure compatibility with most devices. Files of the new standard are also being generated in /spi/3.1/ but have not been tested. IRT's support has informed me that a new version of the app is on it's way and will support the new standard.

Best regards,
Ulrik Brinck
Kanal Plus, Denmark.

[Alexander Erk]

Hello Ulrik,

a question would be, does the app display any of your EPG data? If no, I assume, that the base RadioDNS lookup is not working (for whatever reason). Then it would be helpful, if you could investigate the IP traffic of the app (e.g. Wireshark) to see what FQDN the app is trying to resolve and if this is sucessful. 

We are currently working on an update supporting the actual WorlDAB SPI Spec. Should be out soon.

Best regards

Alex

 

[Nick Piggott]

Hi Ulrik,

I'm on a train at the moment, so can't do a very thorough look at your XSI file, but I've noticed the stream URLs you have are to m3u playlists. Have you tried putting the direct URL to the stream in those ServiceID entries ("http://stream.kanalplus.fm/kp48")?

For note, the Samsung Galaxy handsets which support RadioDNS also use the XSI file, as they were launched pre-ETSI standard, so there is some benefit to providing both.

Nick

[Ulrik Brinck]

Dear Alexander,

 

"a question would be, does the app display any of your EPG data? If no, I assume, that the base RadioDNS lookup is not working (for whatever reason). Then it would be helpful, if you could investigate the IP traffic of the app (e.g. Wireshark) to see what FQDN the app is trying to resolve and if this is sucessful."

 

Yes, the EPG data are displayed, so the DNS lookup itself is working. Only the service following doesn't work.

 

I hooked the LG Stylus 2 up to a local DNS server in the lab, and in the logs I see that what is looked up is first 0.9103.9101.9e1.dab.radiodns.org, then _radioepg._tcp.kanalplus.fm and then www.kanalplus.fm (this is where the EPG is located), and they are all successful. It does not perform any lookup of the streaming URL domain.

 

The service following strategy is set to "Aggressive" in the app preferences.

Thanks for your help,

Ulrik.

 

 

--
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/d/optout.

[Ulrik Brinck]

Dear Nick,

Thanks for your response.

 

I actually began with direct URLs to the stream. The reason why I changed it to m3u playlists is that I saw that the german radio station, which I tested against (SR 1), were using m3u playlists, so I wanted to see if the reason why it didn't work for me was, that m3u was necessary (but no, that wasn't the solution).

 

I have changed it back to direct URLs now, but the service following still doesn't work.

 

Do you think that I should keep the direct URLs now? Is that more correct than using m3u playlists?

 

Best regards,

Ulrik.

 

 

----- Original Message -----

From: Nick Piggott

To: RadioEPG developers

Sent: Thursday, August 10, 2017 11:04 AM

Subject: Re: Service following on LG Stylus 2 with IRT hybrid radio app

[Nick Piggott (RadioDNS)]

Hi Ulrik,

How are your tests progressing? Were you able to get it to work when using direct stream URLs rather than m3u playlists?

Nick

--

Nick Piggott

Project Director

RadioDNS

www.radiodns.org // @radiodns // +44 (0) 1600 888335 // +1 (850)-888 8335

RadioDNS Limited is a not-for-profit company owned by its members, and registered in England and Wales with number 08818015. The registered office is 96a Curtain Road, LONDON, EC2A 3AA.

[Ulrik Brinck]

Hi Nick,

No, unfortunately changing to direct stream URLs did not fix the problem.

[Ulrik Brinck]

Good morning friends,

I got an idea for a new experiment:

 

* Again I made a test signal in the lab, using the GCC, EId and SId of the german radio station SR 1 and tuned in to it in the app on the phone.

* But this time I hooked the phone up to a local DNS server in the lab.

* On the local DNS server, I "spoofed" the domain 0.(blahblah).de0.dab.radiodns.org (that of SR 1) to point to kanalplus.fm instead of where it goes in the outside world.

* In my XSI file on kanalplus.fm, I changed the DAB bearer parametres to match those of SR 1. This was the ONLY thing I changed in the XSI file.

* I copied my _PI files on kanalplus.fm to a new path which matches the parametres of SR 1.

* I picked Germany instead of Denmark as my country in the app.

 

And THEN the service following worked.

 

This leads me to the conclusion, that my XSI file is in general good. Only the DAB bearer information could theoretically be wrong (it was the only thing I changed in the file for this experiment). But the fact that my EPG data are displayed in the app, confirms that the GCC, EId, SId and SCIds are as expected, so the DAB bearer information couldn't really be wrong, as I see it.

 

If the DAB bearer information is correct, I can't see any other conclusion right now, than that something must be wrong in the app.

 

Or am I overlooking something? Any comments to this?

[Nick Piggott (RadioDNS)]

Hello Ulrik,

That's a very good experiment.

I wonder if the application is constructing the GCC incorrectly?

If you are running a local DNS server (bind?), then I'd suggest putting it into verbose logging mode, resetting everything back to Denmark and your correct bearer information, and then see what queries the handset makes to the DNS server for the radiodns.org domain.

Nick

[Ulrik Brinck]

Hi Nick,

I did this recently, and in the logs of Bind, I got this:

---

11-Aug-2017 03:52:28.042 queries: info: client 192.168.1.128#61726 (0.9103.9101.9e1.dab.radiodns.org): query: 0.9103.9101.9e1.dab.radiodns.org IN CNAME + (192.168.1.98)
11-Aug-2017 03:52:32.954 queries: info: client 192.168.1.128#20157 (_radioepg._tcp.kanalplus.fm): query: _radioepg._tcp.kanalplus.fm IN SRV + (192.168.1.98)
11-Aug-2017 03:52:32.971 queries: info: client 192.168.1.128#35375 (www.kanalplus.fm): query: www.kanalplus.fm IN A + (192.168.1.98)
---

 

So, thats first: 0.9103.9101.9e1.dab.radiodns.org

Then: _radioepg._tcp.kanalplus.fm

And then: www.kanalplus.fm (this is where the EPG is located).

 

So it seems to be correct. And besides, the EPG data are displayed in the app, which also confirms that the DNS lookup must be correct.

 

But there is no lookup of the streaming URL domain in the logs, so it looks like that the app doesn't even try to do a service following. Nothing really seems to happen, when the DAB+ signal is lost.

[Nick Piggott (RadioDNS)]

Hi,

Attention casual readers: This posting refers to the OLD version of the SI document (known as XSI). The new version is called SI, and has different element names. Don't use this posting as reference for anything written to the published ETSI spec of TS 102 818 v3.1

You did say that the PI was being correctly displayed, so I guess that should have been confirmation that the SPI lookup was happening correctly, and that the GCC is correct.

The next potential issue is on matching in the <serviceID> (current spec version <bearer>) elements. The app has to:

* Enumerate through all the bearers in the XSI document

* Find the bearer that matches the service it is currently tuned to

* Find sibling bearers of that bearer

* From those sibling bearers, find those which are streaming - e.g. begin http://

* From those streaming bearers, find those which have codecs (mimeType) and bitrate that are compatible with the device

* From those compatible streaming bearers, pick the "best" one

* Connect and start streaming.

I had a look at the <serviceID> elements for SWR1-BW

<serviceID id="http://mp3-live.swr.de/swr1bw_m.m3u" mime="audio/mpeg" bitrate="128" cost="128" />

<serviceID id="http://mp3-live.swr.de/swr1bw_s.m3u" mime="audio/mpeg" bitrate="64" cost="64" />

I notice that they're both MPEG streams. In your XSI:

<serviceID id="http://stream.dbmedia.se/kp48" mime="audio/aacp" bitrate="48" cost="48"/>

<serviceID id="http://stream.dbmedia.se/kp96" mime="audio/aacp" bitrate="96" cost="96"/>

<serviceID id="http://stream.dbmedia.se/kp128" mime="audio/mpeg" bitrate="128" cost="128"/>

Your lowest cost (most preferred bearers) are AAC bearers. Have you tried putting just the MPEG bearer in, by itself? Also, without wanting to be seriously picky (but parsers can be), the IRT element closing is " /> and yours is "/> (no space before the backslash). That might be worth trying as a change too.

Nick

[Ulrik Brinck]

Thank you, Nick.

The space before the slash in the element closing is already present in my XSI file, but in my browser (Firefox), the space is not shown, until I do a "View source". Perhaps it's the same in your browser?

 

I have now removed all AAC stream bearers from the XSI file, but that didn't help. Service following is still not working. :-(

[Nick Piggott (RadioDNS)]

Then I am stumped. I'd just have to guess that the bearer matching isn't happening correctly, so the app isn't finding the stream URL for your station. If you're not even seeing an attempt to resolve the stream host domain on DNS, then it looks like the app isn't even trying to open it.

Alex - any thoughts?

Nick