This will also not work yet with CubicSDR as the SoapySDR API has moved to V0.6, CubicSDR is built against V0.5 so we will have to wait until the next build of Cubic supporting the latest V0.6 SoapySDR API. There should be some CubicSDR development builds in the near future...

And lastly, is Cliffe's SoapySDRPlay driver supposed to work with the new SDRplay API nowadays? I had to hack it to get it working, before I abandoned it and rewrote a new from scratch. Or has SDRplay released their own SoapySDR-driver now? You don't mention which "official" github you used.

SoapySDRPlay is a new version released by SDRPlay team and included in Github SoapySDRPlay approx 3 days ago.SoapySDR is from Github

I have done some test and solved the problem.As first test I have modified Registration.cpp forcing rspDevs[0].devAvail to "1". I have only 1 RSP1 and this worked.After this SDRUtils show my device ad "available" and CubicSDR is working

So I have search for a kernel module using my RSP1 and found that removing msi2500 will do the job. Now SoapySRTUtil show correctly:

After this test the problem was in kernel module but there is no "usb error" as in old post on this forum. And this kernel module don't interferes in correct RSP1 usage. My device is working with gr-osmosdr and Luaradio (both don't use mir_sdr_getDevices() call) and was working with old SoapySDRPlay

Yes, the GNU/Linux kernel module sdr_mir3101 does not per se interfere with the RSP1, but it will mark it as busy and if the new SopaySDRplay honors this flag, that was very likely your problem. The old (Cliffie's) didn't care.

My understanding is that there are different ways to blacklist devices on different Linux systems so that's probably not practical. If there is a consistent way to do it, then I'd be happy to add it to the installer.

The API now behaves correctly and only accesses the device if it has exclusive access. Blindly accessing the device without exclusive access could have caused issues.

btw it's not just sdr_msi3101 that can be a problem. I've also seen the following kernel modules cause issues: msi001 and msi2500

It's a shame any one can add totally unsupported reverse engineered modules into the kernel and they just get accepted.

The way I do it on Ubuntu is to add the following lines to the /etc/modprobe.d/blacklist.conf file

blacklist sdr_msi3101blacklist msi001blacklist msi2500

Any other way of trying to blacklist the modules that I've tried doesn't survive a reboot. Once I've edited the file, I reboot and then don't have a problem again.