Thanks for the clear report — the screenshot with the field names made this immediate to find.
Confirmed, and this is my regression in v1.6.1. The panel records which one-off data migrations have already run, and it stores those records alongside your settings. The settings page loads everything it finds there and sends it all back when you save, but v1.6.1 added a stricter check on what may be saved — and those records are not settings, so the save is refused.
It affects every v1.6.1 install, not only upgrades, because those records are written on first start even when there is nothing to migrate. Nothing in your configuration is damaged: the save is refused before anything is written.
Fixed for the next release: the settings page is no longer handed anything that is not a setting. There is a test for it now, so a future migration cannot bring this back.
Until then, you can change settings through the API, which is not affected. For example, to change the subscription update interval:
curl -X POST -H "Token: <Your API Token>" \
-d "object=settings" -d "action=set" \
-d 'data={"subUpdates":"6"}' \
"http://localhost:2095/app/apiv2/save"
Send only the keys you want to change; the rest keep their values. The setting names are listed here:
https://github.com/alireza0/s-ui/wiki/Settings-Reference
