xpra icon
Bug tracker and wiki

Opened 6 months ago

Closed 6 months ago

#1440 closed defect (fixed)

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

Reported by: J. Max Mena Owned by: Antoine Martin
Priority: major Milestone: 2.0
Component: server Version: 1.0.x
Keywords: Cc:

Description

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

Change History (5)

comment:1 Changed 6 months ago by Antoine Martin

Status: newassigned

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.

comment:2 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Status: assignednew

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.

comment:3 Changed 6 months ago by Antoine Martin

Component: androidserver
Milestone: 2.0

comment:4 Changed 6 months ago by J. Max Mena

Owner: changed from J. Max Mena to Antoine Martin

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.



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.

comment:5 Changed 6 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.