Airspy R2 works. FoxSDR's own Airspy driver asked the radio for samples before telling it to start receiving; the Airspy firmware switches its sample connection off whenever the receive mode changes, so the first read failed with "Windows error 31" and the radio was given up for the session. The driver now starts the radio in the order Airspy's own software uses, restarts the stream by itself if a read ever fails, and no longer mistakes stopping or a rate change for a dead radio. Reported by two beta testers; thank you.
HackRF on older firmware. The same start order would have failed on HackRFs running firmware from 2018 or earlier, and stopping could mark a healthy HackRF dead. Both follow HackRF's own order now.
SDRplay no longer jams. Once a minute FoxSDR wrote to its diagnostic log from inside the SDRplay driver's own thread; on a busy disk that held the driver up long enough for the SDRplay service to stop answering. FoxSDR now never makes the SDRplay driver wait for anything, and if the service does stop, START tells you to restart the SDRplay API service instead of failing with "AlreadyInitialised" again and again.
None of these radios is on our bench, so the fixes are proven against simulations built from each maker's own firmware and software. If your radio still misbehaves, REPORT A BUG / DISLIKE with the diagnostics bundle tells us exactly what happened.
SHA-256 of foxsdr-setup-0.99.32.exe:
3beb3829f87ae75a4b7f36d01755cb1f492e7339dcc7836e8029b2f9eaa80bc0
SHA-256 of FoxSDR-0.99.32-x86_64.AppImage:
8e29c2426a67d9f87db05d74156a96cfced5cb5ca7ee7afc677138affff883ce
SHA-256 of foxsdr-0.99.32-linux-x64.tar.gz:
92241545e5f78af265a414b89e25ba7048ca73751b1308cd6dbc4519484a9a04