Its sounds crazy - but i had a RPI2 Zero working with RPI4, I then added another RPI2 Zero and now the two RPI2 Zeros will work as multi-room, and will control each other, however not the RPI4
This is happening in reverse as well.
They are on different versions - I just changed the version of supervisor on the RPI4 to be the same as the others - and am hoping this fixes things.
Thanks for any help, ideas or advice.
Ok, so the changing the supervisor means that the RPI4 is now able to control the 2 RP20 devices, however neither of these can control the RPI4, however they can control each other.
Is this normal behaviour? Is there some sort of hierarchy built in to control the system?
Seems very strange.
Again, thanks.
Hello, for the multi-room feature there can only be one master “controlling” any number of clients. The device you start streaming to will configure itself as the master, and any other devices on the same network should act as clients. You can see more details in the documentation here: Usage | Balena Sound
Thanks for this reply alanb128.
If I swap to another device and stream to THAT device should it not become the Master?
Am a bit confused about this - I thought that we could switch devices and the device we are streaming too becomes the master and all others the clients.
So when the devices come online which ever device I first stream too will become the master, so I need to reboot all of them and then start streaming to a different device for it to then become master?
Thanks for taking the time to help me understand this.
Guzzy.
Ok @alanb128, that documentation confirms that there is in fact a problem. When I switch to other devices they SHOULD become the “MASTER” and others the “CLIENTS” - however this is not happening.
Instead ONLY one pie is able to act as master of all devices, while the two RPI2ZERO devices can only become master of each other.
Here is the relevant part from your link
" Whenever you start streaming to any device in multi-room mode, it will auto-configure itself to be the master device and will broadcast a message to all other devices within your local network to get them in sync. Note that it can take a few seconds for the system to auto-configure the first time you stream. You can always change the master by streaming to a different device"
I wonder if there is a conflict between the two versions as the RPI2ZERO devices are on a different version?
This appears to be the only reason I can see. Maybe you have some other ideas.
Thanks for taking the time here.
Guzzy.
@guzzy are you sure all of the devices are on the same network? When you mention that the RPI2ZERO devices are on different versions, are you referring to the balenaOS version or the version of balenaSound? The OS version should not matter but it would be ideal if they are all on the same (latest) version of balenaSound.
Hi thanks again for getting back. I am running everything directly from the cloud, I can not see anything which refers to the BalenaSound version - where would this be?
All the services are on 3.9.6 and are tracking the latest version in the settings. All services are up to date on all devices.
Only thing that varies is the operating system as shown in the screen grab - this includes the supervisor etc - same.
Did some more testing - it appears that when you first cast to a device this sets itself as the master - and nothing can be changed from there on in. When selecting a different device as the master device this breaks the entire system.
I am not sure how long this takes to re-sync, or if we need to reboot the devices for them to be able to change Master/Client relationships, however this is what is happening.
Not sure how the relationship is established or how the system operates - it is VERY slow to coordinate changes in track lists etc. Is it using RabbitMQ or similar?
Is this a known problem? Should I run some tests to see when this happens (rebooting, leave for 5 minutes, etc)?
Thanks again for your time.
Guzzy.