Service Names and Component Names

[jpuigs]

I've found a small bug.

I noticed that on all home & car receivers I have, some stations long names (16 char) are different from the ones that abracaDABra shows. On DAB/DAB+ programs, Audio Service has a name, and Audio Component may have or not have a name. Receivers have to look wether Audio Component has name or not, and if Audio Component has one, they have to show it, and if Audio Component has no name, they have to show the "main" name from Audio Service.

AbracaDABra always shows the Audio Service Name. It should show the component name when it's available.

On AbracaDABra ensemble info, the Service and the Component names are always the same ones, and that's the bug. Here an example:

Red (service name) and Orange (Component name) are equal, but they are not really equal. If you look at radio receiver, or you look at other PC programs like DAB Player, you'll see that names are different.

Here you have a DAB Player ensemble information, as you'll see, it shows the differences that AbracaDABra doesn't (orange Component name)

---

AbracaDABra:

Component name is not shown anywhere.

---

DAB Player:

So, please, would it be possible to fix the ensemble information to show correct service and component names everywhere ? And show component name (where available) instead of Service name in main app.

Thanks,

[KejPi]

Thank you for reporting. This is actually the first time I see the primary service component to have dedicated name. I am glad that I have a test case for that and I will fix it in next version.

[KejPi]

I was checking the implementation and it is done this way intentionally because 2.1.1 standard from 2017 does not permit to broadcast primary service component name:

Since this change could have some unwanted side effects, I have decided not to change current implementation at the moment.

[jpuigs]

OK, I understand that what is shown on the program list is OK, but inside the enseble information it should appear. It should appear what is transmitted....

[jpuigs]

I remembered to have seen this In the UK............

https://assets.publishing.service.gov.uk/media/5a7adfe9ed915d71db8b3166/Domestic_Min__Spec.pdf

[jpuigs]

BBC in the UK, has 2 channels with 2 components.

If you always look names at service label and not on component label (if exist), you'll be listening to Parliament, and program label will be BBC Radio 4

[KejPi]

Where this comes from? My quote was taken from ETSI EN 300 401 V2.1.1 (2017-01) http://www.etsi.org/deliver/etsi_en/300400_300499/300401/02.01.01_60/en_300401v020101p.pdf

Component label is shown, but only for secondary services that shall have label unlike primary services.

[jpuigs]

OK, Ok, I know you do it correctly. But, I repeat, although program behaviour is correctly according to ETSI standards, when we look at ensemble information, we would have to see correct component labels names, where they appear. So, red and orange labels should appear different, as they are really transmitted different in this station and others,

Only here, in ensemble information .

It should not be transmitted ? Of course, It shouldn't. But as it is, we should see it exactly what is transmitted..... just for own information.

[KejPi]

I understand your point but at the moment it is not possible without side effects. The decoder is designed to be compliant with latest DAB standard so it does not consider primary service component labels. It is not a problem to decode it, after all it is label like any other - in fact it is already decoded - the problem is that at the time the service list is read from decoder it may not be available and thus the service list loading would need to be redesigned and would always take longer just to support single case. The other option would be to implement labels update functionality, that is in my TODO list, but with very low priority at the moment.

[KejPi]

Let's keep this issue open as TODO reminder like #9