FoxSDR 0.99.85

FoxSDR 0.99.85 is the release the first 0.99.84 field reports asked for. An SDRplay radio whose service was still delivering samples when FoxSDR closed could take the whole application down in its last instant: a crash report from an RSPduo owner caught the vendor's own thread writing into a buffer FoxSDR had just freed on its way out of the process, and that buffer now outlives the exit. The same owner's report bundle found three smaller things, each fixed: Ctrl+A and Ctrl+C in the report page's read-only diagnostics box switched the receiver to AM and then CW instead of selecting and copying; a change of sample rate left no line in the log, so a report with eight changes in it could not say which rate any minute had run at; and the count of samples the SDRplay service itself lost - the one number 0.99.84 added the field for - came back masked as service gaps #, because the longer line was cut by the log and a cut line is scrubbed whole. A USRP owner on radioconda, whose UHD ships without its firmware images, saw an empty Source list and a radio-setup page that called the radio usable; FoxSDR now reads UHD's own warning and says what is missing and how to get it. And the Microsoft Store package declares all 34 interface languages, so the Store's listings can match what the application already does.

Still not fixed: the RSPduo owner's crackle at 4 MS/s itself. The 0.99.84 counter did its job - the loss is inside the SDRplay service on the USB side at a steady 4 MS/s and absent at 8 - and the remedy, if there is one in software, is a USB transfer mode or a different anti-alias filter the next round of testing will decide. The 0.99.81 plugins-reload freeze remains open with its instrumentation in place and no newer report yet. The two 2026-10-05/06 fast-fail crash reports from 0.99.64/65 remain unexplained, and the one 0.99.75 AppImage start-up death can only be diagnosed if it recurs on 0.99.78 or later. The Microsoft Store copy stays on its current version until the next submission is certified.

SHA-256 of foxsdr-setup-0.99.85.exe:
1ee66fce4ec76af62d237eff313a42378852a07f7c72d4b77a79c017119800e0

SHA-256 of FoxSDR-0.99.85-x86_64.AppImage:
6b73db1e1b752493e9efa41112b87747c4875597d91cc20ef6b9b634f2802498

SHA-256 of foxsdr-0.99.85-linux-x64.tar.gz:
232ab01740e07c96c6b2cef9aae567e6dbc4e6f33f114620f64afb8262287416

SHA-256 of FoxSDR-0.99.85-aarch64.AppImage:
13920019dbf0193d00803f4a714118b3511b81c3de5893dd653dfaf961238221

SHA-256 of foxsdr-0.99.85-linux-arm64.tar.gz:
17d87380986fe57a02aa9e802991be08d04fef7607ae8afb3bea0c12739cc63b

Features and fixes, 2026-10-23

A stranded SDRplay stream can no longer crash FoxSDR as it exits. Crash report 929BF825C4993CB3 (0.99.84, Windows 10, an RSPduo at 4 MS/s): an access violation on the SDRplay service's own thread, two frames of FoxSDR above sdrplay_api.dll, 107 seconds into the session - the instant the main window closed. The log tells the sequence. The reader had declared the stream stalled half a minute earlier, but the service never stopped delivering (its last health window counts 115,296 blocks, 111,135 of them into a ring nobody was reading any more); so when the window closed, the driver took the branch it has for a service it no longer trusts - stop without Uninit, close without ReleaseDevice - and set the stream's buffer aside in a process-wide graveyard rather than free it under a thread that might still be inside it. That graveyard was an ordinary static object, and the C runtime destroys those when main returns, on the main thread, while every other thread in the process is still running: the operating system ends them only afterwards. The service thread, which nothing had told to stop, took its next block into the freed buffer. The graveyard is now a heap object that nothing, not even exit, deletes, which is what "for the life of the process" always meant. A new test runs itself as a child process - a fake SDRplay service delivering a block every millisecond, a stop whose Uninit the service refuses, the source destroyed, main returned with the service thread live - and an object destroyed after the driver's own statics checks that the stranded buffer is still there: exit code 7 before the fix, 0 after it, ten runs of ten. The reporter builds FoxSDR from source in a Debug configuration, whose freed-memory fill made the fault certain where a shipped build would merely have been exposed to it.

Keys stay out of a read-only text field. Ctrl+A and Ctrl+C in the report page's diagnostics box switched the mode to AM and then CW (GitHub issue 6). The key dispatcher asked Dear ImGui's WantTextInput alone, and that flag is ImGui's answer to "should a software keyboard be shown" - never true for a read-only InputText, which nevertheless owns the keyboard while its text is selected and copied. A new textFieldHoldsKeys() asks the second question too, whether any text field, editable or not, is the active item, and the dispatcher stays out while one is. A headless ImGui test drives a read-only box and an editable one through both answers.

Every accepted sample-rate change is logged. dsp: input rate 4000000 S/s -> 8000000 S/s, channel 200000 S/s (decimate by 40), written once at the pipeline's commit, where every path a rate change can take - the rail's Rate combo, a plugin preset, the browser, a retune the driver answered with another rate, a source change - ends. A no-op and a refusal leave no line. Through 0.99.84 a change left nothing but the DSP thread's restart line, so the issue 6 bundle, with eight changes in it, could not say which rate any minute had run at.

The SDRplay service-gap count reaches its reader whole. The bundle's stream-health lines read reads #, ... service gaps #: 0.99.84's tail took the line to 194 characters, the diagnostic log holds 191, and a cut line has every number masked by the upload scrub (the unit that named one may be in the lost part). Widening the log was tried and reverted - a full log ring plus the report's history sections must fit the 64 KiB diagnostics cap agreed with the site, which a test holds to the byte. The gaps now follow the health line on a line of their own, source: SDRplay service gaps 112 (592884 samples), at the same level, the answer the Airspy driver already uses for the same problem; the health line is again the Soapy format word for word. A reader that took the tail from the health line reads the line after it instead.

A USRP that UHD cannot identify for want of firmware images is named, not silently unlisted. radioconda installs SoapyUHD and UHD but ships no images directory, so UHD's discovery warns Could not find path for image ... <no images directory located> and lists nothing - while the radio sits healthy on the bus with the right driver, the radio-setup page calls it usable, and the Source list is simply empty. FoxSDR now recognises UHD's own warning (from the SoapySDR log bridge in the enumeration child, and on Windows from the child's standard error as well, which the parent now reads and passes on unchanged, because radioconda's SoapyUHD does not forward UHD's log) and says so in three places: an amber line under the Source list while a USRP is on the USB bus, a vendor-missing finding on the radio-setup page that names uhd_images_downloader and UHD_IMAGES_DIR ahead of the generic advice, and a warning in the log. The installer's post-install note tells USRP owners about the step. The new texts are in all 33 catalogues (machine translations that nobody has read). Not verified on a radioconda-only machine: the one here has had UHD_IMAGES_DIR set since the diagnosis, and the condition was reproduced by clearing it for the helper run the detector was written against.

The Microsoft Store package declares all 34 interface languages. The MSIX manifest listed English only; it now lists English and the 33 catalogues, which is what Store Policy 10.7 asks of a product that supports them and what the Store builds its listing languages from. The application itself already follows the Windows display language when its setting is "auto". The 0.99.84 Store package was rebuilt from this manifest by hand for submission 23; from this release the ordinary build carries it.