Jörg B
Member
Version: RadioBOSS Ultimate (current stable, x64), Windows 11 Pro 25H2 (Build 26200)
Symptom
On a fresh install with the Remote Control feature enabled in Settings (Remote Enable = on, port = 9000, Localhost
only = off, one user defined under RemoteUsers with username + password and upAdmin permission), RadioBOSS does not
open the listening socket at all. netstat -ano shows zero LISTEN entries for the radioboss.exe process, including
127.0.0.1. No error dialog, no entry in startup.log, no bugreport_*.txt is written. The API is simply absent.
Reproduction
1. Fresh install RadioBOSS Ultimate on a clean Windows.
2. Enable Remote Control in Settings, set port and at least one RemoteUser, leave the global "Password" field blank.
3. Restart RadioBOSS.
4. netstat -an | findstr :9000 returns nothing. Local connect to http://127.0.0.1:9000/ times out.
Root cause (found by config diff)
A working installation has this block in player.ini:
RemoteEnable = True
RemotePort = 9000
RemotePassword = '<something>'
RemoteLocalhostOnly = False
RemoteUsers = <
item
Username = '...'
Password = '...'
Permissions = [upAdmin]
end>
A non-working installation has the identical block but without the RemotePassword line. As soon as a value is entered
in the global Password field in the Remote Control settings dialog (or the line is added manually to player.ini), the
API starts on the next launch and binds the configured port normally.
Expected behaviour
Either:
- The Remote Control module starts even without a global RemotePassword, as long as at least one RemoteUser with a
password is defined, or
- RadioBOSS writes a clear error to startup.log / bugreport when the API initialization is aborted because of a
missing required field, or
- The Settings dialog refuses to save the configuration with empty global password while RemoteUsers exist.
Currently it silently does nothing, which makes the issue practically invisible.
Notes
Tested with port 9000 and 9005 — same behaviour either way, so it is not a port reservation. Tested after full
uninstall + reinstall + AppData wipe — same behaviour. Tested with x86 build — same behaviour. Smart App Control off,
no AppLocker, no WDAC blocks, no Defender exclusions needed. Pure config-side issue.
Symptom
On a fresh install with the Remote Control feature enabled in Settings (Remote Enable = on, port = 9000, Localhost
only = off, one user defined under RemoteUsers with username + password and upAdmin permission), RadioBOSS does not
open the listening socket at all. netstat -ano shows zero LISTEN entries for the radioboss.exe process, including
127.0.0.1. No error dialog, no entry in startup.log, no bugreport_*.txt is written. The API is simply absent.
Reproduction
1. Fresh install RadioBOSS Ultimate on a clean Windows.
2. Enable Remote Control in Settings, set port and at least one RemoteUser, leave the global "Password" field blank.
3. Restart RadioBOSS.
4. netstat -an | findstr :9000 returns nothing. Local connect to http://127.0.0.1:9000/ times out.
Root cause (found by config diff)
A working installation has this block in player.ini:
RemoteEnable = True
RemotePort = 9000
RemotePassword = '<something>'
RemoteLocalhostOnly = False
RemoteUsers = <
item
Username = '...'
Password = '...'
Permissions = [upAdmin]
end>
A non-working installation has the identical block but without the RemotePassword line. As soon as a value is entered
in the global Password field in the Remote Control settings dialog (or the line is added manually to player.ini), the
API starts on the next launch and binds the configured port normally.
Expected behaviour
Either:
- The Remote Control module starts even without a global RemotePassword, as long as at least one RemoteUser with a
password is defined, or
- RadioBOSS writes a clear error to startup.log / bugreport when the API initialization is aborted because of a
missing required field, or
- The Settings dialog refuses to save the configuration with empty global password while RemoteUsers exist.
Currently it silently does nothing, which makes the issue practically invisible.
Notes
Tested with port 9000 and 9005 — same behaviour either way, so it is not a port reservation. Tested after full
uninstall + reinstall + AppData wipe — same behaviour. Tested with x86 build — same behaviour. Smart App Control off,
no AppLocker, no WDAC blocks, no Defender exclusions needed. Pure config-side issue.
