Opening "Session Info" while "server is not responding, drawing spinners over the windows", can lead to timeout about xpra HOT 15 OPEN

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.

from xpra.

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

from xpra.

(also btw - graph window is not working)

from xpra.

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

from xpra.

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

from xpra.

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

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

from xpra.

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

from xpra.

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

from xpra.

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.

from xpra.

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

from xpra.

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)

from xpra.

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?

from xpra.

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?

from xpra.

... also on the normal ones

from xpra.

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

Please try r35929 or later.

from xpra.