Unable to play to group because of "Please check that all remotes in the group are online" error
PureTryOut opened this issue · 8 comments
Both servers present are online and can play audio just fine when send to it individually, just not through a group.
Reproduced the issue, will have a look at it.
Interesting symptoms so far: it works with the slave remote in a local VM (bridged networking), but I get the error when the slave remote is on dedicated hardware (Raspberry Pi Zero W). Since everything in this failing configuration uses WiFi, I'm leaning towards a time-out issue, but will keep investigating.
I'm also doing it over Wi-Fi so that seems plausible
The problem appears to be the auto-detected IP addresses in the list of slave remotes that get handed to the master remote. I had the multi-room playback working just fine earlier on the aforementioned Raspberry Pi Zero W, in sync with the master remote on the Win10 laptop, all via WiFi.
Looking at the previous non-working playback attempt on these devices, here the Win10 laptop's IP was the VirtualBox virtual IP address (host-only network), while the Raspberry Pi Zero W's IP was that of the WiFi network.Obviously, if the Win10 laptop is the master in this scenario, it can use the RPi0W as slave, but vice versa does not work, since the VBox host-only network is not accessible from the RPi0W.
Theoretically, this is a scenario that should not occur when e.g. running the Player on another system on the (WiFi) network, but which can be problematic when running the Player on the same system as one of the group remotes. A possible solution here would be to keep track of the different IPs per server remote, and match them up per network range when put into a group. Though that may backfire in other fun ways.
This may take some thought :)
Ah. I am indeed running the player/client on the same machine as one of the remotes. I did notice it showed 127.0.0.1 as it's IP but did not realize that would be a problem. Makes sense though, the remotes ofc have to communicate with each other to make sure the playback is synced and what not.
I suppose it's a bit of an edge case, but then again I'm guessing it'll be relatively common.
It would definitely be an issue whenever using the client on the same system as a remote that's part of a group, yes.
I'm still looking at an elegant solution for this that covers all cases. Incidentally it's also a potential issue with the NymphCast MediaServer when it runs on the same system as a remote, though that should be an uncommon issue outside of testing. Still, good to tackle that one at the same time :)
I have implemented a change in the Group dialogue. This should keep a local remote (hostname == local hostname) always as the first item in the first position of the list, and thus as the master remote.
Currently it only checks for this when creating a new group or when adding a new remote to a group, which seems sufficient to me, but feel free to think of further use cases :)