select network interface(s) for MVR-xchange (mDNS discovery robustness)

[stephezapo]

This is a feature request that is connected to mDNS issues when using the library on Windows (11).

Current Situation:
Using grandMA3 onPC v2.0.0.4, the library can always detect the console's MVR service, but the other way round is not working all the time. The reasons for this could not be found out yet. This happens on multiple machines with different network configurations, even with Windows firewall being turned off. Running grandMA3 on a second machine with wired networking always works between the consoles, they can communicate both ways in any situation. So the issue is very likely related to libMVRgdtf.

Solution Proposal:
grandMA3 offers the possibility to select network interfaces (i.e. IPs) on which the service is enabled. Perhaps this could also be a valuable feature to implement into the library, as it currently opens the service on multiple (random?) interfaces.

[welcome]

Thanks for opening your first issue here! Be sure to follow the issue template!

[vanous]

@stephezapo not sure if related, but i had a lot of troubles with multicasting when network interface did not define default route, could this be the issue? It wasn't on mDNS but on sACN...

It turns out that default route must be present for the multicast to work, which is not compatible with ipv4 option "never default".

See more details here Hundemeier/sacn#45 (comment)

[moritzstaffel]

By default, libMVRgdtf will always uses all available network interfaces. It booth adds them to the mDNS services, and also starts the TCP servers on each of this interfaces.

During development there was some debate if we should also do it like MA and only start on one interface. But we thought, we really want to make it zero conf.

But adding the option in the lib is really easy. So we can add this.

Are you available for a quick meeting, so that we can have a look on this. The issue you describe we did not have.