xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#954 closed defect (fixed)

Windows Clients fail to connect

Reported by: J. Max Mena Owned by: J. Max Mena
Priority: major Milestone: 0.16
Component: server Version: 0.15.x
Keywords: Cc:

Description

Attempting to connect to a built from source trunk Fedora 21 server with a (Smo build) trunk r10336 Win8.1 client:

  • Server started with xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm
  • Client attempting to connect (from CMD) with Xpra_cmd.exe attach tcp:10.0.32.139:2200 --opengl=no (Windows machine with Apple Intel driver)

The client fails to connect with the following output:

2015-08-19 15:11:29,969 xpra gtk2 client version 0.16.0 (r10336)
2015-08-19 15:11:30,453  detected keyboard: layout=us
2015-08-19 15:11:30,453  desktop size is 2560x1440 with 1 screen(s):
2015-08-19 15:11:30,453   '1\WinSta-Default' (677x381 mm - DPI: 96x96) workarea:
 2560x1400
2015-08-19 15:11:30,453     DISPLAY1 (597x336 mm - DPI: 108x108) workarea: 2560x
1400
2015-08-19 15:11:50,454 connection timed out
2015-08-19 15:11:50,470 Connection lost

Attempting to connect with --encodings=webp,jpeg,png,h264 still fails, but takes longer and prints the following:

2015-08-19 15:13:27,628 xpra gtk2 client version 0.16.0 (r10336)
2015-08-19 15:13:28,253  detected keyboard: layout=us
2015-08-19 15:13:28,253  desktop size is 2560x1440 with 1 screen(s):
2015-08-19 15:13:28,253   '1\WinSta-Default' (677x381 mm - DPI: 96x96) workarea:
 2560x1400
2015-08-19 15:13:28,253     DISPLAY1 (597x336 mm - DPI: 108x108) workarea: 2560x
1400
2015-08-19 15:13:48,269 connection timed out
2015-08-19 15:13:48,269 server: Linux Fedora 21 Twenty One, Xpra version 0.16.0
(r9542)
2015-08-19 15:13:48,269 error in hello packet
Traceback (most recent call last):
  File "xpra\client\client_base.pyc", line 578, in _process_hello
  File "xpra\client\ui_client_base.pyc", line 1302, in server_connection_establi
shed
  File "xpra\client\client_base.pyc", line 598, in server_connection_established

  File "xpra\client\client_base.pyc", line 730, in parse_network_capabilities
AttributeError: 'NoneType' object has no attribute 'enable_encoder_from_caps'
2015-08-19 15:13:48,269 error processing hello packet from server: 'NoneType' ob
ject has no attribute 'enable_encoder_from_caps'
2015-08-19 15:13:48,269 error during win32 events cleanup of event window instan
ce: (5, 'DestroyWindow', 'Access is denied.')
2015-08-19 15:13:48,285 error during win32 events cleanup of event window class:
 (5, 'DestroyWindow', 'Access is denied.')
2015-08-19 15:13:48,301 Connection lost

The server prints the following in both cases:

2015-08-19 15:13:28,087 client does not support any csc modes with vp9
2015-08-19 15:13:28,093 client does not support any csc modes with vp9
2015-08-19 15:13:48,519 internal error: read connection tcp socket: 10.0.32.139:2200 <- 10.0.11.123:52257 reset
2015-08-19 15:13:48,519  [Errno 104] Connection reset by peer
2015-08-19 15:13:48,521 xpra client disconnected.

Change History (3)

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena

Confirmed a problem, which only manifests itself as a sluggish client for me, and only on win32.
I don't think this ticket has anything to do with vp9. (you seem to have more or less the same problems with and without vp9 enabled - makes no difference when I tested)

Since this must be a recent issue, I then moved on to bisecting (which is what you do to find when a regression was added). And so, many many hours later:

All the changes in r10325 looked fine, assuming that glib is a direct replacement for gobject... which it might not be despite the scary deprecation warnings I've seen advising to the switch over.
r10370 gets rid of the threads_init, cleans up the code a bit and seems to solve the problem.
Which is quite odd considering that calling threads_init was actually required for fixing the proxy server (see r10355).

r10363 should avoid most of the NoneType errors reported in the ticket description, those cleanup races are near impossible to hit without the other bug - so there is no urgency to backport those fixes.

@maxmylyn: please close this ticket if that works for you.


opengl=no


Do you still have problems with opengl? What are they? Is there a ticket for that?

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 5 years ago by Antoine Martin

Summary: Windows Clients fail to connect without VP9 supportWindows Clients fail to connect

(editing bug title)

comment:3 Changed 5 years ago by J. Max Mena

Resolution: fixed
Status: newclosed

The changes have cleared it up so far as I can tell. (as in it's working properly now..)


Do you still have problems with opengl? What are they? Is there a ticket for that?


Yeah, I was having some general stability issues when I had OpenGL enabled on this machine, as it's an Apple laptop running Windows (hardware not in VMWare), but still with Apple drivers. I switched to disabling OpenGL and it seemed to fix it, but I forgot I've been doing it by default for a while now(the things QA people should avoid..). I'll actually try it with OpenGL enabled for a while and see if it's still a persistent issue; in which case I'll file a ticket.

The issues I was seeing were a milder version of the Intel OpenGL OSX issues we were having in Xpra 14/15 before the driver was greylisted.

Last edited 5 years ago by J. Max Mena (previous) (diff)
Note: See TracTickets for help on using tickets.