Pressing Record no longer freezes the window while the disk creates the file, and a start that is waiting can be cancelled. A freeze report from a session of 0.99.58 showed the window stopped, for more than the five seconds after which FoxSDR files a freeze report, inside the call that creates a recording's folder and file. That call ran on the thread that draws the window - the Record IQ button, the Record audio button, the Record key and the web remote's record controls all made it - so a folder that was slow to answer (a synchronised or network folder, a drive that had spun down, a scanner holding the file) stopped the window drawing for as long as it took. The file is now opened in the background. Until it exists the button reads "Starting IQ - click to cancel" (or "Starting audio - click to cancel"), and after a second a line under it says "Waiting for the disk to open the file" with the seconds so far. Pressing Stop, the toolbar Stop on a running receiver, clicking that button, or the web remote's stop while it is waiting withdraws the recording: nothing is armed, the file is closed when it arrives, and what it leaves is the same zero-length file that pressing Record and then Stop at once has always left; nothing is deleted. A second Record while one is waiting changes nothing. A failed open is reported in the same words as before, a moment later. The recording's clock and the REC lamp start when the file is open, not when the button was pressed. If the receiver's input rate changes while the I/Q file is opening, that recording is not started and the panel says so, because the header written into the file would be for the old rate. Closing FoxSDR waits at most a quarter of a second for an open that is stuck and then leaves it behind. The log says once when an open has been out for five seconds and once when it returns, naming neither the folder nor the file. The new words are in all 33 interface languages as machine translations that nobody has read. Checked in FoxSDR's tests with a stand-in for a slow disk - a file open that is made to take 2.5 seconds - against a real freeze watchdog, which sees the freeze with the old call and sees nothing with the new one, and through the real window's handlers for the buttons, the key and the web remote; not on a real slow disk, and nobody has pressed the button on one. Not covered: a recording started by a speaker on the patch page still creates its file the old way, on the window's thread, and can still hold the window if the disk is slow; the web page does not show a start in progress, so its button reads Record until the file is open; and the drawing of the new button states is not read by any test, only the state it is drawn from.
A catalogue refresh no longer unloads and reloads every plugin when nothing in the plugins folder changed, and every plugin reload now writes one log line saying how long each step took. Fetching the plugin catalogue (the first time the plugin store window is opened in a session, or CHECK NOW) used to reload every plugin whether or not anything had changed, because the retirement rules it stores only take effect on a reload. A reload destroys every plugin's decoders, unmaps every plugin and maps them all again, on the thread that draws the window. One session of 0.99.58 did this twice, three seconds apart, and the window did not draw for two minutes inside one of them. The refresh now compares one listing of the plugins folder - each file's name, size and last-write time - with the one taken for the last reload that completed, and skips the reload when they are the same, with the log line "plugins: reload skipped - nothing changed since the last scan" (no names, no paths). Anything else reloads exactly as before: a file added, removed, renamed or replaced, a retirement rule that changed (the plugin it retires is then not loaded, and is loaded again when the rule is lifted), a folder listing that cannot be made, a plugin the last reload refused (what refused it may be outside the folder), or no completed reload to compare with. The Rescan key on the Fitted modules window, an install, an update and a removal always reload. The refresh also no longer rewrites the plugins folder's record of what is installed (installed.json) when the catalogue taught it nothing new. Every reload that does run now writes one line with the seconds each of its seven steps took, for example "plugins: reload took 3.6 s (decoders 0.0, patch 0.0, panels and map 0.3, unload 0.4, inventory 1.9, load 0.9, restart 0.1)"; a reload of five seconds or more is a warning that names the slowest step. The line contains no plugin name, file or path. What this does not fix: a reload that is needed still runs on the window's thread with no limit, and can still hold the window for as long as a plugin takes to stop. One field session froze for two minutes inside one. What held it is not known, and the timing line, and the freeze report with every thread's stack that FoxSDR writes for a reload that runs past 30 seconds, are there to find out which step it was; moving plugin shutdown off the window's thread is not done, because it changes which thread every plugin is stopped on and the cause should be known first. Checked in FoxSDR's tests against the real window and real plugin modules that record when they are loaded, unloaded, and asked to create and destroy a decoder, with the catalogue read from a local file: an unchanged folder leaves every module and decoder alone, and each kind of change above reloads. Not checked: a catalogue fetched over the network, a plugin that is slow to stop, a folder on a file system with a coarse clock (a file replaced by one of the same size and the same last-write time is not seen). On Linux the same tests have since passed in our automated build; nothing was tried by hand there.
The Fitted modules window no longer reads every plugin file's size from the disk on every frame it is open. To draw each module's plate the window asked the file system for the size of that plugin's file, for every plugin, on every frame, on the thread that draws it, in the plugins folder - which for a Microsoft Store install is a redirected profile folder. A slow or sleeping disk, or an unreachable share, held the whole window on one slow answer; one such call on an unreachable share was timed at 26.7 seconds. The size is now read once, when the plugins are scanned, from the folder listing that scan was already reading, and the window draws that figure. It can therefore be as old as the last reload: a plugin file replaced by hand shows its old size until the next reload, which installing, updating, removing and the Rescan key all do. Checked in FoxSDR's tests: a test of the drawing function's source holds it to no file-system call at all, and was seen to fail against the old code first; the scan's recording of sizes and the carry of the figure to the window are tested too. Not seen on a real slow disk, and the freeze itself was worked out from the code and one timed call, not reproduced in a session.
Freeze reports name a module that was loaded after start-up, and a freeze inside a display driver that was loaded late is filed as a display stall. FoxSDR names each frame of a frozen thread from a list of the modules that were loaded when the list was last refreshed, so a thread stuck inside code loaded after that - a graphics driver the system reloaded after a reset, a vendor DLL, a shell extension - printed those frames as bare addresses. The report could not say where the thread was, and the rule that tells a display stall (a monitor switched off, a graphics-driver reset, a remote session reconnecting) from a freeze of FoxSDR could not recognise a graphics driver it had never heard of, so that freeze was filed as a hang, which is sent (with Diagnostics on) as a freeze of FoxSDR, instead of being kept on your computer and counted only as a number. Such a frame is now named by the module's file name and the distance into it, like every other frame. For that frame the report sent now carries the file's name (never a path) and the offset, where before it carried an empty module name and an address inside the process; PRIVACY.md says so. The list of loaded modules in a report is still the one from the last refresh: a late module is named on the stack lines and is not added to it. Windows only. Checked in FoxSDR's tests with a real watchdog and a real thread parked inside a DLL that is loaded after the list was last refreshed, and again with that DLL under a graphics driver's file name, where the report comes out as a stall; not seen on a real driver freeze.
SHA-256 of foxsdr-setup-0.99.63.exe:
ae2453308b2a44ae86acc751b9263cfd820fbc092d8532ad08faef814dafd7f1
SHA-256 of FoxSDR-0.99.63-x86_64.AppImage:
9dbb922412ad40a1b6d0886e83df839bd20d99641813f8eda53007ffc2c072bf
SHA-256 of foxsdr-0.99.63-linux-x64.tar.gz:
1e101ac328dcf2b3425728a40fdaf8a4fca2ee27a514e7ed3c6f6cbbefc29a2c
SHA-256 of FoxSDR-0.99.63-aarch64.AppImage:
00762eb22c68d9f5077ad5cf46ce2521e2a9b6125869f24970359c409684ef28
SHA-256 of foxsdr-0.99.63-linux-arm64.tar.gz:
a609a81b7dbbd6663d71e922b321ce3f58cf61d5dd54265b3acb1535c7019c54