Xpra: Ticket #1440: Scrolling in Quod Libet causes the server to lock up and stop sending paints

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= --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:

Wed, 15 Feb 2017 03:44:02 GMT - Antoine Martin: status changed

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.

Sat, 18 Feb 2017 06:21:13 GMT - Antoine Martin: owner, status changed

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.

Tue, 21 Feb 2017 12:45:42 GMT - Antoine Martin: component changed; milestone set

Tue, 21 Feb 2017 22:26:09 GMT - J. Max Mena: owner changed

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
  File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1017, in reconfigure
  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.

Wed, 22 Feb 2017 02:58:17 GMT - Antoine Martin: status changed; resolution set

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.

Sat, 23 Jan 2021 05:24:22 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1440