mc_server_group_extend throws error if device is added with a dns name instead of ipaddress about aiomusiccast HOT 3 OPEN

For the time being, we only support the IP addresses for the grouping functionality, because the Yamaha devices expect an IP address provided, when we try to extend the group member list. As most users use the device discovery to add their devices, we are able to update the IP address of the device by using the serial number as single source of truth. However, we will take a look into that and see, whether it's possible to support hostnames.
Regarding your UDP problem when you use the IP address, I believe this could be related to the delays your network infrastructure leads to. We are using UDP messages to let the device tell us when something changes. And the device only sends us information about the kind of change so that we can then pull the correct information from the device. In case of grouping we have to send multiple requests and we have to wait until the device tells us that it is ready has processed the previous one. So there is some kind of structure like this:

1. HA HTTP -add group member-> Yamaha
2. HA <-updated group members- UDP Yamaha
3. HA HTTP -get group members-> Yamaha
4. HA HTTP -start distribution-> Yamaha

If we do not get the expected status information within one second, we log this message and send a request to the device. So it is like we skip step 2 from above and hope that the device is already ready. If it isn't, we try to repeat the whole process an additional time and if that fails we raise an exception (just like you had it when you were using the host names).
But maybe you have problems with the UDP connection in general. If you for example play some net-usb sources, do you get correct artist/title meta information displayed in real time in the media-control (or mini-media-player) card?

from aiomusiccast.

Thanks for this great and compehensible explanation. I can live with that for now, I just have to use fixed IP's for them now, no big thing. Otherwise I also have to use the DNS names for them, HA's web frontend is used via SSL (ha-proxy), and, to embed the Yamaha's web interface in the gui (for newer browsers), I have to pass their traffic also through ha-proxy, ha-proxy (currently) uses the hostname to pick the correct Amp as a backend/server.

I do not believe it could be caused by delay. Total RRT is < 3ms.

Often (not always) I see that meta informations is not updated on the Yamahas, at the beginning of a playlist, the title is displayed properly, but the following titles aren't updated, neither on the Yamahas, nor in the miniplayer. The information diplayed on the mini-player matches the Amps display, even if it's not correct.

Can you explain from where the Yamaha's and the mini players display information is taken from?

This would help to explore the apparent network issue a bit further. I have wireshark on the HA box, but currently I cannot monitor the traffic between the NAS an the Yamahas.

I'll try to set up a port mirroring for the remote Yamahas to prove your UDP packet loss theory. I did put the local Yamaha in a routed VLAN, now it has the same display-not-updated-on-song-change issue, if I can't fix it, I'll try to build a L2 VLAN for the remote Yamahas to try it without routing.

from aiomusiccast.

The UDP channel is the only communication channel the MusicCast device can use to send data to HA on its own. As we did not want to pull all information every second from every single device, we decided to only update the data when the device tells us, that there is a relevant change. In addition, we pull all information from every device once a minute. This way we ensure that the data are not inconsistent forever if a UDP package got lost.
If you say that information like the title are not up to date, it could also be caused by the loss of UDP packages. Without them, HA only updates information once a minute. We could discuss, whether we want to add a configuration flag in HA to define that the data should be pulled every x seconds. It's not really clean and would cause much more traffic, but it's the only way, I see, to keep data up to date, if UDP packages cannot be transmitted.

from aiomusiccast.