Opening "Session Info" while "server is not responding, drawing spinners over the windows", can lead to timeout
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:
- server command
- client command
- 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.
... or idk - maybe it was really a bad connection. But we are talking home network, Gigabit Eth over WiFi (@ ~135Mb/s)
(also btw - graph window is not working)
Maximum latency at 22 seconds! 159 Megapixels/s Don't expect miracles!
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).
- 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
"How can I have latency 22 seconds?!?"
It's easy on wifi, you are experiencing bufferbloat. xpra is really not lying about this.
BTW, if you have latency / bufferbloat issues, you should definitely try connecting using QUIC rather than ssh.
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
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.
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-sslcommand to generate self-signed certs - potentially remote ones too. And maybe axpra get-sslcommand 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
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)
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?
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.
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?
... also on the normal ones
Probably caused by the "Light builds" packaging changes in #4100
Please try r35929 or later.
and
... idk what I'm doing wrong 😕
... 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?
I am trying to mimic xpra shadow ssh://..., using quic (as per your suggestion)