RTL2838 with RT820T2 on linux : Duplicate stations while scanning

[tenzap]

Hello

(If my sentences are a bit too synthetic, there is an example bellow of what is happening)

When changing Channel, it still reports the stations of the first channel found to have stations. So if for example the first stations are found on channel 5A, then for 5B the same channels are reported as 5A (but also on 5B), so I end up having many times the same stations in welle.io

Same problem, when I change the stations I listen to by selecting one in another channel, then welle.io gets populated with the stations of the first channel I selected but on that new channel (actually they don't exist on that channel)

Example :

Channel 5A has RADIO1 and RADIO2
When welle.io scans 5B, it will add RADIO1 and RADIO2, although there is RADIO3 only emitted on channel 5B... So I end up having in my stations list :

• RADIO1 on channel 5A
• RADIO1 on channel 5B
• RADIO2 on channel 5A
• RADIO2 on channel 5B

Workaround, close welle.io before scanning a new channel (in the expert mode). Then I manage to have :

• RADIO1 on channel 5A
• RADIO2 on channel 5A
• RADIO3 on channel 5B

But, if I open welle.io, choose to listen to RADIO3 on channel 5B, and then change to RADIO1 (on channel 5A), then it will add in my station list RADIO3 on channel 5A. Thus having :

• RADIO1 on channel 5A
• RADIO2 on channel 5A
• RADIO3 on channel 5A
• RADIO3 on channel 5B
  Workaround is to close & reopen welle.io before changing station

[tenzap]

This is on Debian buster 10 with "welle.io_2.0-Beta2_Linux_x86_64.AppImage"

[AlbrechtL]

Thanks for reporting. We have to take a look into it.

[tenzap]

Hello,

I could narrow down the issue and find a workaround that is probably not the best performance-wise so please feel free to improve it. Moreover it fixes the issue most of the time but not permanently.

In the console I always had this error right after your "rtlsdr_set_center_freq" call
rtlsdr_demod_write_reg failed with -9
Which points to a LIBUSB_ERROR_PIPE ( http://libusb.sourceforge.net/api-1.0/group__misc.html )

Actually the problem is likely to come because you use rtlsdr_read_async and you set the frequency before calling rtlsdr_cancel_async (see https://github.com/roger-/pyrtlsdr/issues/55 which put me on the way).

So the frequency was never updated hence the issue in this report.

So I modified the code to always stop the device before restarting it (especially when changing channel and scanning)
I also added a call to restart_device function when scanning.

It is probably better to handle that async thing directly, rather than with this workaround but that's beyond my knowledge/understanding. Moreover my workaround is not totally satisfactory because I still have that error sometimes in the console log and sometimes the issue described here is still is there. But at least it fixes this issue most of the time (but sadly not always) :/ There may be some other calls that need rtlsdr_cancel_async or are not catched by the workaround.

For now this fixes:

• scanning (no more duplicates and the frequency is really changed for each channel),
• manual change of channel &
• listening to a station that is on another channel.

Changes are detailed here.

https://github.com/AlbrechtL/welle.io/compare/next...tenzap:tenzap-workaround-duplicate-stations?expand=1

[tenzap]

That one may be much better and simpler. It works also in all 3 cases and modifies only rtl-sdr.

https://github.com/AlbrechtL/welle.io/compare/master...tenzap:tenzap-workaround-duplicate-stations-v2?expand=1

[AlbrechtL]

Are both PRs tenzap@16db3cb and tenzap@e334317 necessary?
If not close the old one please.

BTW: It is also possible to update PRs. Then it is not necessary to open many PRs just for the same thing. Anyway thanks for fixes!

[tenzap]

Since this is a "sensitive" change I would have liked your advice before making a PR. Especially that you check whether this is compliant with your architecture.
I guess the 2nd is better (the first one doesn't need to be applied if we use the 2nd)
So for, it works well for me.

[AlbrechtL]

Yesterday I didn't realized that you just linked some commits. I think you can createa pull request for version 2. Then I will add it to the welle.io version 2.1 list.

[tenzap]

see #431
Actually I don't understand why you don't merge this into 2.0 since it is labelled beta.

[AlbrechtL]

You got me. I will merge it to the 2.0.