Bug 240303 - Load Covers Asynchronously
Summary: Load Covers Asynchronously
Status: RESOLVED DUPLICATE of bug 240300
Alias: None
Product: amarok
Classification: Applications
Component: Collection Browser (other bugs)
Version First Reported In: 2.3.1-GIT
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-01 01:57 UTC by Bernd Helm
Modified: 2010-06-01 15:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Helm 2010-06-01 01:57:56 UTC
Version:           2.3.1-GIT (using KDE 4.4.3) 
OS:                Linux

If i Expand a Artist (lets take Elvis with 50 CDs) it takes 50 secounds (yeah,
1 sec per album). In this time, amarok is freezed and not useable anymore.
As all needet information is in the Database except the
Cover, which is only stored as path-to-file which ends up in Album dir
(Folder.jpg, you know), i guess it is because amarok is fetching the cover at
first expand. and after each amarok restart again, making collection browsing very slow and uncomfortable.

Iam using a Remote collection mounted using sshfs; its on a "Online-Harddrive"
from strato.de, and needs some time to open a file.

To avoid that, fetch the covers asyncon like ampache service
does - it first shows the default cover image and replaces it with the right
one as soon as it is loaded. This will give a great Performance
inprovement, not only for any mounted collections but also for local ones. iam thinking of Netbooks with cheap and slow solid state drives.

with asyncronous loading, the user will see that the artist is expanded and the cover images popping up. He can close the artist or add tracks without need to wait until loading is done. make sure it also updates the cover of a currently playing track if the user adds it faster than it is loaded.

also look at bug 240300, which is about caching the covers, so both things can work together.

Reproducible: Always

Steps to Reproduce:
place some albums of one artist on a slow media... you can use your webspace
with ftpfs (fuse). then expand.

Actual Results:  
needs ~1 Second per Album, expanding elvis with 50 albums and covers takes 50 seconds where amarok is
completely freezed and unuseable. (very bad if you accidently klicked such a
artist)

Expected Results:  
Instant-expand without freezing :)
Comment 1 Rick W. Chen 2010-06-01 12:40:49 UTC
Whatever the solution for this is would probably solve bug 240300 too. Marking as duplicate.

*** This bug has been marked as a duplicate of bug 240300 ***
Comment 2 Bernd Helm 2010-06-01 15:03:35 UTC
I dont think this Bug is duplicate.

if bug 240300 had been implentet, there is still the Problem that the Covers need to be fetched and scaled once, and amarok freezes and is unresponsoble for this time. making cover fetching asyncronous would solve that.

if the cover is fetched and thumbnailed at scanning time, it would be ok for the collection browser, but when user starts playing a song, so "Current Track" needs a bigger version of the cover, the cover is fetched syncronious.