search

MayaPosch / NymphCast

Audio and video casting system with support for custom applications.
http://nyanko.ws/nymphcast.php
BSD 3-Clause "New" or "Revised" License
2.43k stars 82 forks source link

Unable to play to group because of "Please check that all remotes in the group are online" error #80

Closed PureTryOut closed 7 months ago

PureTryOut commented 1 year ago

Both servers present are online and can play audio just fine when send to it individually, just not through a group.

MayaPosch commented 1 year ago

Reproduced the issue, will have a look at it.

MayaPosch commented 1 year ago

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.

PureTryOut commented 1 year ago

I'm also doing it over Wi-Fi so that seems plausible :thinking:

MayaPosch commented 1 year ago

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 :)

PureTryOut commented 1 year ago

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.

MayaPosch commented 1 year ago

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 :)

MayaPosch commented 1 year ago

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 :)

MayaPosch commented 7 months ago

Closing this issue as complete. Feel free to reopen or create new issue as needed.