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?

Bug: Tuning Step Setting Resets to Smallest Value After Upgrading to a New Version

What

After installing a new version of AetherSDR, the tuning step size (shown in the
RX applet's step stepper) silently reverts to the smallest available value (10 Hz)
instead of the value the user had previously configured. The saved step preference
appears to be ignored on first launch after an upgrade.

As a workaround, if the user manually opens the step stepper and re-selects the
same value they want (e.g. picks 1000 Hz when it already reads 1000 Hz, or
sets it away and back), the setting takes effect correctly and is used for tuning.
The bug is in the initial restore on launch, not in the stepper widget itself.

Why

The tuning step size is one of the most personal and frequently-used radio
preferences — CW operators typically use 10–100 Hz, SSB operators use 100–500 Hz,
and AM/wide-scan users may use 5–10 kHz. Having it silently reset to 10 Hz on
every upgrade is disruptive and easy to miss: the user may tune several steps
before noticing the frequency is moving in unexpectedly small increments.

The workaround (re-select the same value) is non-obvious and only discovered
by accident.

How Other Clients Do It

• SmartSDR for Windows: Per-slice step size is stored in the radio's own
  session state (linked to the client gui <UUID> session). It survives client
  restarts and upgrades automatically because it's radio-side, not client-side.
• SDRuno (SDRplay): Persists the last-used step size in its local config file.
  No reset on upgrade.
• GQRX: Saves tuning step in ~/.config/gqrx/default.conf; survives version
  upgrades because the key name is stable across releases.

The common pattern: persist the value under a stable key that survives upgrades.

Suggested Behavior

1. On launch (or reconnect), RxApplet reads the saved step size from
   AppSettings (key e.g. TuningStepHz or SliceStepHz_<sliceId>).
2. The step stepper widget is initialized to that value before any signal
   connections fire, so the first programmatic set matches the saved state.
3. Any time the user changes the step (via the stepper arrows or direct click),
   the new value is written to AppSettings immediately.
4. After a version upgrade the key must still be present and readable — i.e. no
   migration or rename should silently discard it.
5. The workaround behaviour (re-selecting the value causes it to work) should
   disappear: the value should be active from the moment the UI is shown.

Steps to reproduce the current bug:

1. Set tuning step to any value other than 10 Hz (e.g. 1000 Hz).
2. Close AetherSDR.
3. Install a newer version.
4. Launch the new version and connect to the radio.
5. Observe: step stepper shows (or silently uses) 10 Hz instead of 1000 Hz.
6. Workaround: open the step stepper, select 1000 Hz — now it works.

Protocol Hints

The tuning step size is client-side only — it is not sent to or stored by
the radio via any SmartSDR protocol command. No FlexLib/SmartSDR API call is
involved; this is purely an AppSettings persistence issue within AetherSDR.

Relevant code paths to investigate:

• src/gui/RxApplet — the step stepper widget initialization and
  syncFromSlice() / updateFromModel() path.
• src/core/AppSettings — verify the key name used to persist step has not
  changed between versions (a rename silently drops the saved value on upgrade).
• Check whether the step value is written to AppSettings when changed,
  or only at shutdown (a crash between change and shutdown would also lose it).
• The QSignalBlocker usage in RxApplet during model-sync may be masking
  the currentIndexChanged signal that would normally trigger the save.

Suggested AppSettings key (PascalCase per project convention):

// Write on change:
AppSettings::instance().setValue("TuningStepHz", QString::number(stepHz));

// Read on init (before connecting signals):
int stepHz = AppSettings::instance().value("TuningStepHz", "1000").toInt();

What did you expect?

stepsize not being ignored

Steps to reproduce

No response

Radio model & firmware

No response

Linux distro & Qt version

No response