aethersdr / aethersdr/AetherSDR
AetherSDR.exe not closing completely, Reset VFO & EQ
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 221
- Forks
- 117
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 299
Description
Report preparation
- I used the AI-assisted bug report tool (Help → Support → File an Issue)
- I have attached a support bundle or log file
What happened?
Title: AetherSDR.exe not closing completely, Reset VFO & EQ
What did you expect?
Expectation was for VFO to remain where I last was using, as well as not resetting my RX EQ settings.
Steps to reproduce
Unable to reproduce.
Radio model & firmware
Radio: AU-510
Firmware: 4.2.20.41343
OS & version
OS: Windows 11
AetherSDR: 26.7.2
Qt: 6.8.3
Issue Description
VFO resets to 14.100 and RX EQ resets to zero positions. Noticed that the AetherSDR process is still alive in Windows Task Manager after shutting down AetherSDR from the UI. Unable to reliably reproduce; happens intermittently.
Developer Notes
Likely root cause: shutdown isn't completing, which breaks the settings-save path
Per the project's settings architecture, all client-side state (window geometry, layout, and client-side DSP including RX EQ/NR2/RN2/NR4/DFNR) is persisted through AppSettings (src/core/AppSettings.h) to ~/.config/AetherSDR/AetherSDR.settings — on Windows this maps to the equivalent per-user config path. Frequency/VFO, by contrast, is explicitly radio-authoritative and is not supposed to be saved client-side at all; the client is meant to pick it back up from the radio's own session/GUIClientID restore on reconnect.
That split is the key to both symptoms:
RX EQ resetting points to AppSettings::save() (or the app-exit path that calls it) not running to completion. If settings are only flushed on a clean exit, and the process is hanging around in Task Manager instead of exiting, the save may be getting skipped or truncated on that particular run — which would explain why it's intermittent rather than 100% reproducible.
VFO resetting to 14.100 is more likely a reconnect race, not a settings bug — 14.100 (or 14.225, the documented default) looks like a fallback/default slice frequency being applied because the client didn't get (or didn't apply) the radio's RF_frequency status in time before creating/redisplaying the default slice. Worth checking the "Connection Sequence" step 6 (slice list → create default slice if empty) for a case where the radio's actual slice state hasn't arrived yet and the client falls through to the hardcoded default.
Files most likely involved:
src/core/AppSettings.h / .cpp — settings load/save; check whether save() is called on every exit path or only on a "clean" one
src/models/RadioModel — owns m_reconnectTimer (3s auto-reconnect) and m_intentionalDisconnect flag; worth checking whether intentional-disconnect/shutdown correctly stops all threads and timers before the process should exit
src/models/SliceModel — default slice creation logic (slice list empty → create default at 14.225/14.100)
Whatever owns app shutdown/QApplication::quit() in src/gui/MainWindow — since up to 11 worker threads exist per the architecture doc, a thread not joining cleanly (e.g., the PanadapterStream VITA-49 UDP thread, or the audio engine thread) would explain the ghost process in Task Manager while also short-circuiting any exit-time settings save
Logging to enable (Help → Support):
Settings / Persistence (to confirm whether AppSettings::save() fires and what it writes on that session)
Connection / Protocol (to see whether RF_frequency arrives before or after the default slice gets created)
Threading / Shutdown (if such a category exists — to see which thread(s), if any, fail to terminate)
Suggested reproduction aid: if there's no explicit shutdown/thread-teardown logging category yet, it may be worth adding one, since "process survives after UI close" is otherwise very hard to catch after the fact — by the time the user notices it in Task Manager, the relevant state (which thread didn't join, whether save() ran) is already gone.
What did you expect?
Expectation was for VFO to remain where I last was using, as well as not resetting my RX EQ settings.
Steps to reproduce
Unable to reproduce consistently.
AetherSDR version
26.7.2
Radio model & firmware
AU-510 (4.2.20.41343)
Operating system
Windows
OS version and hardware
Windows 11 Home, 10.0.26200 N/A Build 26200
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/core/AppSettings.h/.cpp, src/models/RadioModel, src/models/SliceModel, and shutdown handling in src/gui/MainWindow. Enable Settings/Persistence, Connection/Protocol, and Threading/Shutdown logging, then inspect save completion, reconnect timing, default-slice creation, and thread teardown. Done means the process exits cleanly and the reported RX EQ and VFO resets no longer occur.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 43/100