GCC resolution: DE and DAB SId 101B results in 1e0, expected de0

[zoulou]

Hello,

I am working on integrating RadioDNS with a DAB/DAB+ Android app.

I found that the latest version ab3505d of java-CountryCodeResolver
results in an unexpected GCC result for German DAB stations, when SId starts with "1" instead of "D".

Instead of de0, the result is 1e0.

This causes that the DNS lookup fails when using gcc=1e0, but succeeds with gcc=de0.
See below for the command-line nslookup command results.

In Germany, SId with a leading "1" are quite common for private stations. 
SId of public stations start with "D" typically and these can be resolved to gcc=de0 properly.

Is this a bug in the Resolver code or countries.csv?

Thanks for any feedback on this matter.

zoulou
Maintainer of DAB-Z app on Google Play

===========================================================

nslookup -type=CNAME 0.101b.d073.1e0.dab.radiodns.org
==> Non-existent domain

nslookup -type=CNAME 0.101b.d073.de0.dab.radiodns.org
==> 0.101b.d073.de0.dab.radiodns.org        canonical name = rdns.radioplayer.de

Java source code for a unit test:

Resolver resolver = new Resolver();
resolver.setIsoCountryCode("DE");
resolver.setDabSId("101B"); // "95.5 CHARIVARI" on Ensemble="Muenchen" Eid=D073
List<Result> resultList = resolver.resolveGCC();
Result result = resultList.get(0);
assertEquals("de0", result.gcc);

org.junit.ComparisonFailure: 
Expected :de0
Actual   :1e0

===========================================================

[Andy Buckingham]

Hi zoulou,

Thanks for getting in touch.

The GCC is made up of the first nibble of the SId followed by the ECC, so if the SId of a German (ECC `e0`) service begins with `1` the correct GCC is `1e0`.

If the resolution fails (but works with `de0`) it suggests the entry for that service has been incorrectly registered by the service provider in to RadioDNS (in this case, Radioplayer.de).

To conclude, I don’t believe the library is at fault. As a representative of the RadioDNS project I’m happy to pick this up with the service provider and try and seek a resolution. I’ll be back in touch once I’ve found out more.

Thanks,

Andy.

--
--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[zoulou]

Thanks a lot, Andy. I really appreciate your efforts.

[James Cridland]

Hello, list.

I look after this part of Radioplayer and am happy to look into it for you.

James

[zoulou]

Hello James,

I checked this issue again today and now both queries fail: with de0 and 1e0

nslookup -type=CNAME 0.101b.d073.de0.dab.radiodns.org

==> Non-existent domain.

nslookup -type=CNAME 0.101b.d073.1e0.dab.radiodns.org
==> Non-existent domain.

I also used CNAME lookup tools from the web and get the same error. So, it's not a problem of my DSL router.

Maybe you could give a brief update?

Thanks,

zoulou

[Andy Buckingham]

Hi zoulou,

Just to briefly jump in on this in James’ absence - I can confirm that those entries are not present in RadioDNS.

The second example is the one that’s technically correct in terms of the first nibble of the GCC reflecting the SId and therefore, assuming it’s a genuine broadcast bearer, it would be up to the relevant service provider to request these entries be created and link to an appropriate domain.

I’ve tried looking up the FM bearer for the same service and it works as expected:

$ nslookup -type=CNAME 09550.101b.1e0.fm.radiodns.org

09550.101b.1e0.fm.radiodns.org canonical name = rdns.radioplayer.de.

This suggests it’s either a mistake or intentional decision by the service provider to not be listed.

Thanks,

Andy.

[James Cridland]

I apologise for not looking into this as quickly as I could; there are not very many tools that I have at my disposal at present to see what is available for Radioplayer Germany (who in this case look after their own data).

I've reported this, but it may need to wait for a month or so until I have a window into the data.

--

- https://podnews.net - your daily briefing for podcast and on-demand
- https://next.radio - the radio ideas conference
- https://james.crid.land - my weekly radio trends newsletter
- https://james.cridland.net - speaking and consultancy

Amazingly Brilliant Pty Ltd | ABN 30 612 913 514