Scrolling in Quod Libet causes the server to lock up and stop sending paints

[totaam]

Issue migrated from trac ticket # 1440

component: server | priority: major | resolution: fixed

2017-02-14 19:03:39: maxmylyn created the issue

---

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:

• Install Quod Libet

• Add some music
• Create a playlist
• Scroll up and down in the playlist a bit
• Server keels over and stops painting whatsoever - even sound stops

[totaam]

2017-02-15 03:44:03: antoine changed status from new to assigned

[totaam]

2017-02-15 03:44:03: antoine commented

---

This scroll encoding error is fixed in 15067.

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.

[totaam]

2017-02-18 06:21:13: antoine changed status from assigned to new

[totaam]

2017-02-18 06:21:13: antoine changed owner from antoine to maxmylyn

[totaam]

2017-02-18 06:21:13: antoine commented

---

Reverting 15067 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.

[totaam]

2017-02-21 12:45:43: antoine changed component from android to server

[totaam]

2017-02-21 22:26:09: maxmylyn changed owner from maxmylyn to antoine

[totaam]

2017-02-21 22:26:09: maxmylyn commented

---

Upped server and client to r15129:

• No longer crashes or locks up the server

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.

---

[[br]]

Does your system have enough CPU and memory headroom to run this?

[[br]]

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.

[totaam]

2017-02-22 02:58:17: antoine changed status from new to closed

[totaam]

2017-02-22 02:58:17: antoine set resolution to fixed

[totaam]

2017-02-22 02:58:17: antoine commented

---

The "frame_delay" is fixed in r15131 (15132 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.