[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 240300] New: Cache Album Cover Thumbnails
From:       Bernd Helm <maps () rw23 ! de>
Date:       2010-05-31 23:51:26
Message-ID: bug-240300-17878 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=240300

           Summary: Cache Album Cover Thumbnails
           Product: amarok
           Version: 2.3.1-GIT
          Platform: Compiled Sources
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: Collection Browser
        AssignedTo: amarok-bugs-dist@kde.org
        ReportedBy: maps@rw23.de


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. it is so amazing slow because iam using a remote
connection mounted using sshfs, but caching will also improve speed for local
collections too i think.

The Cover Thumbnails sould be cached somewhere, so they dont need
to be fetched and rescaled every time again the user expands a artist after
amarok restart again. I guess this may be part of the upcoming
"Dynamic Collection", but caching sould be generic because also local hard
drives are also a slow media. thinking of Netbooks with slow ssd drives.

It sould be possible to cache the cover art in the database (just add a new
binary field next to the file path, or create a new table called i.e.
"albums_cover_cache"). As the cover thumbnails are very small and compressed
with jpeg or something they sould not be very big.


alternative, caching can also be done in local filesystem of the client. If the
user is running amarok with a external MySQL-Database, it would not be the best
to put cache on it, because it may be also slow. then, just create the table
"albums_cover_cache" as sqlite database locally, so it is independent for each
client.

best (but not required) would be to have a configuration option where to cache
things (No Cache, Cache in Remote Database, Cache in local Database).

Reproducible: Always

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

Actual Results:  
Looks like amarok is fetching the covers and freezes until done

Expected Results:  
no freeze :)

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]