List of services is not completely deleted

[Drehrumbum]

Hi Clem!

After switching to another multiplex, some of the services from the previously displayed multiplex sometimes remain in the list of services. The behavior cannot be reproduced, it happens randomly. A problem related to this was reported last year in issue #63 by andimik.

In the example below, the switch was from channel 5C to channel 5D. Some programs from the "1st Bundesmux" (like "DLF Kultur") can still be seen in the list.

[softsyst]

This is an old non-reproducible one. A bug, not a feature! Probably the same one as #47.

[Drehrumbum]

Hello Clem,

as you more likely know, I always test new QIRX versions with the CPU throttled (fixed at 1.2 GHz) to see if performance has changed. While playing around a little, the bug came up. After switching from the MDR (9A) to the regio-mux at 10A, some services remain in the list. "New" (I've never seen that before) was the empty entry in between.

[softsyst]

Many thanks for the observation!

[andimik]

I had similar observations with Qt-DAB and fear the culprit is rtl_tcp.

[softsyst]

The problem could be - after a request of a new frequency (mux change request) - to get rid of all the samples of the old mux being possibly still in the whole queue, back to the hardware. What would be necessary was an event from the hardware or the IQ server, being sent after the samples from the new frequency have been started to arrive. According to @old-dab this is technically not easily possible.

The RSPs get an indication from the sdrplay service when a new frequency was selected, as a parameter of the callback function where the samples arrive. QIRX tries to evaluate it, thus it would be interesting whether the error still occurs in the RSPs as well.

[Drehrumbum]

Hi folks!

The rtltcp is likely not the problem and IMHO there is no need for a "new samples available" indicator. If I change the frequency directly inside of the rtltcp callback function (or calling SetEvent() there for signaling the waiting worker-thread that a new buffer arrived), it only takes a few milliseconds for the command to arrive in the dongle. When the next buffer arrives through the callback function you can see a short noise-burst in the IQ signal, after which the samples come from the newly selected frequency. I know this, because I wrote a simple DAB scanner that checks up to 32 channels per second for activity (RMS) last year.

Well, QIRX uses a circular buffer, which means that it takes some time (depending on its size) until the samples from the newly set frequency are actually used. This leads me to the following suggestion for channel switching:

• Set the new frequency
• Clear the services list, forget all you know about the last multiplex
• Wait until the known “round trip time” of the circular buffer is reached
• Start a brand new Null-symbol detection

Diving a little deeper - another test...

• Make a IQ-Recording (one minute or so) and step from one multiplex to the next every 10 seconds.
• Loop playback this file over TCP

Sit back and watch the show. QIRX re-syncs to the Null-symbols, shows the multiplexes/ services and works as expected. Now let’s make some noizzzz – throttle the machine a bit and move the tiles with the mouse. Watch the video and keep an eye on the multiplex-name display. Although QIRX notices and shows that there is a different multiplex every 10 seconds, the service list is not deleted.

CU Heiko

422_stress1.mp4

[softsyst]

Hi Heiko,

many thanks for your little demo. I'll try to reproduce it.

The suggestions you are making are already implemented. But life is a little more complicated than you sketch it. For instance, qirx has not only one circular buffer. And some multithreading where all relevant threads need to be terminated properly on a mux change. Only Details (with the devil inside).
Anyway, I'll continue on this error, although I did not see it here for a long time.

Clem