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: Scheduled event "Tune to Frequency" updates RX/TX frequency but slice display remains on previous frequency; also drops window from Maximized

What happened?

When a scheduled net (created via the new Schedule feature) fires its reminder and I click the "Tune to Frequency" action in the popup, two things go wrong:

1. Slice display desync. AetherSDR correctly switches to the right band and mode, but the slice's on-screen frequency readout stays on whatever frequency was last used on that band — it does not update to show the scheduled net's frequency. However, the radio itself is not actually on the displayed frequency: RX and TX are both happening on the correct scheduled frequency. So the GUI is lying about where I am tuned, even though the hardware is in the right place. This is dangerous from an operating standpoint — if I trust the display, I could call a net at the wrong displayed QRG, or be confused about where I actually am if I need to verify against a published net frequency.

2. Window mode change. Independently, whenever the band/mode switch triggered by the scheduled tune happens, AetherSDR drops out of Maximized and resizes to a smaller window. This isn't tied to manual band changes — it specifically seems to coincide with the scheduled "tune to frequency" action.

What did you expect?

• Clicking "Tune to Frequency" from the schedule reminder should send the actual scheduled frequency to the radio and update the slice's displayed frequency (RF_frequency) to match, so the GUI accurately reflects what the radio is doing at all times.
• The window should remain in whatever state it was in (Maximized) before the scheduled tune occurred — band/mode/frequency changes shouldn't affect window geometry/state at all.

Steps to reproduce

1. Open the new Schedule feature and create a scheduled event for a net, specifying a frequency/mode that differs from whatever was last used on that band.
2. Maximize the AetherSDR window.
3. Wait for (or trigger) the scheduled reminder popup.
4. Click "Tune to Frequency" (or equivalent action) in the reminder prompt.
5. Observe: band and mode change correctly; the window un-maximizes to a smaller size.
6. Observe: the slice frequency readout shows the previous frequency used on that band, not the scheduled net frequency.
7. Verify actual operating frequency — e.g. by checking the waterfall/panadapter center, or by listening/transmitting and comparing against another receiver — confirming RX/TX are actually on the scheduled net frequency, not the displayed one.

Radio model & firmware

FLEX-6400, firmware 4.2.18.41174

OS & version

Windows, AetherSDR 26.6.5, Qt 6.8.3

Developer Notes

This looks like two separate bugs triggered by the same code path, most likely both rooted in whatever handler the Schedule feature uses to execute "Tune to Frequency."

1. Slice display desync (likely root cause)

Per CLAUDE.md, click-to-tune and programmatic tuning should go through slice m <freq> pan=<panId> (or the slice-targeted tune command), and the radio is authoritative for frequency — the displayed RF_frequency should only ever be updated by an incoming status echo, never assumed locally. Two plausible failure modes:

• The scheduler is sending the tune command to the wrong/wrong-type target. If the schedule feature's tune action calls a band/mode-select path (e.g. something that issues slice set <id> RF_frequency=... or a "select band" helper) but routes the frequency portion through a different code path than the normal click-to-tune flow (which uses slice m <freq> pan=<panId>), the radio could end up tuned correctly via one command while the GUI's optimistic/local update logic touches a stale cached value for display. This matches the "RX/TX is right, display is wrong" symptom.
• m_updatingFromModel / QSignalBlocker guard suppressing the real status echo. Per the GUI↔Radio Sync pattern in CLAUDE.md, model setters that originate from the scheduler might be flagged as "from model" to avoid an echo loop, which would block the legitimate S<handle>|slice <n> RF_frequency=... status update from refreshing the displayed VFO digits, even though the radio did send it and the radio's actual state is correct.
• Likely files: src/models/SliceModel.* (look at the setter for RF_frequency and how it interacts with applyStatus), and whatever new file backs the Schedule feature — likely something like src/gui/ScheduleDialog.* / src/core/ScheduleManager.* (not present in the architecture doc above, so probably new since the doc was last updated — worth confirming the actual filename in the current tree). Check the function that handles the "Tune to Frequency" button/action specifically for whether it calls the same code path as normal click-to-tune (MainWindow/SpectrumWidget click-to-tune handler) or a separate, possibly incomplete, path.

2. Window leaves Maximized state

Given the FramelessWindow / dialog-geometry-persistence patterns described in CLAUDE.md (docs/dialog-patterns.md), if the scheduled tune action opens or re-triggers a dialog/popup (the reminder prompt itself, or some band-change confirmation), and that dialog's show/restore logic touches MainWindow geometry instead of its own — e.g. a stray restoreGeometry()/showNormal() call meant for the popup but applied to the top-level window — that would explain the Maximized-to-smaller-window symptom. Worth checking:

• The reminder/popup dialog class's show()/exec() logic for any call that affects MainWindow rather than itself.
• Whether the band-change triggered by the scheduler calls a layout/panadapter-stack rebuild (PanadapterStack, wirePanadapter()) that inadvertently resets window state as a side effect of recreating panadapter widgets.

Logging to capture (Help → Support → enable before reproducing):

• Protocol/command logging (to confirm exactly which C-prefixed tune command(s) the scheduler sends, and what S-prefixed status the radio echoes back — this will show definitively whether the radio's RF_frequency status differs from what the GUI displays)
• GUI/model sync logging if available (to see whether the status echo is being received but suppressed by an update-guard)
• Window/geometry logging if available (to see what triggers the un-maximize)

A Wireshark capture spanning the schedule popup → "Tune to Frequency" click → post-tune state would make this trivial to pin down, since it will show whether the radio actually echoes the new RF_frequency and, if so, why the GUI isn't applying it.

aethersdr-20260629-214258.log

support-bundle-20260629-214645.zip

What did you expect?

No response

Steps to reproduce

Schedule event (e.g. net) with frequency, mode, time.
Ensure frequency currently displaying is different to frequency in scheduled event.
Select a different band/mode etc. prior to schedule reminder appearing.
When reminder appears, allow it to set AetherSDR for the event.
Note slice position and displayed frequency.
Trigger TX and note where TX appears on panadapter. Listen for a signal at that frequency and confirm it's not what is being received at the displayed slice and slice frequency. i.e., radio will be receiving and transmitting at the scheduled frequency, not at the displayed slice frequency.

AetherSDR version

26.6.5

Radio model & firmware

Flex 6400 4.2.18

Operating system

Windows

OS version and hardware

Windows 11