Using QuPad across larger networks where uplinks between switches may not be up when the console boots means the initial mDNS discovery message appears to be missed. This is expected network behaviour, as the console boots in seconds and a connected switch powering at the same time much longer. This results in QuPad not discovering the console unless there is an IGMP query message (probably every 30s or so in most configured networks) or an mDNS event triggered. This can be proven a couple of ways; physically disconnecting and reconnecting the console from its local network switch, or by triggering from another app. For example, I have a Qu-SB in a rack with a dbx PA2, also connected to the switch. The PA2 control app lets you manually discover/reconnect to a known IP address, and this triggers an mDNS message as far as I can tell (would need Wireshark to confirm). As soon as this happens, toggling back to QuPad now shows the console available to connect.
I have also noticed that on occasion, (e.g. mixing an all-day festival and swapping between multiple control applications for Qu, PA, lights etc.) QuPad can sometimes need reconnecting and this manual trigger to rediscover, despite all devices having remained online. This could be an IGMP snooping issue, where the device is pruned back and a join message not registered correctly. While switch config could cure the latter with static multicast forwarding groups, I see no way to solve the former mDNS issue other than creating a button in the app that triggers and mDNS event manually. This would be much quicker than swapping to the PA2 app to do it, and back, and it is an elegant solution on other similar apps/consoles/network controlled devices.
Thanks,
Ed
.
