Understanding Problem & Scan available?

[MkMunich]

Hi Jan,
I do not yet understand the architecture. May you please give me a hint how it works? How is the data flow of the stream(s) coming from e.g. the DVB-T stick (including audio, program information, gifs, ...)? Are there perhaps daemons needed running in background to process the data streams?

Is there an option instead issuing commands to the DBV-T stick to perform a scan to find all radio stations (I'm mainly interested in DAB+, but FM may be an option?) and to store the available stations in a text file? This would allow new commands to be implemented like:
-scan
-P n (where n is the n th Program found in the radio station list file)

Best Regards

[andimik]

I'm pretty sure, users who installed qt-dab or other tools know what channels and services they are able to receive and may own DAB radios as well.

[MkMunich]

Thanks for the quick response.
You're right ;-) but this was not my point. I'm sorry about my bad English. I'll try it again:

I do not understand, how dab_cmdline is finally playing radio on my Rpi 3. The "Callbacks" are strange to me: Do I need more applications to get a sound and dab+ information?

As dab_cmdline is coming with no GUI (this is exactly, I'm looking for) I would like to use dab_cmdline in RasPiCar, which is a Kodi (Python) application. With a car, there is a need to scan the radio stations more often than at home, because of driving around.
When using dab_cmdline with Python interface, RasPiCar would need a list of available radio stations. Having this list, it would then use dab_cmdline to tune the radio station. My question is, where this radio station list is coming from. I had in mind, that a scan was already present in qt_dab and so I suggested a new 'scan' command in dab_cmdline. But of course, the list can also be created by a separate tool ;-)

[JvanKatwijk]

The command line version does not scan. It is tuned to a given channel and extract the data from that channel. If there is no data found within a reasonable amount of time, the software will halt. If an ensemble is found, the program names are displayed. The Python interface is just to experiment a little with Python. DAB handling software is made into a library, i.e. something that has to be controlled from elsewhere. The callbacks connect the library output to the command line handler, GUI or whatever is used to control the library, Both the C++ command line version and the Python version have implementations for relevant callbacks, In the end a lot of data is sent back from the library to the controlling software: obviously sound samples, but also the program names in the ensemble, the dynamic label (i.e. messages encoded in the sound), some signal and data quality indicators et etc. The scanning as implemented in Qt DAB searches for the next channel in the selected band that contains DAB data, it does not search for all channels and all stations. If there is sufficient interest then I might look at a scanning function in the cmd line version. best jan 2017-04-04 12:21 GMT+02:00 MkMunich <notifications@github.com>:

…

Thanks for the quick response. You're right ;-) but this was not my point. I'm sorry about my bad English. I'll try it again: I do not understand, how dab_cmdline is finally playing radio on my Rpi 3. The "Callbacks" are strange to me: Do I need more applications to get a sound and dab+ information? As dab_cmdline is coming with no GUI (this is exactly, I'm looking for) I would like to use dab_cmdline in RasPiCar, which is a Kodi (Python) application. With a car, there is a need to scan the radio stations more often than at home, because of driving around. When using dab_cmdline with Python interface, RasPiCar would need a list of available radio stations. Having this list, it would then use dab_cmdline to tune the radio station. My question is, where this radio station list is coming from. I had in mind, that a scan was already present in qt_dab and so I suggested a new 'scan' command in dab_cmdline. But of course, the list can also be created by a separate tool ;-) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AITzwJiK4kyOO2mXv9q_hGf6U5eaOK5bks5rshmygaJpZM4MylsL> .

-- Jan van Katwijk +31 (0)15 3698980 +31 (0) 628260355