Station sort order by ID

[mxlbzn]

Currently the stations are sorted alphabetically by the station label, sort order cannot be changed.

Please allow also original sorting (by SubChId?). (Often the stations in the multiplex are ordered by the "importance". Also new stations in the multiplex would appear at the bottom, so could be easily spotted.)

I realize this might hot be desired, as the stations can be renamed by the user. So, having this id (together with 0xXXXX stationId) at least in the scan output would be nice.

[andimik]

Have you seen the favorite feature?

And regarding the scan output, the SId is part of the text file.

If you want to find it in the main window, please right click.

[JvanKatwijk]

The original sorting is an "undefined" sorting, depending on the quality of the signal. The software just collects data from the FIC, as soon as sufficient data is collected for a service (data composed from more than one element in the FIC), such that the service can be selected, the servicename is passed on to the GUI handler. Sorting was added as a suggestion - and implementation - from stuart longland (australie), Of course there are different criteria that could be used for sorting: there are two obvious criteria, alphabetically or on the serviceId, the latter probably leading to something like the "orginal order"

Op zo 16 feb. 2020 om 17:34 schreef andimik notifications@github.com:

Have you seen the favorite feature?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQFSVTNM4P4VIU5YEQTRDFTJ5A5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4LWGQ#issuecomment-586726170, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASGDOXS62Z6W6NAULRDFTJ5ANCNFSM4KWETAZA .

-- Jan van Katwijk

[JvanKatwijk]

Adding the serviceId's to the scan is not hard, you can see the serviceIds and notice that they do not necessarily form a sequence

Op zo 16 feb. 2020 om 18:04 schreef jan van katwijk <j.vankatwijk@gmail.com

:

The original sorting is an "undefined" sorting, depending on the quality of the signal. The software just collects data from the FIC, as soon as sufficient data is collected for a service (data composed from more than one element in the FIC), such that the service can be selected, the servicename is passed on to the GUI handler. Sorting was added as a suggestion - and implementation - from stuart longland (australie), Of course there are different criteria that could be used for sorting: there are two obvious criteria, alphabetically or on the serviceId, the latter probably leading to something like the "orginal order"

Op zo 16 feb. 2020 om 17:34 schreef andimik notifications@github.com:

Have you seen the favorite feature?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQFSVTNM4P4VIU5YEQTRDFTJ5A5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4LWGQ#issuecomment-586726170, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASGDOXS62Z6W6NAULRDFTJ5ANCNFSM4KWETAZA .

-- Jan van Katwijk

-- Jan van Katwijk

[JvanKatwijk]

well, if you were happier with the servicenames being unsorted, that is easy. Sorting is done on line 558 in the file radio.cpp, commenting that line out causes the names to be visible in the order that they are discovered

Op zo 16 feb. 2020 om 18:28 schreef jan van katwijk <j.vankatwijk@gmail.com

:

Adding the serviceId's to the scan is not hard, you can see the serviceIds and notice that they do not necessarily form a sequence

Op zo 16 feb. 2020 om 18:04 schreef jan van katwijk < j.vankatwijk@gmail.com>:

The original sorting is an "undefined" sorting, depending on the quality of the signal. The software just collects data from the FIC, as soon as sufficient data is collected for a service (data composed from more than one element in the FIC), such that the service can be selected, the servicename is passed on to the GUI handler. Sorting was added as a suggestion - and implementation - from stuart longland (australie), Of course there are different criteria that could be used for sorting: there are two obvious criteria, alphabetically or on the serviceId, the latter probably leading to something like the "orginal order"

Op zo 16 feb. 2020 om 17:34 schreef andimik notifications@github.com:

Have you seen the favorite feature?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQFSVTNM4P4VIU5YEQTRDFTJ5A5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4LWGQ#issuecomment-586726170, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASGDOXS62Z6W6NAULRDFTJ5ANCNFSM4KWETAZA .

-- Jan van Katwijk

-- Jan van Katwijk

-- Jan van Katwijk

[JvanKatwijk]

OK

I added two things. a. the overview of the scan now shows for each service the serviceId b. an option is to add "noSort=1" to the ini file. If set, the incoming service names are NOT sorted

Op zo 16 feb. 2020 om 18:39 schreef jan van katwijk <j.vankatwijk@gmail.com

:

well, if you were happier with the servicenames being unsorted, that is easy. Sorting is done on line 558 in the file radio.cpp, commenting that line out causes the names to be visible in the order that they are discovered

Op zo 16 feb. 2020 om 18:28 schreef jan van katwijk < j.vankatwijk@gmail.com>:

Adding the serviceId's to the scan is not hard, you can see the serviceIds and notice that they do not necessarily form a sequence

Op zo 16 feb. 2020 om 18:04 schreef jan van katwijk < j.vankatwijk@gmail.com>:

The original sorting is an "undefined" sorting, depending on the quality of the signal. The software just collects data from the FIC, as soon as sufficient data is collected for a service (data composed from more than one element in the FIC), such that the service can be selected, the servicename is passed on to the GUI handler. Sorting was added as a suggestion - and implementation - from stuart longland (australie), Of course there are different criteria that could be used for sorting: there are two obvious criteria, alphabetically or on the serviceId, the latter probably leading to something like the "orginal order"

Op zo 16 feb. 2020 om 17:34 schreef andimik notifications@github.com:

Have you seen the favorite feature?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQFSVTNM4P4VIU5YEQTRDFTJ5A5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4LWGQ#issuecomment-586726170, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASGDOXS62Z6W6NAULRDFTJ5ANCNFSM4KWETAZA .

-- Jan van Katwijk

-- Jan van Katwijk

-- Jan van Katwijk

-- Jan van Katwijk

[mxlbzn]

Configurability in the ini file is nice.

But I don't think it's very useful to have station list unsorted at all, by the (almost random?) order as it finds frames in the stream. As the sorting means alphabetical sorting, could be the behavior change to unsorted (noSort=1) to mean not alphabetically sorted, but sorted by subchannel ID ?

[JvanKatwijk]

well, it could be ordered by serviceId. Ordering by subChannelId is less attractive from an implementation point of view

Op di 18 feb. 2020 om 09:44 schreef Michal Bozon notifications@github.com:

Configurability in the ini file is nice.

But I don't think it's very useful to have station list unsorted at all, by the (almost random?) order as it finds frames in the stream. As the sorting means alphabetical sorting, could be the behavior change to unsorted (noSort=1) to mean not alphabetically sorted, but sorted by subchannel ID ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQDUKBCAG7ZVKB4T2ZDRDONXHA5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBCX2Q#issuecomment-587344874, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQAINSIFHKP4UBCZYILRDONXHANCNFSM4KWETAZA .

-- Jan van Katwijk

[andimik]

Well, please note, that sorting by SubChannel Id or SId is not sufficient for some countries.

For example, in Croatia, public broadcaster HRT has Subchannels 11, 12 and 13 (lowest is 4). They even don't have the smallest SId ...

Therefore, I suggest to use the favourite list which is useful when you can receive more than one DAB ensemble.

[JvanKatwijk]

It all depends what the purpose of the sorting is. The original idea was to ease finding by ordering the service name, which is of course a very legitimate and even helpful. The benefits of orderings based on other criteria are not clear to me yet

Op di 18 feb. 2020 om 12:57 schreef andimik notifications@github.com:

Well, please note, that sorting by SubChannel Id or SId is not sufficient for some countries.

For example, in Croatia, public broadcaster HRT has Subchannels 11, 12 and 13 (lowest is 4). They even don't have the smallest SId ...

Therefore, I suggest to use the favourite list which is useful when you can receive more than one DAB ensemble.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQD4MGM5FTYBWMNYBKLRDPEI7A5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBWPZY#issuecomment-587425767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASQC5FR2AIX4Z5ECLRDPEI7ANCNFSM4KWETAZA .

-- Jan van Katwijk

[JvanKatwijk]

This is as example the output of one of the ensembles I receive. Servicenames not ordered, What would be the benefit of having the serviceIds or the subchIds sorted?

devicename = SDRplay_RSPII_VID_1DF7&PID_3000_BUS_001_PORT_001 adding GrootNieuwsRadio serviceId 8961 subchId 15 adding 538 serviceId 83c7 subchId 1 adding 538TOP50 serviceId 8802 subchId 2 adding 100% NL serviceId 83d3 subchId 6 adding Qmusic serviceId 83c8 subchId 10 adding BNR Nieuwsradio serviceId 83d1 subchId 9 adding Qmusic non-stop serviceId 8804 subchId 4 adding Radio 10 60s&70s serviceId 8818 subchId 12 adding Sublime serviceId 82a8 subchId 13 adding Veronica serviceId 83e1 subchId 7 adding Radio Maria serviceId 8816 subchId 3 adding Sky Radio Hits serviceId 8808 subchId 16 adding KINK serviceId 8358 subchId 14 adding SLAM! serviceId 82a5 subchId 11 adding Sky Radio serviceId 83c6 subchId 5 adding Radio 10 serviceId 83d2 subchId 17

Op di 18 feb. 2020 om 13:08 schreef jan van katwijk <j.vankatwijk@gmail.com

:

It all depends what the purpose of the sorting is. The original idea was to ease finding by ordering the service name, which is of course a very legitimate and even helpful. The benefits of orderings based on other criteria are not clear to me yet

Op di 18 feb. 2020 om 12:57 schreef andimik notifications@github.com:

Well, please note, that sorting by SubChannel Id or SId is not sufficient for some countries.

For example, in Croatia, public broadcaster HRT has Subchannels 11, 12 and 13 (lowest is 4). They even don't have the smallest SId ...

Therefore, I suggest to use the favourite list which is useful when you can receive more than one DAB ensemble.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155?email_source=notifications&email_token=ACCPHQD4MGM5FTYBWMNYBKLRDPEI7A5CNFSM4KWETAZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMBWPZY#issuecomment-587425767, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASQC5FR2AIX4Z5ECLRDPEI7ANCNFSM4KWETAZA .

-- Jan van Katwijk

-- Jan van Katwijk

[mxlbzn]

I think that the serviceId could roughly corellate with radio station age. Might be useful for some. Ability to specify sort order parameter in (station name, serviceId, subchId) in config file would be great.

Current behavior, not sorting the stations by default, sucks, because the order is unstable.

[JvanKatwijk]

What would be the advantage of ordering service names according to the ServiceId compared to alphabetical ordering, that is still not clear to me

Op za 21 mrt. 2020 om 20:46 schreef Michal Bozon notifications@github.com:

I think that the serviceId could roughly corellate with radio station age. Might be useful for some. Ability to specify sort order parameter in (station name, serviceId, subchId) in config file would be great.

Current behavior, not sorting the stations by default, sucks, because the order is unstable.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155#issuecomment-602094214, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQAEMJ77TO477GL7OSLRIUKSDANCNFSM4KWETAZA .

-- Jan van Katwijk

[andimik]

In lots of countries public radio stations have the same naming structure, like Radio 1, Radio 2 and so on. This is easy when you want to zap.

But there are also countries where you cannot learn it from the name. The only way is the sorting by SId, as these IDs are similar. Of course this only happens where a DAB ensemble has public and private services on board.

Furthermore, the PI-Code in RDS and the SId in DAB have the task to distinguish between countries (1st digit) and national/regional/local (2nd digit).

But, I recommend to leave it as it is at the moment. The preset function is good enough in my opinion.

[JvanKatwijk]

If you add the line serviceOrder=1 to the ini file the sorting will be on SIds. I still do not understand what the advantage is though

[mxlbzn]

Humbly asking to reopen the issue. It was "solved" by enabling sort order by a different param. Possibility of ordering by subchannel ID is still desired.

Argumentation:

ETSI TS 103 176 (Digital Audio Broadcasting (DAB); Rules of implementation; Service information features), D.5 Sorting of the service list, states (some text strong-emphasised by me):

The sorting of the service list is implementation dependent. Various strategies may be applied for sorting. It is recommended to apply a lexicographical sorting of labels based on the character code used for display. It is essential that the sort order is independent of the character encoding used in label transmission.

The sort order of the service list should be static and consistent across ensembles. It should be predictable to the end user, so that a service can be found by its name. A receiver may provide an option to change the sorting order, e.g. from a lexicographical order top-down to bottom-up or v.v. Other than by user action, the sort order should not be changed.

The default sort order seems to be lexicographical sorting. The optional alternative sort order (serviceOrder=1) is almost globally unique, which is good. That is another type of predictable sorting.

However, the user user might expect a different kind of predictability. The qt-dab software might be used in fixed station with single local multiplex. User might not care of "globally" predictable sorting, rather want to see the stations either in the order given by the multiplex provider, and/or such that the stations newly added to the multiplex ensemble would appear at the end of the list. That newly added station would not necessarily have highest service ID (might be old station, only new in DAB; so in both current sorting methods it would appear at non-predictable position of the list), but would likely have the highest subchild ID.

An example of (linux) DAB player that uses this sorting by default is dablin(_gtk).

[JvanKatwijk]

Such a friendly request cannot be ignored, user "serviceOrder=2" for ordering on subChId's

Op wo 9 sep. 2020 om 21:24 schreef Michal Bozon notifications@github.com:

Humbly reopening the issue. It was "solved" by enabling sort order by a different param. Possibility of ordering by subchannel ID is desired, as well.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/qt-dab/issues/155#issuecomment-689767597, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQBBHLTLAMZO6SOA5RTSE7I75ANCNFSM4KWETAZA .

-- Jan van Katwijk

[mxlbzn]

It's a handy solution. Tested. Thanks.