I'm experiencing an issue with AetherSDR, a Linux/macOS/Windows SDR client
for FlexRadio transceivers (https://github.com/aethersdr/AetherSDR).

My system:

• AetherSDR version: 26.6.5
• Qt version: 6.8.3
• OS: Windows
• Radio: FLEX-8400M fw 4.2.20.41343

support-bundle-20260629-092635.zip

What happened?

DX Spot markers are expected to display the associated spot information when the mouse hovers over them.

Currently, this only works when the spot marker is positioned on or near the slice carrier frequency, where the callsign text extends at least partially outside the slice filter region. In that case, hovering over the visible callsign displays the tooltip correctly.

However, when the DX Spot marker is located completely within the slice filter passband, hovering over the spot does not display any tooltip or spot information. This makes spots inside the filter impossible to inspect with the mouse, while otherwise identical spots outside or partially outside the filter behave correctly.

This appears to be related to hit-testing or mouse event handling for spot overlays when they overlap the filter rendering.

What did you expect?

Hovering over a DX Spot should display its tooltip regardless of whether the spot lies:

• On the carrier frequency
• Partially inside the filter
• Completely inside the filter passband

The filter overlay should not prevent hover detection of DX Spot markers.

Steps to reproduce

1. Connect to a FLEX-8400M.
2. Enable DX Spots.
3. Tune so that a DX Spot falls completely inside the slice filter bandwidth.
4. Hover the mouse over the spot.
5. Observe that no spot information is displayed.
6. Move or retune so the same spot is positioned on the carrier or partially outside the filter.
7. Hover over the spot again.
8. Observe that the tooltip is displayed correctly.

Radio model & firmware

• Radio: FLEX-8400M
• Firmware: 4.2.20.41343

OS & version

• OS: Windows
• AetherSDR: 26.6.5
• Qt: 6.8.3

Developer Notes

Based on the project architecture, this issue is most likely in the panadapter rendering and mouse hit-testing path rather than the spot data model itself.

Areas worth investigating include:

• src/gui/SpectrumWidget* (mouse move, hover, overlay hit-testing, tooltip handling)
• src/gui/MainWindow_Spots.cpp (spot lifecycle and UI wiring)
• Any DX Spot overlay or rendering classes responsible for painting spot markers and determining hover targets
• Rendering order and event handling between the filter overlay and DX Spot overlay

The symptoms suggest one of the following:

• The filter overlay is intercepting or obscuring mouse hit-testing before it reaches the DX Spot overlay.
• Hit-testing is performed only against the visible callsign text rather than the complete spot marker.
• The hover region is clipped when the spot lies inside the filter area.
• Z-order/render-order and mouse-hit order are inconsistent, allowing painting but preventing hover detection.

For diagnostics, enable the following logging categories from Help → Support:

• Commands
• Status
• Discovery

While this issue appears to be entirely client-side, these logs can confirm that the spot data is present and unchanged while reproducing the hover behavior. Additional debug logging around SpectrumWidget mouse-move processing and DX Spot hit-testing would likely be the most useful for isolating the failure.

The project architecture places panadapter rendering and interaction in SpectrumWidget, with MainWindow responsible for wiring spot-related UI components into the application. The hover failure appears consistent with a UI hit-testing issue rather than a SmartSDR protocol or radio-status problem. ([raw.githubusercontent.com]1)