fix: waterfall device claim fails on frequency change due to USB release lag

When restarting capture for a new frequency, the USB handle from the
just-killed process may not be released by the kernel in time for the
rtl_test probe inside claim_sdr_device. Add retry logic (up to 4
attempts with 0.4s backoff) matching the pattern already used by the
audio start endpoint.

Also clean up stale shared-monitor state in the frontend error handler
so the monitor button is not left disabled when the capture restart
fails.
This commit is contained in:
Smittix
2026-02-23 21:41:14 +00:00
parent 2e6bb8882f
commit 0daee74cf0
2 changed files with 123 additions and 104 deletions

View File

@@ -2488,6 +2488,17 @@ const Waterfall = (function () {
} else if (msg.status === 'error') {
_running = false;
_scanStartPending = false;
_pendingSharedMonitorRearm = false;
// If the monitor was using the shared IQ stream that
// just failed, tear down the stale monitor state so
// the button becomes clickable again after restart.
if (_monitoring && _monitorSource === 'waterfall') {
clearTimeout(_monitorRetuneTimer);
_monitoring = false;
_monitorSource = 'process';
_syncMonitorButtons();
_setMonitorState('Monitor stopped (waterfall error)');
}
if (_scanRunning) {
_scanAwaitingCapture = true;
_setScanState(msg.message || 'Waterfall retune error, retrying...', true);