Solution to spyserver "Could not acquire the device" error on Linux with rtl-sdr device

Need help installing or figuring out something about your SDR? Ask here.
Post Reply
Timpanogos Slim
Posts: 9
Joined: Mon Feb 10, 2020 1:39 am

Solution to spyserver "Could not acquire the device" error on Linux with rtl-sdr device

Post by Timpanogos Slim » Mon Feb 10, 2020 1:53 am

I beat my head against this issue on both intel and arm linux environments, and google revealed no helpful information at all.

The following instructions assume of course that you know your rtl-sdr device is working because rtl_test runs successfully.

For the record, I think it's possible that you can set a sample rate in spyserver.config that would result in a nonworking system, but i don't think it is the usual cause of this error.

My linux debugging skills were a little rusty but eventually, I looked up the syntax to have strace log the system calls to a file.

Code: Select all

strace -f -o spyserver.trace ./spyserver
Then try to connect to the server with sdrsharp, and the logs clearly showed that on my 64-bit armbian system, it was beating the bushes looking for librtlsdr.so in about a dozen different places and not finding it.

In current debian/armbian/raspbian/etc, it's present as librtlsdr.so.0 and if spyserver were a normal dynamically linked binary i am pretty sure that the dynamic loader would have taken care of that for it.

Just add a symlink named librtlsdr.so that points to librtlsdr.so.0.

On my system, because it's an aarm64 system with armhf libraries loaded for compatibility with the spyserver binary, I did this:

Code: Select all

sudo ln -s /usr/lib/arm-linux-gnueabihf/librtlsdr.so.0 /usr/lib/arm-linux-gnueabihf/librtlsdr.so
To find it on your system, use the find command like this:

Code: Select all

find /usr/lib -name librtlsdr.so.0
For example, on my 64-bit intel linux system, it's in /usr/lib/x86_64-linux-gnu/

rtlsdrblog
Site Admin
Posts: 2521
Joined: Mon Nov 19, 2012 11:54 pm

Re: Solution to spyserver "Could not acquire the device" error on Linux with rtl-sdr device

Post by rtlsdrblog » Thu Feb 13, 2020 3:09 am

How did you install the RTL-SDR drivers, manually, or via the repos? I don't think i've ever come across this issue before on multiple Linux/Raspbian installs of Spyserver (although I did those several months ago), but thanks for providing a fix!

Timpanogos Slim
Posts: 9
Joined: Mon Feb 10, 2020 1:39 am

Re: Solution to spyserver "Could not acquire the device" error on Linux with rtl-sdr device

Post by Timpanogos Slim » Thu Feb 13, 2020 4:26 am

rtlsdrblog wrote:
Thu Feb 13, 2020 3:09 am
How did you install the RTL-SDR drivers, manually, or via the repos? I don't think i've ever come across this issue before on multiple Linux/Raspbian installs of Spyserver (although I did those several months ago), but thanks for providing a fix!
"apt-get install rtl-sdr" was how I installed them.

Annoyingly, the debian package doesn't include the udev rules file, so i had to get that from github. I should report that as a bug. It should be over in /usr/share/doc with the readme and stuff

I fixed this issue on my Orange Pi PC2 running Armbian/buster with the 5.4.7-sunxi64 kernel but i also observed it on an ubuntu 19.10 desktop amd64 machine. It appears that going forward, on debian derived linux distributions, the actual shared library is called librtlsdr.so.0. There is probably some kind of planned naming convention at play.

But it's not debian at fault. Programs that load shared libs in a normal way will take it in stride.

Timpanogos Slim
Posts: 9
Joined: Mon Feb 10, 2020 1:39 am

Re: Solution to spyserver "Could not acquire the device" error on Linux with rtl-sdr device

Post by Timpanogos Slim » Thu Feb 13, 2020 4:37 am

fwiw my observation vis-a-vis the sample rate setting for spyserver is that when you connect to it with sdrsharp or sdr console, you will only be able to select sample rates the same or lower than that number which are actually a valid sample rate for your hardware.

Or maybe that is more correctly, a valid sample rate for the hardware-software combination? I would have to spend some time with test matrix to model the exact behavior and that feels like work. I have an inkling that the limitations are both different between my ancient e4000 based stick and my v3 stick AND between how those behave connected directly to a windows pc and how they behave behind spyserver running on linux, but it doesn't really matter.

Maybe the advice here is that if you can't connect with a sample rate you thought you could use natively, increase the number in the config file, restart spyserver, and try again. Increasing the sample rate at the spyserver end will increase the processing overhead a little and maybe cause the hardware to run a little warmer.

Post Reply