Just a thought, but the issue only affects connections on WiFi, but the workaround is 'global' - it'll nobble the setting whether you're on wireless or not. I assume thats not going to be a major problem? (its only checking for connectivity changes)
If it is, rather than setting the value to -1, maybe increasing it to 15 or 30 minutes? You'll only get a spike every half hour which is better than every 10 seconds.

Don’t think it should be an issue. I’m told that this is what the Symless folks did to fix it in their Synergy app. But if necessary 30 mins is reasonable.

No, I was just thinking out loud. If off is good, it gets my vote. I primarily use DB4S wirelessly at home, but wired at work. Never really had an issue, but don't use the network that 'closely'... its usually 'good enough'.... ;)

Thanks for pointing this out, @gee4vee. I never would have guessed that there is a problem like this 😉 I've just pushed a fix for this. Can you check if it's now working better for you using one of the next nightly builds?

By the way, I don't set the timer to -1 now because that prints an irritating warning to the console whenever you start the application. Instead I'm setting it to INT_MAX which should give you around 596 hours on most systems between each bad ping value 😉

It definitely doesn't seem like the right approach but likely it's also the only thing we can do... If anybody notices any side effects of this, please point them out.

Got the nightly just now and the latency is gone. 👍 👊

Awesome 😄 Thanks for testing 👍

Interestingly, it seems like the Qt team are looking into a more proper solution finally:

    https://bugreports.qt.io/browse/QTBUG-65586