Opening "Session Info" while "server is not responding, drawing spinners over the windows", can lead to timeout

[stdedos]

Describe the bug
A clear and concise description of what the bug is.

"Xpra-Light-x86_64_6.1-r35826\xpra_cmd" shadow ssh://user@ip/0  --modal-windows=no --headerbar=off --title="@title@ on @@/@server-display@" --encodings=-webp --microphone=off --speaker=off --webcam=no --pulseaudio=no --opengl=no --min-speed=70 --key-shortcut=Shift+F2:toggle_pointer_grab

XPRA_EXECUTABLE=Xpra-Light-x86_64_6.1-r35826
XPRA_FILE_CHOOSER_NATIVE=2


2024-05-25 22:54:13,767 Xpra GTK3 client version 6.1-r35826 (g4b8baa544b) beta (light build)
2024-05-25 22:54:13,921  running on Microsoft Windows Microsoft Windows 10 Enterprise
2024-05-25 22:54:13,921  cpython 3.11
2024-05-25 22:54:14,420 GStreamer version 1.24.3
2024-05-25 22:54:14,428 created named pipe 'Xpra\54748'
2024-05-25 22:54:14,473 keyboard layout 'United States - English' : 'us' (0x409)
2024-05-25 22:54:14,713 Connected (version 2.0, client OpenSSH_8.2p1)
2024-05-25 22:54:15,186 SSH password authentication failed:
2024-05-25 22:54:15,186  Bad authentication type
2024-05-25 22:54:15,186   allowed types: ['publickey', 'password']
2024-05-25 22:54:21,063 Authentication (password) successful!
2024-05-25 22:54:21,822 ssh server OS is 'linux-gnu'
2024-05-25 22:54:22,025 paramiko SSH agent forwarding enabled
2024-05-25 22:54:22,045  keyboard settings: layout=us
2024-05-25 22:54:22,046  desktop size is 4480x1516:
2024-05-25 22:54:22,046   Default (1185x401 mm - DPI: 96x96) workarea: 4480x1476
2024-05-25 22:54:22,046     Samsung C32JG5x  2560x1440 at    0x0    (697x392 mm - DPI: 93x93) workarea: 2560x1400
2024-05-25 22:54:22,047     LG IPS234        1920x1080 at 2560x436  (510x290 mm - DPI: 96x95) workarea: 1920x1040 at 2560x436
2024-05-25 22:54:22,406  SSH: 'Entering daemon mode; any further errors will be reported to:'
2024-05-25 22:54:22,407  SSH: "  '/run/user/1000/xpra/0/server.log'"
2024-05-25 22:54:24,314 enabled remote logging
2024-05-25 22:54:24,316 Xpra shadow server version 5.0
2024-05-25 22:54:24,317  remote desktop size is 1920x1080
2024-05-25 22:54:24,318   :0.0 (508x285 mm - DPI: 96x96) workarea: 1851x1053 at   69x27
2024-05-25 22:54:24,318     LGD eDP-1        (309x174 mm - DPI: 158x158)
2024-05-25 22:54:24,856 running, 1 windows
2024-05-25 22:54:31,327 server is not responding, drawing spinners over the windows
2024-05-25 22:54:31,831 server is OK again
2024-05-25 22:54:32,401 window 1 has been moved to monitor 1: LG IPS234 1920x1080 at 2560,436
2024-05-25 22:54:36,329 server is not responding, drawing spinners over the windows
2024-05-25 22:54:37,584 server is OK again
2024-05-25 22:54:41,331 server is not responding, drawing spinners over the windows
2024-05-25 22:54:42,086 server is OK again
2024-05-25 22:54:46,332 server is not responding, drawing spinners over the windows
2024-05-25 22:54:48,842 server is OK again
2024-05-25 22:54:51,333 server is not responding, drawing spinners over the windows
2024-05-25 22:54:52,087 server is OK again
2024-05-25 22:54:56,334 server is not responding, drawing spinners over the windows

(xpra_cmd:54748): Pango-WARNING **: 22:55:04.863: couldn't load font "Gentium Book Basic Bold Italic Not-Rotated 57.331", falling back to "Sans Bold Italic Not-Rotated 57.331", expect ugly output.

(xpra_cmd:54748): Pango-WARNING **: 22:55:04.875: couldn't load font "Gentium Book Basic Bold Italic Not-Rotated 57.096", falling back to "Sans Bold Italic Not-Rotated 57.096", expect ugly output.

(xpra_cmd:54748): Pango-WARNING **: 22:55:05.134: couldn't load font "DejaVu Serif Not-Rotated 59.797", falling back to "Sans Not-Rotated 59.797", expect ugly output.

(xpra_cmd:54748): Pango-WARNING **: 22:55:05.142: couldn't load font "URW Bookman L Not-Rotated 52.762", falling back to "Sans Not-Rotated 52.762", expect ugly output.
2024-05-25 22:55:05,186 server is OK again
2024-05-25 22:55:06,336 server is not responding, drawing spinners over the windows
2024-05-25 22:55:13,763 server is OK again
2024-05-25 22:55:24,336 server is not responding, drawing spinners over the windows
2024-05-25 22:55:24,839 server is OK again
2024-05-25 22:55:29,338 server is not responding, drawing spinners over the windows
2024-05-25 22:55:31,848 server is OK again
2024-05-25 22:55:39,339 server is not responding, drawing spinners over the windows
2024-05-25 22:55:41,346 server is OK again
2024-05-25 22:55:44,338 server is not responding, drawing spinners over the windows
2024-05-25 22:55:45,595 server is OK again
2024-05-25 22:55:49,341 server is not responding, drawing spinners over the windows
2024-05-25 22:55:49,594 server is OK again
2024-05-25 22:55:54,341 server is not responding, drawing spinners over the windows
2024-05-25 22:55:55,598 server is OK again
2024-05-25 22:55:59,342 server is not responding, drawing spinners over the windows
2024-05-25 22:56:00,097 server is OK again
2024-05-25 22:56:04,342 server is not responding, drawing spinners over the windows
2024-05-25 22:56:04,594 server is OK again
2024-05-25 22:56:09,344 server is not responding, drawing spinners over the windows
2024-05-25 22:56:11,351 server is OK again
2024-05-25 22:56:14,345 server is not responding, drawing spinners over the windows
2024-05-25 22:56:18,360 server is OK again
2024-05-25 22:56:19,345 server is not responding, drawing spinners over the windows
2024-05-25 22:56:21,353 server is OK again
2024-05-25 22:56:24,346 server is not responding, drawing spinners over the windows
                                                                                    <--- opened Session Info
2024-05-25 22:56:30,414 UI thread is now blocked
2024-05-25 22:57:33,208 server is not responding, drawing spinners over the windows
2024-05-25 22:57:36,241 server is OK again
2024-05-25 22:57:36,241 UI thread is running again, resuming
2024-05-25 22:57:36,274 server requested disconnect:
2024-05-25 22:57:36,275  ConnectionMessage.CLIENT_PING_TIMEOUT
2024-05-25 22:57:36,275  waited 60 seconds without a response

To Reproduce
Steps to reproduce the behavior:

1. server command
2. client command
3. specific action to trigger the bug

System Information (please complete the following information):

• Server OS: Ubuntu 20.04.6 LTS
• Client OS: Microsoft Windows [Version 10.0.18363.836]
• Xpra Server Version: (see above)
• Xpra Client Version: (see above)

Additional context
Add any other context about the problem here.
Please see "reporting bugs" in the wiki section.

[stdedos]

... or idk - maybe it was really a bad connection. But we are talking home network, Gigabit Eth over WiFi (@ ~135Mb/s)

[stdedos]

(also btw - graph window is not working)

[totaam]

Maximum latency at 22 seconds!
159 Megapixels/s
Don't expect miracles!

[stdedos]

Idk - I don't want to say that xpra is lying, but ...

"How can I have latency 22 seconds?!?"
I have a (home) shit LAN, but not 22s latency from a Gigabit ETH to 135 Mb/s WiFi

I have "just an HD monitor", so the math doesn't add up:

For an HD (High Definition) resolution, typically 1920x1080 pixels, we can calculate the required data transfer rates at different frame rates (25, 30, and 60 fps).

1. Resolution: 1920 * 1080 = 2,073,600 pixels (approximately 2.07 Megapixels per frame)

Now, let's calculate the required Megapixels per second for each frame rate:

• 25 fps:
  ( 2.07 , \text{Megapixels} \times 25 , \text{fps} = 51.8 , \text{Megapixels/s} )

• 30 fps:
  ( 2.07 , \text{Megapixels} \times 30 , \text{fps} = 62.1 , \text{Megapixels/s} )

• 60 fps:
  ( 2.07 , \text{Megapixels} \times 60 , \text{fps} = 124.2 , \text{Megapixels/s} )

Therefore, for screen mirroring an HD resolution (1920x1080):

• At 25 fps, you need 51.8 Megapixels/s.
• At 30 fps, you need 62.1 Megapixels/s.
• At 60 fps, you need 124.2 Megapixels/s.

Given these numbers, a transfer rate of 159 Megapixels/s is more than sufficient to handle HD screen mirroring at any of these frame rates, including the highest at 60 fps.

I am more than happy to take an FPS hit, and "color-quality" hit (but ofc no blur, since a lot is text 😕) - and I assume that the v5 video encoders can do something about it?

I think your stats are a bit misleading: If data arrives "all the time" e.g. here

2024-05-25 22:54:56,334 server is not responding, drawing spinners over the windows

(xpra_cmd:54748): Pango-WARNING **: 22:55:04.863: couldn't load font "Gentium Book Basic Bold Italic Not-Rotated 57.331", falling back to "Sans Bold Italic Not-Rotated 57.331", expect ugly output.

(xpra_cmd:54748): Pango-WARNING **: 22:55:04.875: couldn't load font "Gentium Book Basic Bold Italic Not-Rotated 57.096", falling back to "Sans Bold Italic Not-Rotated 57.096", expect ugly output.

(xpra_cmd:54748): Pango-WARNING **: 22:55:05.134: couldn't load font "DejaVu Serif Not-Rotated 59.797", falling back to "Sans Not-Rotated 59.797", expect ugly output.

(xpra_cmd:54748): Pango-WARNING **: 22:55:05.142: couldn't load font "URW Bookman L Not-Rotated 52.762", falling back to "Sans Not-Rotated 52.762", expect ugly output.
2024-05-25 22:55:05,186 server is OK again

but for some reason you don't update those stats in-between server is not responding / server is OK again - then yes, in ~10s the buffers maybe finally returned 159 MP/s.
But then I'd say you'd have to instead report 159 MP/s / 10s = 15.9 MP/s received

[totaam]

"How can I have latency 22 seconds?!?"

It's easy on wifi, you are experiencing bufferbloat.
xpra is really not lying about this.

[totaam]

BTW, if you have latency / bufferbloat issues, you should definitely try connecting using QUIC rather than ssh.

[stdedos]

BTW, if you have latency / bufferbloat issues, you should definitely try connecting using QUIC rather than ssh.

idk, it doesn't look like it

Ofc it's not a nice result - but not 22 seconds delay ....

---

It seems that opening the Session Info window "causes more damage" than the connection itself

... also quic seems to not be an option?

---

Also, since I haven't played with certs, it'd be cool if it could be setup via ssh-auth (e.g. to send a random, client-generated certificate - and even on a random port).

I tried to see if GUI would make it easier, but it doesn't look like it

[totaam]

The problem is the wifi, always is.
It has its own buffer for re-transmits, and TCP head of line blocking can cause packet delays as big as what you are seeing.

---

It seems that opening the Session Info window "causes more damage" than the connection itself

Populating the info window makes requests and the responses are relatively big.
This is a known limitation - see previous tickets on the subject.
Normally not a big issue on a good connection.

---

As for aioquic, don't install it in a venv unless you also install xpra there (don't).

---

I guess we could add some sort of xpra gen-ssl command to generate self-signed certs - potentially remote ones too.
And maybe a xpra get-ssl command to just download a remote ssl cert.

[stdedos]

As for aioquic, don't install it in a venv unless you also install xpra there (don't).

Yeah, ofc I wouldn't have wanted to do that. I just wanted to try it, and if it doesn't work simply rm -rf it.

However, I don't know which package would have it for xpra:

$  apt-cache madison xpr\t
xpra                xpra-client         xpra-codecs         xpra-codecs-nvidia  xpra-html5          xpra-x11            xprobe              
xpra-audio          xpra-client-gtk3    xpra-codecs-extras  xpra-common         xpra-server         xprintidle          

None of them sounds "needed, but missing"

---

I guess we could add some sort of xpra gen-ssl command to generate self-signed certs - potentially remote ones too.
And maybe a xpra get-ssl command to just download a remote ssl cert.

I mean, "eventually maybe" I should start my own CA, etc etc - but for a barebones way to bootstrap a quic session using some kind of auth would be nice. ssh keys give that flexibility. "Sort-of similar" to how e.g. https://mosh.org/ works

[totaam]

However, I don't know which package would have it for xpra:

Support for quic is included in all recent versions, you just need to install aioquic to get it. (pip install or whatever)

[stdedos]

Ah, okay - I see. I just thought that xpra would not pick up from the "currently active environment" (user or venv) - but simply its own (system or "something special" for python packages installed via apt-get/dpkg).

I started getting mindful of "polluting" my system/user catch-all pip installs and tried to move them e.g. in pipx.
Is there a "reasonably easy" way to convince xpra to "extend its path" to include a venv?

[totaam]

Is there a "reasonably easy" way to convince xpra to "extend its path" to include a venv?

This is not an xpra question, it's an OS / venv one.
python3 /usr/bin/xpra ... is your entry point.

[stdedos]

I managed to hack something together for Ubuntu, but still on Windows, I am getting:

(pyasn1)

I think that on Windows builds you cannot "add" anything, so is this an omission?

Ofc, this is a Light build - so maybe that's it?

[stdedos]

... also on the normal ones

[totaam]

Probably caused by the "Light builds" packaging changes in #4100

Please try r35929 or later.

[stdedos]

and

... idk what I'm doing wrong 😕

[totaam]

... idk what I'm doing wrong

Not sure what the problem is here. What am I supposed to be seeing?
The quic packaging problems are solved so are we back to the "server is not responding" issue?

[stdedos]

I am trying to mimic xpra shadow ssh://..., using quic (as per your suggestion)