Cancellation happens too late

Bug #1531038 reported by Michi Henning on 2016-01-05
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Unassigned
thumbnailer (Ubuntu)
High
Michi Henning

Bug Description

I'm still not happy with cancellation. The thumbnailer handles cancellation correctly, that is, successfully cancels anything that hasn't been sent via dbus yet. But it doesn't work well at the UI level. When thumbnailing a large collection of MP3s without artwork and scrolling forward quickly, the requests that are scrolling off the top of the screen are not physically cancelled, so it takes a long time for the thumbnails for the visible section of the list to show up. In addition, more often than not, the application times out and shows "no artwork" images.

Ideally, I'd like to see whatever is in the currently visible section to get priority.

Need to investigate what exactly is going on here and whether there might be a way to mitigate the issue.

Related branches

Changed in thumbnailer (Ubuntu):
assignee: nobody → Michi Henning (michihenning)
importance: Undecided → High
Albert Astals Cid (aacid) wrote :

listviews have a cache area, that's why items off screen are not deleted immediately.

Michi Henning (michihenning) wrote :

Thanks for that. Yes, I figured that too. The question is whether, they way things are at the moment, things are ever deleted. We allow up to 20 async requests via dbus and then queue any additional ones up on the client side. With the remote server taking 3-10 seconds for each image, it's easy to pile up a few hundred requests just by scrolling down quickly.

Now, when we get a cancel(), we actually cancel() the request if it's one that is still in the queue waiting to be sent. And we don't kick the queue to start working on another request until an earlier request completes. The question for me right now is "at what point (if any) does the listview cancel requests that scroll off the top of the screen while they are still waiting?"

The behavior I'm seeing when scrolling forward suggests that nothing is ever cancelled (or that cancellation isn't working for some reason). If cancellation did work, I wouldn't have to wait for the 200 requests that I just scrolled past to complete before the current region of the listview gets its thumbnails.

At this point, it's still investigation. I don't know what exactly is happening just yet. It's possible that there is still a bug in our request cancellation.

Michi Henning (michihenning) wrote :

Fixed. The backlog of 20 was too large, meaning that the UI could never cancel requests quickly enough to actually be still in the queue because, each time we dropped back to the event loop, we'd fire another request. That turned all the cancel messages effectively into no-ops.

I also changed the rate limiter to use LIFO instead of FIFO. This gives a cancel message a much better chance of still finding a request waiting in the queue, so it can really be cancelled. This massively improves the user experience with a cold cache when scrolling through a large collection of songs because the requests that become visible once scrolling stops are dealt with first. (Previously, the thumbnails for songs visible at the end of the scroll would appear only once all preceding thumbnails (now no longer visible) had been dealt with.)

Changed in thumbnailer (Ubuntu):
status: New → In Progress
Changed in thumbnailer (Ubuntu):
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: New → In Progress
importance: Undecided → High
milestone: none → ww02-2016
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package thumbnailer - 2.3+16.04.20160107.1-0ubuntu1

---------------
thumbnailer (2.3+16.04.20160107.1-0ubuntu1) xenial; urgency=medium

  * Fix for lp:1531038. Much better user experience this way. (LP:
    #1531038)

 -- Michi Henning <email address hidden> Thu, 07 Jan 2016 06:33:30 +0000

Changed in thumbnailer (Ubuntu):
status: Fix Committed → Fix Released
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers