Running a Fedora 25 server and client, both built from 1.X source, currently at r14576
The server is started normally using xpra start :13 --no-daemon --bind-tcp=0.0.0.0: --start-child=quodlibet
and connecting with xpra attach tcp:ip
. After scrolling up and down a playlist a few times (the playlist is only maybe 40 songs large), the server starts printing:
2017-02-14 10:52:08,619 Error during scrolling detection! Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1668, in do_video_encode return self.encode_scrolling(image, distances, lcsums, csums, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1535, in encode_scrolling scrolllog("too many items: %i scrolls, %i non-scrolls - sending just one image instead", len(raw_scroll), len(non_scroll)) NameError: global name 'raw_scroll' is not defined
and then stops sending sound or paint and just locks up. After disconnecting I can no longer reconnect.
The quodlibet
package is available in the Fedora repos, and the repro for this issue is very very easy:
This scroll encoding error is fixed in r15067.
Not sure why this would cause the server to lockup, I didn't trust this new code 100% which is why we catch the exceptions that can come out and continue with regular video encoding.
Reverting r15067 to test with the 1.x branch, I am able to reproduce the scroll logging stacktrace but the server process continues quite happily and falls back to a video encoding. I did see some heavy CPU load as the app scanned my music folders but not much else. Does your system have enough CPU and memory headroom to run this?
If you are able to reproduce hangs (with or without the revert), please get a GDB backtrace of the xpra server and Xorg processes.
Upped server and client to r15129:
I do get a new traceback in both 1.0.X and 2.0:
Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/source.py", line 512, in recalculate_delays ws.reconfigure() File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1017, in reconfigure self.update_speed() File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 949, in update_speed info, target_speed = get_target_speed(self.wid, self.window_dimensions, self.batch_config, self.global_statistics, self.statistics, self._fixed_min_speed, speed_data) File "/usr/lib64/python2.7/site-packages/xpra/server/window/batch_delay_calculator.py", line 179, in get_target_speed "frame_delay" : int(frame_delay), UnboundLocalError: local variable 'frame_delay' referenced before assignment
Pretty sure that's minor, but I'll pass back to you to confirm. Other than that periodic traceback it behaves fine now.
Does your system have enough CPU and memory headroom to run this?
Well the machine in question (my old friend Vorfuehreffekt
) has a "quad" core i5, which is definitely strong enough as Quod Libet runs fine on my old Core 2 Quad Q6600 machine with the same amount of RAM (4GB). These low-end computers aren't that fast, but they aren't total slouches - most computers made in the last few years is surprisingly powerful even on the low end.
The "frame_delay" is fixed in r15131 (r15132 for v1.0.x).
I'm still not at all convinced that the lockups were directly caused by the scroll encoding failures... (could have been a video encoding related lockup - as we ended up using a video encoding as a fallback for when scroll encoding fails). But since the bug is gone, I'm closing this ticket.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1440