search

JvanKatwijk / dab-cmdline

DAB decoding library with example of its use
GNU General Public License v2.0
57 stars 29 forks source link

fix listing of audio/data programs #69

Closed hayguen closed 4 years ago

hayguen commented 4 years ago

Signed-off-by: hayati ayguen h_ayguen@web.de

JvanKatwijk commented 4 years ago

what is the problem? Are there more than 5 subchannels active?

Op do 11 jun. 2020 om 23:27 schreef hayati ayguen <notifications@github.com

:

  • the SCIds can be 0 .. 15, as the number comes from SCIds = getBits_4() in fib-decoder.cpp line 791 (HandleFIG0Extension8)
  • in older version (my clone), componentNr was used when looking for that data e.g. with dataforPacketService(), but that was also from getBits_4()
  • problem was reported from andimik

Signed-off-by: hayati ayguen h_ayguen@web.de

You can view, comment on, or merge this pull request online at:

https://github.com/JvanKatwijk/dab-cmdline/pull/69 Commit Summary

  • fix listing of audio/data programs

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/dab-cmdline/pull/69, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQASFRLK3LWFPEYEF5TRWFD37ANCNFSM4N3YXT6Q .

-- Jan van Katwijk

andimik commented 4 years ago

BTW: This fix did not solve, what I have reported.

I have to investigate which tool really causes the issue.

JvanKatwijk commented 4 years ago

What is the issue?

Op vr 12 jun. 2020 om 12:26 schreef andimik notifications@github.com:

BTW: This fix did not solve, what I have reported.

I have to investigate which tool really causes the issue.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/dab-cmdline/pull/69#issuecomment-643198730, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQAPJADUBNQQLDLUA7TRWH7FZANCNFSM4N3YXT6Q .

-- Jan van Katwijk

andimik commented 4 years ago

A data service (SPI, formerly called EPG) was only detected in around 40% of all scans of the same Mux.

I personally think that the problem has to be solved in one of the forks, not in your repository.

JvanKatwijk commented 4 years ago

can you send a link to a recording of the mux

Op vr 12 jun. 2020 om 16:01 schreef andimik notifications@github.com:

A data service (SPI, formerly called EPG) was only detected in around 40% of all scans of the same Mux.

I personally think that the problem has to be solved in one of the forks, not in your repository.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/dab-cmdline/pull/69#issuecomment-643286052, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQFPO2INGGERH3ZJY2DRWIYKRANCNFSM4N3YXT6Q .

-- Jan van Katwijk

hayguen commented 4 years ago

Hi Jan,

regarding "what is the problem? Are there more than 5 subchannels active?":

the problem is/was, that my fork reported a program name (for a data channel) through programnameHandler(), which was later not listed in the CSV file. unfortunately i just got the log files. there is no recording - for now. with a deeper look the only way to explain this (for me) is that the componentNr value might be bigger than 5 - despite the amount/number of components might be smaller.

from my point of view, the same error might happen with your modified code using "SCIds" - instead of componentNr.

with some luck, we'll get an RF recording from Andreas ..

regards, Hayati

andimik commented 4 years ago

Dear Hayati and Jan,

At the bottom there is a link (valid for one week) to a 100MB (= 25 seconds) 7zip raw file and a 4 minute eti-file of Austria's nationwide mux containing 10 audio and 1 data service. The latter is not found in approx. 40% of all scans with a fork of your repository (see https://github.com/hayguen/fmlist_scan and https://github.com/hayguen/dab-cmdline ).

Jan: Your tools (including Qt-DAB) always detect it.

I've checked with https://github.com/Opendigitalradio/etisnoop how often several labels appear in this eti file: (Remark: I had to look for a long label, otherwise it counts the short label as well)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep Mein -c
[...]
1069

(Audio Service Mein Kinderradio)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep ORS -c
[...]
1069

(ORS EPG Data service = SPI)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep Technikum -c
[...]
1069

(Audio Service Technikum ONE)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep Austria -c
[...]
1069

(Ensemble label DAB+ Austria)

So the data service appears exact the same times as the audio service in the eti. But the fork does not detect it each time.

So I fear it has nothing to do with Jan's tools.

dab-files and Qt-DAB always detects the data service.

grafik

$ dab-files -F /tmp/austria_ors.raw 
dab_cmdline example-10 V 1.0alfa,
                      Copyright 2018 Hayati Ayguen/Jan van Katwijk
opt = F
try to open '/tmp/austria_ors.raw' as wavFile ..
file /tmp/austria_ors.raw no legitimate sound file
allocating wave device failed (24), fatal
try to open '/tmp/austria_ors.raw' as rawFile ..
sound file '/tmp/austria_ors.raw' opened with/as raw device

  192: starting DAB processing ..
Period = 16000

  248: ensembleIdHandler: ensemble (EId A101) is recognized

programnameHandler: '* 88.6 *        ' (SId AC47) is part of the ensemble
programnameHandler: 'ARABELLA RELAX  ' (SId AD54) is part of the ensemble
programnameHandler: 'KLASSIK RADIO   ' (SId AD53) is part of the ensemble
programnameHandler: 'ENERGY          ' (SId AC51) is part of the ensemble
programnameHandler: 'R.Maria         ' (SId A3DD) is part of the ensemble
programnameHandler: 'Mein Kinderradio' (SId AD55) is part of the ensemble
programnameHandler: 'ERF Plus        ' (SId AD24) is part of the ensemble
programnameHandler: 'Technikum ONE   ' (SId AD2A) is part of the ensemble
programnameHandler: 'Rock Antenne    ' (SId AD27) is part of the ensemble
programnameHandler: 'jö.live         ' (SId AD56) is part of the ensemble
programnameHandler: 'EPG ORS          (data)' (SId E0A0AD50) is part of the ensemble

  439: ensemblenameHandler: 'DAB+ Austria    ' ensemble (EId A101) is recognized

^CSignal caught, terminating!
tii, 801, 10

https://we.tl/t-6dL9pJCh5c

andimik commented 4 years ago

And this is the output after pressing the "content" button in Qt-DAB:

DAB+ Austria    ; ensembleId A101; channel 8A; frequency 0; time of recording  2020-jun-14 10:49

Audio services
program name;country;serviceId;subchannelId;start address;length (CU); bit rate;DAB/DAB+; prot level; code rate; language; program type

* 88.6 *        ;Austria;AC47;5;228;54;72;DAB+;EEP 3-A;1/2;unknown language;Rock Music;
ARABELLA RELAX  ;Austria;AD54;0;0;54;72;DAB+;EEP 3-A;1/2;unknown language;Pop Music;
ENERGY          ;Austria;AC51;2;108;54;72;DAB+;EEP 3-A;1/2;unknown language;Pop Music;
ERF Plus        ;Austria;AD24;8;396;30;40;DAB+;EEP 3-A;1/2;unknown language;Religion;
KLASSIK RADIO   ;Austria;AD53;11;426;54;72;DAB+;EEP 3-A;1/2;unknown language;Light Classical;
Mein Kinderradio;Austria;AD55;12;480;30;40;DAB+;EEP 3-A;1/2;unknown language;Children's;
R.Maria         ;Austria;A3DD;1;54;54;72;DAB+;EEP 3-A;1/2;unknown language;Religion;
Rock Antenne    ;Austria;AD27;6;282;54;72;DAB+;EEP 3-A;1/2;unknown language;Rock Music;
Technikum ONE   ;Austria;AD2A;7;336;60;80;DAB+;EEP 3-A;1/2;unknown language;Pop Music;
jö.live         ;Austria;AD56;3;162;54;72;DAB+;EEP 3-A;1/2;unknown language;Pop Music;

Data Services
program name;;serviceId;subchannelId;start address;length (CU); bit rate; FEC; prot level; appType ; subService ; 

EPG ORS         ;Austria;E0A0AD50;4;216;12;16;0;EEP 3-A;7;no;;
JvanKatwijk commented 4 years ago

The EPG service is just an ordinary data service - no subservice - and - as andimik said - visible in the output of Qt-DAB and dab-cmdline. If it is not visible in the output of the fork, then something might be wrong with the handling of FIG0/3

Op zo 14 jun. 2020 om 15:46 schreef andimik notifications@github.com:

Dear Hayati and Jan,

At the bottom there is a link (valid for one week) to a 100MB (= 25 seconds) 7zip raw file and a 4 minute eti-file of Austria's nationwide mux containing 10 audio and 1 data service. The latter is not found in approx. 40% of all scans with a fork of your repository (see https://github.com/hayguen/fmlist_scan and https://github.com/hayguen/dab-cmdline ).

Jan: Your tools (including Qt-DAB) always detect it.

I've checked with https://github.com/Opendigitalradio/etisnoop how often several labels appear in this eti file: (Remark: I had to look for a long label, otherwise it counts the short label as well)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep Mein -c

[...]

1069

(Audio Service Mein Kinderradio)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep ORS -c

[...]

1069

(ORS EPG Data service = SPI)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep Technikum -c

[...]

1069

(Audio Service Technikum ONE)

$ etisnoop -i ors_8a_2020-06-14_1052.eti | grep Austria -c

[...]

1069

(Ensemble label DAB+ Austria)

So the data service appears exact the same times as the audio service in the eti. But the fork does not detect it each time.

So I fear it has nothing to do with Jan's tools.

dab-files and Qt-DAB always detects the data service.

[image: grafik] https://user-images.githubusercontent.com/24510556/84595014-f8edab00-ae55-11ea-8d9a-a45437e5abbe.png

$ dab-files -F /tmp/austria_ors.raw

dab_cmdline example-10 V 1.0alfa,

                Copyright 2018 Hayati Ayguen/Jan van Katwijk

opt = F

try to open '/tmp/austria_ors.raw' as wavFile ..

file /tmp/austria_ors.raw no legitimate sound file

allocating wave device failed (24), fatal

try to open '/tmp/austria_ors.raw' as rawFile ..

sound file '/tmp/austria_ors.raw' opened with/as raw device

192: starting DAB processing ..

Period = 16000

248: ensembleIdHandler: ensemble (EId A101) is recognized

programnameHandler: ' 88.6 ' (SId AC47) is part of the ensemble

programnameHandler: 'ARABELLA RELAX ' (SId AD54) is part of the ensemble

programnameHandler: 'KLASSIK RADIO ' (SId AD53) is part of the ensemble

programnameHandler: 'ENERGY ' (SId AC51) is part of the ensemble

programnameHandler: 'R.Maria ' (SId A3DD) is part of the ensemble

programnameHandler: 'Mein Kinderradio' (SId AD55) is part of the ensemble

programnameHandler: 'ERF Plus ' (SId AD24) is part of the ensemble

programnameHandler: 'Technikum ONE ' (SId AD2A) is part of the ensemble

programnameHandler: 'Rock Antenne ' (SId AD27) is part of the ensemble

programnameHandler: 'jö.live ' (SId AD56) is part of the ensemble

programnameHandler: 'EPG ORS (data)' (SId E0A0AD50) is part of the ensemble

439: ensemblenameHandler: 'DAB+ Austria ' ensemble (EId A101) is recognized

^CSignal caught, terminating!

tii, 801, 10

https://we.tl/t-6dL9pJCh5c

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/dab-cmdline/pull/69#issuecomment-643768851, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQFZGIO7JNJBO66B2U3RWTIEFANCNFSM4N3YXT6Q .

-- Jan van Katwijk

hayguen commented 4 years ago

@JvanKatwijk: with the test file, i could reproduce and fix the error in my fork: in fib_processor::bind_packetService() you had a check if the serviceLabel is already there .. and changed this check in your version .. to use an ensembleDescriptor class.

however, in scanning mode collecting data for a few seconds, the packet data always got rejected, despite already gotten reported with programnameHandler()! thus, is_dataService() reported false in main() when listing/printing all services ..

unfortunately, it's impossible to track your changes to update my sources: there are too many changes. if there would be a chance, that you accept pull requests (especially the tii code) .. i would invest the time to update everything ..

the initial pull request 69 might be relevant for some other problem .. at least in theory

@andimik: would you test my latest version - including the bugfix?

JvanKatwijk commented 4 years ago

The "original" TII code is still part of dab-cmdline, however, I do not want to change the API for normal use, so the code

I would not mind updating that code

Op zo 14 jun. 2020 om 22:36 schreef hayati ayguen <notifications@github.com

:

@JvanKatwijk https://github.com/JvanKatwijk: with the test file, i could reproduce and fix the error in my fork: in fib_processor::bind_packetService() you had a check if the serviceLabel is already there .. and changed this check in your version .. to use an ensembleDescriptor class.

however, in scanning mode collecting data for a few seconds, the packet data always got rejected, despite already gotten reported with programnameHandler()! thus, is_dataService() reported false in main() when listing/printing all services ..

unfortunately, it's impossible to track your changes to update my sources: there are too many changes. if there would be a chance, that you accept pull requests (especially the tii code) .. i would invest the time to update everything ..

the initial pull request 69 might be relevant for some other problem .. at least in theory

@andimik https://github.com/andimik: would you test my latest version - including the bugfix?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/JvanKatwijk/dab-cmdline/pull/69#issuecomment-643818909, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCPHQBLBS2SEGHM6F5R2UTRWUYE5ANCNFSM4N3YXT6Q .

-- Jan van Katwijk

andimik commented 4 years ago

@hayguen

I've tested it and already replied per mail.

Still buggy (= not 100% reliable), but lot of improvement so far.

JvanKatwijk commented 4 years ago

I just ran a test and with a small mod to the code to set parameters for the sdrplay, example 10, i.e. the example with your additions, works fine. So, if you have suggestions to "improve" your additions, feel free to suggest. One comment: FIG 0/22 is obsolete, so the FIG's do not carry information on the transmitter identification anymore

hayguen commented 4 years ago

Hi Jan, i could reproduce the error with the hint from andimik. i'll have a look, if i can find/fix the concrete error. Else, i tend to "rebase" onto your version/master branch, what could result in more benefits/fixes. However, cause of the divergence and my lack of time, this will take me some time. Some other ideas to consider/apply before doing that "rebase":

these are just ideas. but before doing a "rebase", in fact a rewrite of my changes, we should consider these first. what do you think?

hayguen commented 4 years ago

think i found the initial problem on my side: bind_audioService() is checking for same SId in addition to componentNr before assuming, that ServiceComps[] is already registered, and returning from bind_audioService(). bind_packetService() wasn't cheking for the same SId and it could erroneously assume having the ServiceComp[] - but NOT having it.

now checked your (Jan) version of bind_packetService(): you also return with checking

    for (i = 0; i < 64; i ++) {
       if (base -> serviceComps [i]. inUse)
          if (base -> serviceComps [i]. SCId == SCId)
             return;
    ..

without comparing against int serviceIndex = setServiceIndex (SId)

JvanKatwijk commented 4 years ago

You are looking at the wrong file. OK, in both systems (qt-dab and the library), the basic idea is that the SId element should be present, with a name, before we react on a request to bind_package. If the SId is defined and the service component is not, then it is defined