Xpra: Ticket #401: detect bad connection and warn the user

When we encounter network problems, we currently deal with it by lowering the framerate (sometimes too much) and drawing spinners on top of the windows. In some cases, the user might be tempted to blame xpra when in fact it is the network that is the problem, so we should warn the user instead and tell them where to look for the problem.


Here is an obvious symptom:

window[3].batch.damage-packet-queue-size=(375, 1002)

Where we just can't send the packets out.


We should probably wait a little while to see if the network problem resolves itself rather than spamming the user. And make it an option? (or just tune the sensitivity? someone on 3G may care a lot less about notifications than when on a LAN)



Fri, 15 Nov 2013 14:13:46 GMT - Antoine Martin: owner, status, milestone changed

too late for 0.11


Thu, 20 Mar 2014 04:56:57 GMT - Antoine Martin: milestone changed

see #540 for a more general ticket, re-scheduling.


Sat, 17 May 2014 11:20:31 GMT - Antoine Martin: milestone changed

re-scheduling.


Tue, 14 Apr 2015 16:29:53 GMT - Antoine Martin: milestone changed

re-scheduling.


Thu, 14 Apr 2016 04:08:10 GMT - Antoine Martin:

See also #999.


Tue, 27 Sep 2016 09:33:03 GMT - Antoine Martin: milestone changed


Sun, 19 Feb 2017 06:36:48 GMT - Antoine Martin: milestone changed


Mon, 10 Jul 2017 14:15:04 GMT - Antoine Martin: milestone changed

re-scheduling


Thu, 20 Jul 2017 16:22:39 GMT - Antoine Martin:

Some ideas:


Tue, 14 Nov 2017 14:11:39 GMT - Antoine Martin: milestone changed

Detecting the problem should be done as part of #999, showing the actual warning can be handled with #1688


Sun, 26 Nov 2017 13:06:33 GMT - Antoine Martin: milestone changed


Tue, 30 Jan 2018 08:10:52 GMT - Antoine Martin: status changed; resolution set

Done in ticket:1688#comment:6


Sat, 23 Jan 2021 04:54:20 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/401