Testing {stuff} with osx client 0.16.0 r10972, against 0.16.0 r10972 fedora 21 server I'm seeing tracebacks upon initial connection (two xterms as start-childs) indicating png and jpeg decoding errors, both client and server side.
Client side:
2015-10-23 14:35:16,129 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)} 2015-10-23 14:35:16,388 server: Linux 4.1.5-100.fc21.x8664 Fedora 21 Twenty One, Xpra version 0.16.0-r10972 2015-10-23 14:35:16,471 Attached to tcp:10.0.32.136:2200 (press Control-C to detach) Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 275, in on_realize File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 62, in get_xid AttributeError: xid attribute not supported Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/gtk_base/gtk_client_window_base.py", line 275, in on_realize File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 62, in get_xid AttributeError: xid attribute not supported 2015-10-23 14:35:16,651 get_window_frame_size(0, 22, 998, 632)=None 2015-10-23 14:35:16,652 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)} 2015-10-23 14:35:16,653 get_window_frame_size(0, 22, 998, 632)=None 2015-10-23 14:35:16,653 get_window_frame_sizes()={'frame': (0, 0, 22, 0), 'offset': (0, 22)} 2015-10-23 14:35:16,793 draw error Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/ui_client_base.py", line 2475, in _do_draw File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/client_window_base.py", line 539, in draw_region File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/window_backing_base.py", line 524, in draw_region File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/window_backing_base.py", line 532, in do_draw_region Exception: invalid encoding: jpeg 2015-10-23 14:35:16,793 error processing draw packet Traceback (most recent call last): File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/ui_client_base.py", line 2415, in _draw_thread_loop File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/ui_client_base.py", line 2475, in _do_draw File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/client_window_base.py", line 539, in draw_region File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/window_backing_base.py", line 524, in draw_region File "/Users/osx/gtk/inst/lib/python2.7/site-packages/xpra/client/window_backing_base.py", line 532, in do_draw_region Exception: invalid encoding: jpeg ...
Server-side:
2015-10-23 14:35:17,794 using h264 as primary encoding also available: 2015-10-23 14:35:17,794 vp9, vp8, webp, rgb24, rgb32, png, jpeg 2015-10-23 14:35:17,795 client root window size is 1480x1245 with 1 displays: 2015-10-23 14:35:17,795 schadenfreude.local (1044x878 mm - DPI: 36x36) 2015-10-23 14:35:17,795 monitor 1 840x525 at 640x720 (592x370 mm - DPI: 36x36) 2015-10-23 14:35:17,795 monitor 2 1280x720 (903x508 mm - DPI: 36x36) 2015-10-23 14:35:17,805 server virtual display now set to 1792x1344 (best match for 1480x1245) 2015-10-23 14:35:17,808 setting keyboard layout to 'us' 2015-10-23 14:35:17,926 DPI set to 36 x 36 2015-10-23 14:35:18,346 client_decode_error: invalid encoding: jpeg (-1) 2015-10-23 14:35:18,346 client_decode_error: invalid encoding: jpeg (-1) 2015-10-23 14:35:18,415 client_decode_error: invalid encoding: jpeg (-1) ... 2015-10-23 14:35:37,612 sound-source pipeline warning: Can't record audio fast enough 2015-10-23 14:35:37,612 sound-source pipeline warning: ("gstaudiobasesrc.c(863): gst_audio_base_src_create (): /GstPipeline:pipeline0/GstPulseSrc:pulsesrc0:\nDropped 2097040 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.",) 2015-10-23 14:36:15,682 client_decode_error: invalid encoding: png (-1) 2015-10-23 14:36:15,959 client_decode_error: invalid encoding: jpeg (-1) 2015-10-23 14:36:16,233 client_decode_error: invalid encoding: jpeg (-1) 2015-10-23 14:36:16,511 client_decode_error: invalid encoding: jpeg (-1) 2015-10-23 14:36:58,222 client_decode_error: invalid encoding: png (-1) 2015-10-23 14:36:58,494 client_decode_error: invalid encoding: png (-1) 2015-10-23 14:36:58,760 client_decode_error: invalid encoding: png (-1) ...
There were actually two problems here:
This uncovered another bug too: #1012.
Initial png & jpg issue confirmed fixed in 0.16.0 r11015 (against 0.16.0 r11031 fedora 21 server).
XPRA_CODEC_FAIL_IMPORT=enc_pillow,dec_pillow
, meanwhile, looks like it is meant to be run client side, but doing so I couldn't find any indication of whether it was causing any failure or not. Ran it on both sides and saw no effect.
(Running XPRA_CODEC_FAIL_IMPORT=enc_pillow,dec_pillow ./xpra/codecs/loader.py
output a list with no enc_pillow or dec_pillow though, so I presume it worked, and was handled gracefully?)
XPRA_CODEC_FAIL_SELFTEST=enc_pillow,dec_pillow ./xpra/codecs/loader.py
outputs warnings when run server side, and XPRA_CODEC_FAIL_SELFTEST=enc_pillow,dec_pillow xpra start
likewise outputs noticeable warning (2015-10-26 17:24:51,224 failed to import Pillow encoder (enc_pillow)
)... but the client seems to connect without warnings or tracebacks of its own.
Presuming this is sufficient, I'll close this.
XPRA_CODEC_FAIL_IMPORT=enc_pillow,dec_pillow, meanwhile, looks like it is meant to be run client side, but doing so I couldn't find any indication of whether it was causing any failure or not. Ran it on both sides and saw no effect.
It can be used with both clients and servers to disable specific encoders (server side) or decoders (client side).
Since it will disable some encodings, you can verify that it is taking effect by looking at the encodings available, either using xpra info, the tray menu options, the command line help arguments, session info, etc...
Note: some encodings have more than one decoder, as can be seen from the loader.py script: webp can be decoded by both dec_webp and dec_pillow, vp8/vp9 can be decoded by dec_avcodec2 and dec_vpx, etc..
so I presume it worked, and was handled gracefully?
Correct.
XPRA_CODEC_FAIL_SELFTEST=...
outputs warnings
Yes, the fail import option is to simulate something that is missing: suboptimal but supported.
The fail selftest option on the other hand is meant to simulate what happens when we detect broken libraries or buggy code and must always trigger a warning so that we can detect it and deal with it.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1010