search

pothosware / SoapySDRPlay3

Soapy SDR plugin for SDRPlay APIv3
https://github.com/pothosware/SoapySDRPlay3/wiki
MIT License
90 stars 15 forks source link

Now unlocking global mutex during sleep, to allow callbacks to execute. #59

Closed luarvique closed 1 year ago

luarvique commented 1 year ago

This should fix any random timeouts and failures to set various RSP settings (such LNA state).

fventuri commented 1 year ago

@luarvique, @fmoessbauer - many thanks for your work on this issue and your suggestions. I plan to look in more depth at this during the weekend when I have more time, and make sure your concerns get addressed.

Franco

luarvique commented 1 year ago

@fventuri , this pull request has been pending for quite a while now. Could you please review and merge it? If you do not want to merge it as-is, please, implement a similar fix that involves releasing the global lock before a wait.

fventuri commented 1 year ago

@luarvique - thanks for the reminder.

I wrote a very simple C++ program (attached) to try to reproduce the issue you reported here; in this program I have a loop that keeps changing frequency and RF gain (via the setting rfgain_sel) while the device is streaming. I ran the program a couple of times with my RSPdx here, however I am not able to reproduce the problem you experienced with OpenWebRX.

Do you mind showing me in more detail the steps you took in OpenWebRX to make that problem occur, or even better to write a simple program in C/C++/Python that causes that problem, so I can run some tests here?

Thanks, Franco

SoapySDRPlay3_test.zip

luarvique commented 1 year ago

Steps as follows:

1) Use current SoapySDRPlay3 release with OpenWebRX 1.2 and any RSP device.

2) Make a few random band changes using OpenWebRX.

3) In a shell connected to the machine where OpenWebRX is running, use one of the following commands to see OpenWebRX logs:

systemctl status openwebrx

or

journalctl -u openwebrx

4) In the log, you will see the following, or similar lines:

[WARNING] Sample rate/decimation update timeout.

Please, let me know if you would like me to walk you through the source of the problem again.

luarvique commented 1 year ago

PS: The problem is obviously not limited to band changes, but it is the easiest to see there.

fventuri commented 1 year ago

@luarvique - this afternoon I built the latest version of OpenWebRX (v1.3.0-dev), and tonight I created three OpenWebRX profiles for my SDRplay RSPdx: one for 10MHz (HF), another one for 2m (VHF), and finally a third one for the 70cm band (UHF). I switched between those profiles a couple of dozen times but I didn't see timeout messages related to frequency or gain changes.

The spurious messages:

[WARNING] Sample rate/decimation update timeout.

are due to the fact that OpenWebRX might change the decimation (not the input RSP sample rate) when changing bands; in this case (i.e. when only the decimation is changed) the effect is immediate, and the fsChanged flag is never triggered; I realized that a month or so ago when working on the wait-for-value-change branch (https://github.com/pothosware/SoapySDRPlay3/tree/wait-for-value-change), and in that branch I removed the waitForUpdate = true statement for this specific case (see here: https://github.com/pothosware/SoapySDRPlay3/commit/d06715cb517df34d87af0b09059e7100efb63729).

I plan to fix that bug in the master branch too in the coming days.

Franco

luarvique commented 1 year ago

Well, for me the problem frequently occurs when changing any values where a while() wait is present in the SoapySDRPlay3 code. The issue mostly disappeared once I implemented proper lock operation in the SoapySDRPlay3. It did remain in the frequency/decimation case and now, after your explanation, I see why.

fventuri commented 1 year ago

@luarvique - I just pushed to the master branch the code change the removes the waitForUpdate = true line in the case of the change of decimation only (which I think is what occurs when bands are changed in OpenWebRX).

I ran a few tests tonight changing bands with this bug fix, and I haven't seen any error/warning message so far, but I'll keep trying to try to reproduce your initial issue.

Franco

luarvique commented 1 year ago

Let me build and install the latest master branch tonight - going to see if I can recreate the message for non-band changes.

luarvique commented 1 year ago

@fventuri , well, updated to your latest "master" branch code, rebuilt, reinstalled .so, restarted OpenWebRX ... and lo and behold:

Oct 17 23:18:18 renegade openwebrx[162287]: 2022-10-17 23:18:18,141 - owrx.source - DEBUG - activating profile vhf-1 for sdrplay
Oct 17 23:18:18 renegade openwebrx[162287]: 2022-10-17 23:18:18,145 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 154300000
Oct 17 23:18:18 renegade openwebrx[162287]: 2022-10-17 23:18:18,147 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 6000000
Oct 17 23:18:18 renegade openwebrx[162287]: 2022-10-17 23:18:18,149 - owrx.source.connector - DEBUG - sending property change over control socket: rf_gain changed to auto
Oct 17 23:18:19 renegade openwebrx[162300]: [WARNING] Sample rate update timeout.
Oct 17 23:18:28 renegade openwebrx[162287]: 2022-10-17 23:18:28,192 - owrx.service - DEBUG - re-scheduling services due to sdr changes
Oct 17 23:18:28 renegade openwebrx[162287]: 2022-10-17 23:18:28,217 - owrx.service.schedule - DEBUG - source has active users; not touching
Oct 17 23:18:28 renegade openwebrx[162287]: 2022-10-17 23:18:28,226 - owrx.service - DEBUG - no services available
Oct 17 23:18:30 renegade openwebrx[162287]: 2022-10-17 23:18:30,796 - owrx.source - DEBUG - activating profile air-1 for sdrplay
Oct 17 23:18:30 renegade openwebrx[162287]: 2022-10-17 23:18:30,801 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 118800000
Oct 17 23:18:30 renegade openwebrx[162287]: 2022-10-17 23:18:30,803 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 2000000
Oct 17 23:18:30 renegade openwebrx[162287]: 2022-10-17 23:18:30,805 - owrx.source.connector - DEBUG - sending property change over control socket: rfgain_sel changed to 2
Oct 17 23:18:30 renegade openwebrx[162287]: 2022-10-17 23:18:30,807 - owrx.source.connector - DEBUG - sending property change over control socket: settings changed to rfgain_sel=2
Oct 17 23:18:31 renegade openwebrx[162300]: could not set unknown key: "rfgain_sel"
Oct 17 23:18:34 renegade openwebrx[162287]: 2022-10-17 23:18:34,538 - owrx.source - DEBUG - activating profile 15m for sdrplay
Oct 17 23:18:34 renegade openwebrx[162287]: 2022-10-17 23:18:34,542 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 21225000
Oct 17 23:18:34 renegade openwebrx[162287]: 2022-10-17 23:18:34,544 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 768000
Oct 17 23:18:34 renegade openwebrx[162287]: 2022-10-17 23:18:34,545 - owrx.source.connector - DEBUG - sending property change over control socket: rf_gain changed to auto
Oct 17 23:18:34 renegade openwebrx[162287]: 2022-10-17 23:18:34,546 - owrx.source.connector - DEBUG - sending property change over control socket: rfgain_sel changed to 0
Oct 17 23:18:34 renegade openwebrx[162287]: 2022-10-17 23:18:34,547 - owrx.source.connector - DEBUG - sending property change over control socket: settings changed to rfgain_sel=0
Oct 17 23:18:35 renegade openwebrx[162300]: [WARNING] Sample rate update timeout.
Oct 17 23:18:35 renegade openwebrx[162300]: could not set unknown key: "rfgain_sel"
Oct 17 23:18:36 renegade openwebrx[162300]: [WARNING] Gain reduction update timeout.
Oct 17 23:18:38 renegade openwebrx[162287]: 2022-10-17 23:18:38,515 - owrx.source - DEBUG - activating profile air-1 for sdrplay
Oct 17 23:18:38 renegade openwebrx[162287]: 2022-10-17 23:18:38,518 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 118800000
Oct 17 23:18:38 renegade openwebrx[162287]: 2022-10-17 23:18:38,522 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 2000000
Oct 17 23:18:38 renegade openwebrx[162287]: 2022-10-17 23:18:38,524 - owrx.source.connector - DEBUG - sending property change over control socket: rf_gain changed to auto
Oct 17 23:18:38 renegade openwebrx[162287]: 2022-10-17 23:18:38,526 - owrx.source.connector - DEBUG - sending property change over control socket: rfgain_sel changed to 2
Oct 17 23:18:38 renegade openwebrx[162287]: 2022-10-17 23:18:38,527 - owrx.source.connector - DEBUG - sending property change over control socket: settings changed to rfgain_sel=2
Oct 17 23:18:39 renegade openwebrx[162300]: [WARNING] Sample rate update timeout.
Oct 17 23:18:39 renegade openwebrx[162300]: could not set unknown key: "rfgain_sel"
Oct 17 23:18:40 renegade openwebrx[162300]: [WARNING] Gain reduction update timeout.
Oct 17 23:18:41 renegade openwebrx[162287]: 2022-10-17 23:18:41,065 - owrx.source - DEBUG - activating profile 30m for sdrplay
Oct 17 23:18:41 renegade openwebrx[162287]: 2022-10-17 23:18:41,068 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 10125000
Oct 17 23:18:41 renegade openwebrx[162287]: 2022-10-17 23:18:41,070 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 192000
Oct 17 23:18:41 renegade openwebrx[162287]: 2022-10-17 23:18:41,072 - owrx.source.connector - DEBUG - sending property change over control socket: rf_gain changed to auto
Oct 17 23:18:41 renegade openwebrx[162287]: 2022-10-17 23:18:41,073 - owrx.source.connector - DEBUG - sending property change over control socket: rfgain_sel changed to 0
Oct 17 23:18:41 renegade openwebrx[162287]: 2022-10-17 23:18:41,074 - owrx.source.connector - DEBUG - sending property change over control socket: settings changed to rfgain_sel=0
Oct 17 23:18:42 renegade openwebrx[162300]: [WARNING] Sample rate update timeout.
Oct 17 23:18:42 renegade openwebrx[162300]: could not set unknown key: "rfgain_sel"
Oct 17 23:18:42 renegade openwebrx[162300]: [WARNING] Gain reduction update timeout.
Oct 17 23:18:43 renegade openwebrx[162287]: 2022-10-17 23:18:43,493 - owrx.source - DEBUG - activating profile air-1 for sdrplay
Oct 17 23:18:43 renegade openwebrx[162287]: 2022-10-17 23:18:43,496 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 118800000
Oct 17 23:18:43 renegade openwebrx[162287]: 2022-10-17 23:18:43,497 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 2000000
Oct 17 23:18:43 renegade openwebrx[162287]: 2022-10-17 23:18:43,498 - owrx.source.connector - DEBUG - sending property change over control socket: rf_gain changed to auto
Oct 17 23:18:43 renegade openwebrx[162287]: 2022-10-17 23:18:43,500 - owrx.source.connector - DEBUG - sending property change over control socket: rfgain_sel changed to 2
Oct 17 23:18:43 renegade openwebrx[162287]: 2022-10-17 23:18:43,501 - owrx.source.connector - DEBUG - sending property change over control socket: settings changed to rfgain_sel=2
Oct 17 23:18:44 renegade openwebrx[162300]: [WARNING] Sample rate update timeout.
Oct 17 23:18:44 renegade openwebrx[162300]: could not set unknown key: "rfgain_sel"
Oct 17 23:18:44 renegade openwebrx[162300]: [WARNING] Gain reduction update timeout.
Oct 17 23:18:53 renegade openwebrx[162287]: 2022-10-17 23:18:53,505 - owrx.service - DEBUG - re-scheduling services due to sdr changes
Oct 17 23:18:53 renegade openwebrx[162287]: 2022-10-17 23:18:53,512 - owrx.service.schedule - DEBUG - source has active users; not touching
Oct 17 23:18:53 renegade openwebrx[162287]: 2022-10-17 23:18:53,513 - owrx.service - DEBUG - no services available

In the above log, the update timeouts are of the main interest as far as this pull request is concerned. Once again, @fventuri , would you like me to go over why they happen with you?

fventuri commented 1 year ago

@luarvique - quick update; I ran a few more tests here and these are my findings:

Franco

luarvique commented 1 year ago 
* I don't see that message `could not set unknown key: "rfgain_sel"`; perhaps in your CMakeLists.txt you have the option `RF_GAIN_IN_MENU` set to OFF? Also if you don't mind, could you attach here the OpenWebRX configuration file `settings.json` that you are using there? This way I can try to figure out if there's any setting there that causes this message

Please, disregard this message: it originates from OpenWebRX, does not signify an error, and does not affect SoapySDRPlay3 operation.

* I was able to reproduce the `[WARNING] Sample rate update timeout.` here; I did some research on the root cause, and I was able to also have the same issue in SDRplay `RSPTCPServer` program (https://github.com/SDRplay/RSPTCPServer). I contacted SDRplay about this problem (the flag `fsChanged` does not seem to be set after a change in sample rate), provided them with the logs, and they are looking into it; hopefully this problem could be solved soon

The same issue occurs with all the flags for me, not just with fsChanged. Every time you wait for a callback to change the flag, without releasing the global lock, there is a timeout.

* I don't see the other warnings about changes in gain reduction timeouts, and I was hoping that with your OpenWebRX `settings.json` I might be able to make them happen here too

I suspect that the significant difference between our setups is the host hardware architecture and the operating system. I am running Armbian on a ROC-RK3328-CC SBC. Differences in the hardware and OS may account for different threading library operation.

fventuri commented 1 year ago

@luarvique - ARM-32 or ARM-64?

I have a Raspberry Pi sitting in a drawer here somewhere, and I thought I could give it a try using the latest Raspberry OS to see if with that hardware I can reproduce those timeouts for changes in gain and frequency.

Franco

luarvique commented 1 year ago

ARM64. I can probably just give you SSH access to my current hardware, if absolutely necessary.

fventuri commented 1 year ago

@luarvique - I wonder if those timeout warnings when changing the gain reduction values might be due to the fact that the function sdrplay_api_Update() is returning an error code when trying to change the gain reduction, my SoapySDRPlay3 driver ignores it, and therefore you see that timeout warning about the gain reduction because it never actually gets changed due to the error.

I just updated the master branch to check the return values from sdrplay_api_Update() when the user changes frequency, sample rate, or gain reduction; with this code change you should now see a warning like this when you try to set an invalid gain reduction value (gRdB or LNAstate):

[WARNING] sdrplay_api_Update(Tuner_Gr) Error: sdrplay_api_OutOfRange

Give it a try and hopefully this will explain those Gain reduction update timeout warnings.

Franco

luarvique commented 1 year ago

@luarvique - I wonder if those timeout warnings when changing the gain reduction values might be due to the fact that the function sdrplay_api_Update() is returning an error code when trying to change the gain reduction, my SoapySDRPlay3 driver ignores it, and therefore you see that timeout warning about the gain reduction because it never actually gets changed due to the error.

That was actually my first suspicion and I also made SoapySDRPlay3 print warnings on sdrplay_api_Update() failures. But no, the function succeeded, and the gain reduction values were ok (0-3 for the little blue MSI.SDR).

SDRplay commented 1 year ago

A gentle reminder that using the SDRplay API with non-SDRplay hardware is a violation of the API license. We cannot warrant how the API operates with non-SDRplay hardware and things like gain control use more than just the Mirics chipset and so you can easily see invalid responses in that condition. It is unfair that @fventuri spends his valuable time chasing down issues that are not supported by the API. If the issue post contained the hardware in use, then at least @fventuri and others could decide whether it should be allowed or actioned on in this issue list. If there are genuine issues that people are finding with the API using genuine SDRplay hardware, we're always happy to work with people on them.

luarvique commented 1 year ago

@SDRplay, well, the usage case in question does not allow for the use of the genuine hardware, since it simply would not fit. But I do have the genuine hardware (RSPduo) and can bet that the same exact issue happens with it as well, since the issue does not appear to be with the SDRPlay drivers.

Also, please, allow me to use this opportunity for a gentle reminder of my own. This pull request has been pending for 5 months now, with no reaction from @SDRplay developers:

https://github.com/SDRplay/ExtIO_SDRplay/pull/2

I have also reported the issue to the user support (before attempting to fix it) and was essentially told to screw off. This is, mind you, for the genuine SDRPlay hardware. Thank you for the use of my valuable time.

SDRplay commented 1 year ago

@luarvique I was not commenting on the issue you are referring to, I was commenting on the use of the SDRplay API - the issue you reported to us in May was about Bias-T control and that was incorporated into changes to the repo a couple of months ago. It wasn't ignored and I don't recall you being told to "screw off". The pull request was regarding a different issue, tuner switching, which was again incorporated into a number of changes that were made a few months ago.

Just so I understand this correctly... you've seen an issue with the SoapySDRPlay library and a non-SDRplay piece of hardware. You assume it would also work in the same way on SDRplay hardware? You could have helped Franco out by testing on genuine SDRplay hardware - maybe you have, I just haven't read up through the entire thread. Generally speaking, these things are always best reported using genuine hardware, so that everyone has a far better chance of reproducing whatever issue is being chased.

luarvique commented 1 year ago

@luarvique I was not commenting on the issue you are referring to, I was commenting on the use of the SDRplay API - the issue you reported to us in May was about Bias-T control and that was incorporated into changes to the repo a couple of months ago. The pull request was regarding a different issue, tuner switching, which was again incorporated into a number of changes that were made a few months ago.

This is very good to know, although a simple note on the pull request at the time of the changes would be very helpful.

It wasn't ignored and I don't recall you being told to "screw off".

You did not. Your customer support did.

Just so I understand this correctly... you've seen an issue with the SoapySDRPlay library and a non-SDRplay piece of hardware. You assume it would also work in the same way on SDRplay hardware?

Yes, because, as far as SDRPlay driver is concerned, everything is fine. There are no errors coming from the driver. I checked. Also increased the wait time for a callback to come up to one second. Same thing.

You could have helped Franco out by testing on genuine SDRplay hardware - maybe you have, I just haven't read up through the entire thread.

Essentially, I cannot stick the whole RSPduo where that MSI.SDR dongle is currently located. I can try plugging it in as the last resort, but going to recheck the software first.

fventuri commented 1 year ago

@luarvique - since at this point it seems that the most significant difference between what you see there and what I am able to replicate on my side are those timeout warnings whenever the gain reduction settings are updated via sdrplay_api_Update(), I just created a new branch called debug-grChanged (https://github.com/pothosware/SoapySDRPlay3/tree/debug-grChanged).

The code in this new branch is identical to the code currently in master with the addition of a few log statements that should help tracking what happens when those settings are updated; for instance when I run OpenWebRX here with the code from that new branch, these are the additional debug messages I see in the terminal:

[INFO] setGain() - calling sdrplay_api_Update(Tuner_Gr)
[INFO] gr_changed=0 params->grChanged=1
[INFO] setGain() - calling sdrplay_api_Update(Tuner_Gr)
[INFO] gr_changed=0 params->grChanged=2

Please give it a try when you have some time, and let me know what you see there.

Franco

luarvique commented 1 year ago

All right. Just to keep the experiment clean, I am also going to update to the latest OpenWebRX version from the master branch.

luarvique commented 1 year ago

So, I installed SoapySDRPlay3 from the debug branch you created, updated OpenWebRX to 1.2.1, and did make some local changes to that OWRX install (nothing serious though). Now, things are even more interesting though.

Every now and then, SoapySDRPlay3 fails to change the frequency. The log below corresponds to me switching from 40m to 10m, then to 20m, then to 80m:

Switching to 40m is ok:

Oct 29 21:32:47 renegade openwebrx[6318]: 2022-10-29 21:32:47,206 - owrx.source - DEBUG - activating profile 40m for sdrplay
Oct 29 21:32:47 renegade openwebrx[6318]: 2022-10-29 21:32:47,211 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 7150000
Oct 29 21:32:47 renegade openwebrx[7639]: [INFO] gr_changed=65535 params->grChanged=4

Switching to 10m fails, leaving OWRX at 40m (although it does not know that and shows it as "10m"):

Oct 29 21:32:53 renegade openwebrx[6318]: 2022-10-29 21:32:53,307 - owrx.source - DEBUG - activating profile 7cba5d74-11b9-4a93-a485-f605f9197862 for sdrplay
Oct 29 21:32:53 renegade openwebrx[6318]: 2022-10-29 21:32:53,311 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 768000
Oct 29 21:32:53 renegade openwebrx[6318]: 2022-10-29 21:32:53,312 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 28250000
Oct 29 21:32:53 renegade openwebrx[7639]: [WARNING] sdrplay_api_Update(Tuner_FrF) Error: sdrplay_api_RfUpdateError
Oct 29 21:32:54 renegade openwebrx[7639]: [INFO] gr_changed=65535 params->grChanged=2

Switching to 20m also fails, but SoapySDRPlay3 now goes to 10m (!), mistakenly shown by OWRX as "20m":

Oct 29 21:34:40 renegade openwebrx[6318]: 2022-10-29 21:34:40,400 - owrx.source - DEBUG - activating profile 20m for sdrplay
Oct 29 21:34:40 renegade openwebrx[6318]: 2022-10-29 21:34:40,403 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 384000
Oct 29 21:34:40 renegade openwebrx[6318]: 2022-10-29 21:34:40,404 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 14175000
Oct 29 21:34:40 renegade openwebrx[7639]: [WARNING] sdrplay_api_Update(Tuner_FrF) Error: sdrplay_api_RfUpdateError
Oct 29 21:34:41 renegade openwebrx[7639]: [INFO] gr_changed=65535 params->grChanged=2

Finally, switching to 80m succeeds and I can finally see actual 80m in OWRX:

Oct 29 21:36:18 renegade openwebrx[6318]: 2022-10-29 21:36:18,507 - owrx.source - DEBUG - activating profile 80m for sdrplay
Oct 29 21:36:18 renegade openwebrx[6318]: 2022-10-29 21:36:18,509 - owrx.source.connector - DEBUG - sending property change over control socket: samp_rate changed to 768000
Oct 29 21:36:18 renegade openwebrx[6318]: 2022-10-29 21:36:18,510 - owrx.source.connector - DEBUG - sending property change over control socket: center_freq changed to 3750000
Oct 29 21:36:18 renegade openwebrx[7639]: [INFO] gr_changed=65535 params->grChanged=2
Oct 29 21:36:18 renegade openwebrx[7639]: [INFO] gr_changed=65535 params->grChanged=1

@fventuri, since you are the expert, you tell me what it is doing there.

luarvique commented 1 year ago

Just to clarify, no LNA changes are being sent in the above test. Whatever it is doing above, isn't related to the LNA state.

luarvique commented 1 year ago

I suspect that your premature return on sdrplay_api_Update() errors may be the reason for the above behavior:

            sdrplay_api_ErrT err = sdrplay_api_Update(device.dev, device.tuner, sdrplay_api_Update_Tuner_Frf, sdrplay_api_Update_Ext1_None);
            if (err != sdrplay_api_Success)
            {
               SoapySDR_logf(SOAPY_SDR_WARNING, "sdrplay_api_Update(Tuner_FrF) Error: %s", sdrplay_api_GetErrorString(err));
               return;
            }

Please, consider waiting and retrying the sdrplay_api_Update() call a few times if it returns an error. The SDRPlay API server might simply be busy with some other work.

fventuri commented 1 year ago

@luarvique - I ran a few tests tonight trying to replicate the sdrplay_api_RfUpdateError that you are seeing with your configuration using the code from the debug-grChanged branch, but unfortunately I was unable to replicate it with my RSPdx. The settings.json file I used for these tests is attached so you can see if I missed anything.

Whenever I see error messages like those, I usually set the SDRplay API debug level to verbose by uncommenting line 1876 in Settings.cpp (https://github.com/pothosware/SoapySDRPlay3/blob/debug-grChanged/Settings.cpp#L1876) and commenting out the previous line. After replicating the same problem with the verbose debug level, you should see some useful diagnostic messages in the system log files (/var/log/messagesor perhaps with journalctl). These messages all contain the string sdrplay_api so you can use grep to search for them; they usually provide some insight on what caused that error.

Franco

settings.json.zip