aethersdr / aethersdr/AetherSDR

AetherSDR.exe not closing completely, Reset VFO & EQ

Open
#4,273 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

audio bug GUI maintainer-review Windows
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.