I’m running balenaSound 3.11.0 on a fleet of Raspberry Pi units. Two of them (living room server and kitchen) work correctly. The third unit (bathroom, Pi 3B) consistently fails to start multiroom-server due to a port conflict with multiroom-client.
The problem
On every boot, multiroom-client starts before multiroom-server and claims ports 1704, 1705, and 1780. When multiroom-server then tries to start, it fails with:
driver failed programming external connectivity on endpoint multiroom-server:
Error starting userland proxy: bind 0.0.0.0:1705: address already in use
This makes the supervisor enter a locked state, making remote reboots impossible. The only workaround is manually stopping multiroom-client via terminal, starting multiroom-server, then restarting multiroom-client — every single boot.
Setup
-
Hardware: Raspberry Pi 3B
-
balenaSound: 3.11.0+rev1
-
SOUND_MODE: MULTI_ROOM
-
SOUND_DISABLE_BLUETOOTH: 1
-
AUDIO_OUTPUT: alsa_output.platform-3f00b840.mailbox.stereo-fallback
-
BALENA_HOST_CONFIG_dtoverlay: vc4-fkms-v3d,cma-320
-
SNAPCAST_SERVER: 192.168.129.10 (fixed IP of server unit)
What I’ve tried
-
Fresh reflash of SD card — problem persists
-
Manually stopping multiroom-client before starting multiroom-server — works but not persistent
-
Restarting balena_supervisor — sometimes helps temporarily
Question
Is there a way to enforce startup order so multiroom-server always starts before multiroom-client? Or is there a configuration to prevent multiroom-client from exposing ports 1704/1705/1780 on client-only units?
