detect bad connection and warn the user

[totaam]

Issue migrated from trac ticket # 401

component: core | priority: minor | resolution: duplicate

2013-08-05 06:10:26: antoine created the issue

---

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.

[[BR]]

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)

[totaam]

2013-11-15 14:13:47: totaam changed status from new to assigned

[totaam]

2013-11-15 14:13:47: totaam changed owner from antoine to totaam

[totaam]

2013-11-15 14:13:47: totaam commented

---

too late for 0.11

[totaam]

2014-03-20 04:56:58: totaam commented

---

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

[totaam]

2014-05-17 12:20:31: totaam commented

---

re-scheduling.

[totaam]

2015-04-14 17:29:53: antoine commented

---

re-scheduling.

[totaam]

2016-04-14 05:08:11: antoine commented

---

See also #999.

[totaam]

2017-07-10 15:15:05: antoine commented

---

re-scheduling

[totaam]

2017-07-20 17:22:39: antoine commented

---

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
• re-implement bandwidth constraint option #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?

[totaam]

2017-11-14 14:11:40: antoine commented

---

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

[totaam]

2018-01-30 08:10:53: antoine changed status from assigned to closed

[totaam]

2018-01-30 08:10:53: antoine set resolution to duplicate

[totaam]

2018-01-30 08:10:53: antoine commented

---

Done in #1688#comment:6