Open phillipivan opened 1 week ago
I feel like this should default to ipv4 only, unless the module author explicitly opts into ipv6.
Simply because I think it likely that most module devs will not think about ipv6, so will not think to opt out of ipv6 results. And if a module dev does think to support ipv6, they will test for it, and should discover that they need to opt into ipv6 results.
I agree, and that was the starting point for the request. I dislike the bonjour field presenting choices I know a priori will fail - which I am encountering at the moment... and it wouldn't have occurred to me to check for it except that I happened upon it in testing.
for now I'm going to simply remove the ipv6 results, making it configurable isnt hard but adds complexity that I don't want to do right now
No worries. Do you know if anyone / how many people use companion in ipv6 environments?
I think https://github.com/bitfocus/companion/issues/2711 covers everyone I have heard of. And based on that, there are many other things we are doing 'wrong' to be ipv6 friendly. But tbh, I have yet to see a piece of hardware that supports ipv6, and even the ip av protocols that I know of (dante, smpte2110, aes67) don't support ipv6, so ipv4 isn't going away inside a lot of production networks anytime soon. Of course some environments could benefit, but most likely ones which only talk to online/cloud services or software on other computers, which are less likely to utilise this discovery.
Is this a feature relevant to companion itself, and not a module?
Is there an existing issue for this?
Describe the feature
Currently, bonjour queries made for device discovery will return both IPv4 and IPv6 results. However not all modules/libraries are compatible with both. It would be good if we could filter by IP type before these options are presented to the user so they don't have options which will throw an error upon config save.
Usecases
A cleaner UI that doesn't present known invalid options to the user.