On restart, AetherSDR restores persisted broken panadapter state instead of defaulting to single-pan safe mode

[chibondking]

On restart, AetherSDR restores persisted broken panadapter state instead of defaulting to single-pan safe mode

Labels: bug, GUI, priority: medium
Related: multi-panadapter FFT/waterfall broken state issue (filed separately)
Related: #152 (multi-panadapter support)

---

What

When AetherSDR is restarted after a session where the second panadapter was
in a broken state (FFT blank, not closeable), it restores the broken
panadapter layout from persisted settings rather than defaulting to a
clean single-panadapter state. The user is immediately back in the broken
state with no path to recovery short of manually editing the settings file.

---

Why This Happens

AetherSDR persists panadapter layout state (number of open pans, pan IDs,
geometry) across sessions via AppSettings. On restart, it reads this
state and attempts to recreate the saved layout. When the saved layout
includes a panadapter that was corrupt at save time, the corruption is
faithfully reproduced on the next launch.

This is a fundamental dirty-state persistence problem: the app saves
whatever state it is in at shutdown — including broken states — and
unconditionally restores it on startup, with no validation that the
persisted state is actually healthy.

---

Why It Matters

A user who encounters the broken-panadapter bug (filed separately) and
restarts AetherSDR expecting a clean slate instead finds themselves in the
same broken state immediately. The restart that should be the recovery
path becomes a trap. Combined with the inability to close the faulty pan
from the UI, the user has no in-app recovery option at all.

---

How SmartSDR Handles It

SmartSDR for Windows never persists multi-panadapter layout client-side.
On connect, it requests the radio's current panadapter state and builds the
UI from live radio data only. If the radio reports only one panadapter,
SmartSDR shows one — regardless of what the previous session looked like.
There is no "dirty load" because there is no client-side layout persistence
to go stale. The radio is the single source of truth for panadapter count
and configuration.

---

The Design Tradeoff

This is a conscious architectural decision with two valid positions:

Option A — Radio as source of truth (SmartSDR approach)

On connect, request panadapter state from the radio (sub pan all) and
build the UI entirely from the radio's response. Do not persist panadapter
count or pan IDs client-side. If the radio reports one pan, show one. If it
reports two, show two.

• Pro: can never load a stale or corrupt layout. Always reflects actual
  radio state.
• Con: loses any client-side display preferences (zoom, dBm range,
  waterfall speed) that the radio does not store. These would need to be
  re-applied heuristically (e.g. by pan frequency match) on reconnect.

Option B — Persist with validation (safer client-side persistence)

Continue persisting layout client-side but add a health check on load:
before restoring a saved panadapter, verify that the radio actually has a
live panadapter with that ID. If validation fails, silently discard the
saved pan and default to single-pan layout.

// In RadioModel or PanadapterStack — on connect, after sub pan all
for (const auto& savedPanId : savedPanIds) {
    if (!m_activePanIds.contains(savedPanId)) {
        // Radio doesn't know about this pan — don't restore it
        AppSettings::instance().remove("Pan2Id");  // clean up stale entry
        continue;
    }
    restorePanadapter(savedPanId);
}

• Pro: preserves client-side display preferences across sessions.
• Con: more complex; validation logic must be correct or it silently
  discards valid state.

Option C — Fail safe, no alert (recommended minimum)

Regardless of which option is chosen for the long term, implement an
immediate fail-safe fallback: if any panadapter fails to initialise
correctly on load (FFT stream not arriving within a timeout, stream ID
not confirmed by the radio, widget in error state), silently drop that
pan and continue with a single-pan layout. No popup, no error dialog —
consistent with SmartSDR's behaviour. The user gets a working app rather
than a broken one.

---

Suggested Behavior (Recommended: Option C now, Option A or B later)

Immediate fix (Option C)

Add a startup health check in PanadapterStack or RadioModel: after
connect and after VITA-49 streaming begins, verify each restored panadapter
has received at least one valid FFT frame (PCC 0x8003) within a
reasonable timeout (e.g. 5 seconds). If a pan fails this check:

1. Silently remove it from the layout.
2. Clean up its persisted state from AppSettings so it does not come
   back on the next restart.
3. Log a diagnostic message (no user-facing alert).

Long-term (Option A or B — design decision for Jeremy)

Decide whether panadapter layout should be radio-authoritative (Option A)
or client-persisted-with-validation (Option B). This decision affects
AppSettings key design for pan state, the wirePanadapter() / reconnect
flow, and how client-side display preferences (zoom, gain, black level) are
associated with pans across sessions.

---

Protocol Hints

Confirming live panadapter IDs from radio (on connect)

sub pan all

The radio responds with display pan <id> status objects for each active
panadapter. The set of IDs in these responses is the ground truth for what
pans actually exist. Any persisted pan ID not in this set should be
discarded on load.

Confirming FFT stream is live (health check)

A panadapter is healthy if PCC 0x8003 packets for its stream ID arrive
within ~5 seconds of client udpport registration. If no packets arrive,
the radio is not streaming FFT for that pan and the pan should be
considered invalid.

Relevant source locations

• src/core/AppSettings — pan layout persistence keys (pan count, pan
  IDs, geometry); identify which keys need to be cleared on failed load
• src/gui/PanadapterStack — pan creation on startup; add health check
  timeout per pan; silent removal of failed pans
• src/models/RadioModel — sub pan all response handling; expose set
  of live pan IDs for validation against persisted state
• src/core/PanadapterStream — FFT packet arrival; add per-pan
  "first frame received" signal for health check timeout logic

[chibondking]

@ten9876 putting on my product manager hat here, I would weigh option A from Claude, since there's no pressure. Everyone knows the software is under rapid dev. Also, if you want to reach out, my email is good on qrz, but: wt2p@cedrick.io (my nginx server is down right now, i'm in the process of moving.. LOL)

Tell the radio X... It does X, you reflect that in your client, across all platforms.

[ten9876]

We're going to go for an even more basic state for now....always launch to a single pan layout. There's a ton of regressions that we need to work through now that we've refactored to multi-pan architecture. Will work through those and then worry about QoL stuff like persisting multi-pan state across launches.

[ten9876]

Fixed in 153594c.

Root cause

We were creating pans on startup via display panafall create to match the saved layout. But the radio already restores all pans from the GUIClientID session — confirmed from SmartSDR pcap showing 3 pans restored by the radio at t=3.4s before any client command.

Our applyPanLayout was creating ADDITIONAL pans on top of the radio's restored pans, causing duplicates and broken state that persisted across restarts.

Fix: radio-authoritative pans, client-authoritative layout

• Radio decides how many pans exist — we accept whatever it restores
• Client decides how they're arranged — we rearrange the splitter based on the saved layout preference
• No display panafall create or display pan remove on startup
• If the saved layout doesn't match the pan count the radio gave us, we pick a sensible default arrangement

73, Jeremy KK7GWY & Claude (AI dev partner)

[jensenpat]

Cross-reference: PR #3316 (for #3212) fixes a remaining instance of this same root cause in a path the 153594c fix didn't cover.

153594c made the layout-restore path radio-authoritative — no more display panafall create to match a saved layout. But the slice list-empty branch in RadioModel::registerAsGuiClient still carried the original assumption: when the radio restores our panadapter but drops its slice (seen after an unexpected disconnect → auto-reconnect), slice list returns empty and that branch ran createDefaultSlice() → display panafall create, re-creating the duplicate pan from a different direction (net: 2 pans, 1 slice).

#3316 reuses the already-restored pan instead. Confirmed against the #3212 support bundle (pan 0x40000000 claimed 1.8 s before the empty slice list).