Settings changes do not save [BUG]

[yozhin]

Describe the bug

Tried to enable Accessibility arrows for VF-O. They do not appear, and settings do not save after six or seven attempts.

Steps to reproduce

1. Connected to radio
2. Went to settings-Accessibility-Moved slider to "on"-Scroll down-Clicked "save settings"

Expected behaviour

Should show arrows next to frequency

Actual behaviour

No arrows shown

Diagnostics

Device name YURISIVITSKCF52
Processor Apple Silicon (3.07 GHz) (4 processors)
Installed RAM 8.00 GB
Device ID 214844CC-2EA8-483F-8674-0E7CD5842255
Product ID 00330-80000-00000-AA003
System type 64-bit operating system, ARM-based processor

Edition Windows 11 Pro
Version 25H2
Installed on ‎11/‎18/‎2025
OS build 26200.7171
Experience Windows Feature Experience Pack 1000.26100.265.0

YWC Version    2.4.0 (released 2026-07-10)
Radio model    FTdx10
Band plan      Region2
Serial port    COM4 at 38400 baud
Connection     connected
SDR device     (none configured)
DX cluster     (off)
Cluster login  (blank)
Browser        Microsoft Edge 150
.NET runtime   10.0.9
Operating sys  Microsoft Windows 10.0.26200
CPU            Apple Silicon, 4 logical cores
Memory         8 GB
Tested fw      FTdx101MP: Main=V01-28 Display=V01-51 MainDSP=V01-20 SubDSP=V01-20 MainSDR=V02-08 SubSDR=V02-08 AFDSP=V01-00

Screenshots / logs

(Drag-and-drop screenshots here. Any F12 console errors below.)

Anything else?

[mm5agm]

Thanks for the detailed report and diagnostics — that made this quick to track down.

Found it: there's a text field on the Settings page (SDRplay install path, under SDR Spectrum Display) that's blank by default for anyone without an SDR configured — which matches your setup exactly ("SDR device: none configured"). A bug in how that field was declared meant the browser silently blocked the entire Settings form from submitting whenever it was empty, with no visible error message. So it wasn't specific to the arrow-buttons toggle — any change on that page would have hit the same wall for you.

Fixed on develop now; it'll be in the next pre-release.

If you want the arrows sooner rather than waiting: on the Settings page, under "SDR Spectrum Display," type any single character into the "SDRplay install path (advanced)" box (you can leave it as junk — it's unused when no SDR is configured) and hit Save. That should unblock the whole form and let the Accessibility toggle save too. Not pretty, but it'll work until the real fix ships.

Thanks again for reporting — first-time reporters catching something like this is exactly the kind of feedback that's most useful right now.

[iu1teu]

I've got the same problem, tried the "SDRplay install path..." fix without success.
My configuration:

YWC Version 2.4.1 (released 2026-07-10)
Radio model FTDX3000
Band plan Region1
Serial port COM5 at 38400 baud
Connection connected
SDR device (none configured)
DX cluster (off)
Cluster login (blank)
Browser Microsoft Edge 150
.NET runtime 10.0.9
Operating sys Microsoft Windows 10.0.26200
CPU Intel(R) Celeron(R) N5105 @ 2.00GHz, 4 logical cores
Memory 7,8 GB
Tested fw FTdx101MP: Main=V01-28 Display=V01-51 MainDSP=V01-20 SubDSP=V01-20 MainSDR=V02-08 SubSDR=V02-08 AFDSP=V01-00

[mm5agm]

Hi @iu1teu,

Thanks for the diagnostics — that's a good clean report. One thing worth ruling out first: did you have the Settings page already open in a browser tab from before you upgraded to v2.4.1? If so, that tab is still running the old page's validation code even though the server underneath it changed. Could you try:

1. Close that tab completely
2. Do a hard refresh (Ctrl+F5) or just open Settings fresh in a new tab
3. Try Save again

If it still doesn't save, could you tell me:

• Does clicking Save show any message at all (green "✓ Settings saved" or red "❌" banner), or does nothing visibly happen?
• Any errors in the browser console? (Press F12, click the Console tab, try Save, and paste anything red that appears)

That'll tell us whether this is the same root cause re-appearing somewhere I haven't found yet, or something specific to your setup. Sorry for the extra round-trip — want to get this actually nailed down for you.

73, Colin

[iu1teu]

Hi @iu1teu,

Thanks for the diagnostics — that's a good clean report. One thing worth ruling out first: did you have the Settings page already open in a browser tab from before you upgraded to v2.4.1? If so, that tab is still running the old page's validation code even though the server underneath it changed. Could you try:

1. Close that tab completely
2. Do a hard refresh (Ctrl+F5) or just open Settings fresh in a new tab
3. Try Save again

My 2.4.1 is a fresh install, no upgrade.

If it still doesn't save, could you tell me:

• Does clicking Save show any message at all (green "✓ Settings saved" or red "❌" banner), or does nothing visibly happen?
• Any errors in the browser console? (Press F12, click the Console tab, try Save, and paste anything red that appears)

Nothing visibly happen, no error or red banner.
The console show the error:

Yaesu_Web_Control.styles.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)

After trying to save:

GET http://localhost:8080/Yaesu_Web_Control.styles.css net::ERR_ABORTED 404 (Not Found)

73 de' IU1TEU - Giovanni

[mm5agm]

Hi Giovanni,

Thanks — that CSS 404 is a red herring, sorry for the noise: that file has never actually existed in any version of YWC (leftover reference to a feature the project doesn't use), so it 404s for every user on every page load. Not related to your issue.

"Nothing visibly happens" is the useful bit though — that suggests the Save click might not even be reaching the server. Could you check one more thing:

1. Open DevTools (F12) → Network tab
2. Click Save
3. Look for a request to Settings (POST) in the list

Two possibilities:

• No POST appears at all — the browser is silently blocking the submit client-side (same family as the original bug, just a field I haven't caught yet). If so, can you screenshot or copy the full Settings page HTML (right-click → View Page Source) so I can see exactly which field still has a required attribute on it?
• A POST does appear — what status code does it return (200, 302, 500)? Click it and check the Response tab for anything useful.

That'll tell us which half of the problem we're in. Thanks for bearing with the back-and-forth — this one's clearly real and I want to run it down properly.

73, Colin

[mm5agm]

Quick follow-up to make the Network tab less overwhelming, Giovanni:

1. Open DevTools (F12) → Network tab
2. Tick "Preserve log" (checkbox near the top of the panel) — a Save click causes a full page navigation, and without this the list clears itself right when the request you want happens
3. Click the trash icon to clear anything already there
4. Click Save
5. In the filter box, type Settings (or click the Doc filter button) to cut out all the CSS/JS/image noise and leave just the page requests

That should leave one or two rows instead of fifty. Whatever shows up for the Settings POST (or the fact that nothing shows up at all) is exactly what I need to see.

73, Colin

[iu1teu]

localhost.txt

The saved (filtered) file of the two Settings row.
The original file extension is .har.

[mm5agm]

Thanks for the HAR file — that gave us a definitive answer, and digging further turned up something genuinely useful.

Your save did work. The POST to /Settings comes back with a clean 302 redirect (success), and the page that loads right after it contains the green "✓ Settings saved successfully." confirmation banner. Your submitted values are all there — RadioModel=FTDX3000, SerialPort=COM5, BandPlan=Region1, and the rest — exactly matching what you configured. The v2.4.1 fix is working correctly for you; nothing failed server-side.

Why it looked like nothing happened, part 1: that confirmation banner only appears right at the very top of the page, and Settings is a long page with a lot of collapsible sections. If you're scrolled down editing something when you click Save, it's easy to miss the banner entirely even though it's there. I'm going to make it float/stay visible regardless of scroll position so this can't trip anyone else up.

Why it looked like nothing happened, part 2 — and this is the interesting one: changing the COM port specifically doesn't actually take effect until the app is restarted, and the app currently gives you no warning about that. If the radio connection is already open on the old port when you save a new one, the reconnect logic silently keeps using the old port instead of switching — so even though your setting saved correctly, the app kept talking to COM3 (or whatever it started on) instead of COM5. Restarting the app fully will pick up the new port.

That second issue is a genuinely obscure bug, and you're the one who surfaced it — thank you for that, and for sticking with the diagnosis and sending the HAR. It's a real fix on our side (either make the reconnect actually honour a changed port, or at minimum warn you that a restart is needed), and it'll be in the next pre-release/release.

For now: please restart the app after saving a new COM port, and let me know if that gets you connected.

[iu1teu]

Unfortunately, I restarted the app several times and nothing happens; tha app appears connected but it keep redirecting me to the Settings page and so on...
I recorded a screencap video, download it here (I cannot add on this page): https://we.tl/t-Avn2TAKP9S1BoUcV

[mm5agm]

I watched your video description carefully, thank you — that's very clear and points to something specific.

One thing worth saying: you're the first FTDX3000 owner to actually put this through its paces. Everything I've built for the FTDX3000 so far has been from reading Yaesu's CAT manual, without a real radio to test against — your testing is what will actually prove the FTDX3000 support works, rather than it just being my best guess at the manual. Genuinely appreciate you sticking with this.

What's happening: the screen you see right at startup (20m, FT8, 14.074) is just showing what YWC remembered from last time, not a live connection yet. The real connection sequence runs in the background afterwards, and something in it is throwing an error specific to the FTDX3000 — that's what causes the "Comm port error" message and the bounce to Settings. Test Connection succeeds because it only does a quick radio-ID check, not the full sequence, so it doesn't hit the same problem. And once that error flag is set, Home and Cancel keep sending you back to Settings until a full connection sequence actually succeeds — a separate bug I'll also fix, since you should never get stuck like that regardless of the cause.

I have a strong suspicion where the actual fault is, but I'd like to confirm it from the app's log rather than guess. Could you do this for me:

1. Close YWC completely.
2. Go to %APPDATA%\MM5AGM\Yaesu Web Control\logs (paste that into File Explorer's address bar).
3. Delete (or rename) today's log file — it'll be called something like ywc-20260711.log. Since you've restarted several times today, that file will be large and it'll be much easier for me to find the fault in a fresh one.
4. Start YWC once, let it fail and bounce to Settings as usual, then close it again.
5. Send me the new ywc-20260711.log that gets created.

That should have just the one failed attempt in it, which will show me exactly what's throwing the error.

[iu1teu]

Here you are:

ywc-20260711.log