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
- owner
changed from Antoine Martin to Antoine Martin
- status
changed from new to assigned
- milestone
changed from 0.11 to 0.12
too late for 0.11
Thu, 20 Mar 2014 04:56:57 GMT - Antoine Martin: milestone changed
- milestone
changed from 0.12 to 0.13
see #540 for a more general ticket, re-scheduling.
Sat, 17 May 2014 11:20:31 GMT - Antoine Martin: milestone changed
- milestone
changed from 0.13 to 0.14
re-scheduling.
Tue, 14 Apr 2015 16:29:53 GMT - Antoine Martin: milestone changed
- milestone
changed from 0.15 to 0.17
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
- milestone
changed from 0.17 to 3.0
Sun, 19 Feb 2017 06:36:48 GMT - Antoine Martin: milestone changed
- milestone
changed from 3.0 to 2.1
Mon, 10 Jul 2017 14:15:04 GMT - Antoine Martin: milestone changed
- milestone
changed from 2.1 to 2.2
re-scheduling
Thu, 20 Jul 2017 16:22:39 GMT - Antoine Martin:
Some ideas:
- split min delay and optimal delay for calculations, near min != near optimal
- fix send speed ratio calculations causing batch delay problems: should be a global thing, not per window
- new factor: packet queue data size (not pixels, but compressed size)
- don't recalculate if no of frames elapsed is low: counter<V
- auto-refresh should take latency into account more (killing us over bad connection?)
- target_latency used for a lot of things... jitter makes it bad, 20ms hardcoded - need better
- #417 max-bandwidth switch server side: integrate in speed/quality calculations, batch delay for others: "target bitrate mode"
- very small compressed frames: use this as hint that we can raise quality
- higher latency: use more strict optimistic sending? take ack time into account: latency*2 + decode time = max time it should take and take packet size into account
- min delay: higher when video region active so rgb paints can get joined in there?
Tue, 14 Nov 2017 14:11:39 GMT - Antoine Martin: milestone changed
- milestone
changed from 2.2 to 3.0
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
- milestone
changed from 3.0 to 2.3
Tue, 30 Jan 2018 08:10:52 GMT - Antoine Martin: status changed; resolution set
- status
changed from assigned to closed
- resolution
set to duplicate
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