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 :)
Wrong component, sorry for the noise
Covers should be cached in $KDEHOME/share/apps/amarok/albumcovers/cache/ the very fist time they're loaded. There might also be other factors that makes this slow. Have you tried turning off cover art display in the collection browser and see how that affects it?
*** Bug 240303 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > Covers should be cached in $KDEHOME/share/apps/amarok/albumcovers/cache/ the > very fist time they're loaded. There might also be other factors that makes > this slow. Have you tried turning off cover art display in the collection > browser and see how that affects it? Turning of the Cover art over "Sort Options" did not work, i had to "update `albums` set image = NULL" to disable the covers. after that, expanding is much faster. Elvis needs now 9 seconds, but this time is still proportional to the nuber of albums of the artist. Iam using a external amarok mysqldb which is connected over the internet, what can be the a reason for that slowness. but as the time scales with the number of albums, i think amarok does subqueries for each album which is not good. would be good if all needed information can be fetched with one query. but yes, it is possivle, that there are more other operations that make it slower, but with covers disabled 50 sec vs. 9 seconds is a performace inprovement of more than 80%.
Well I would think the more albums the slower it gets. Subscribing Jeff since he knows much more about this than I do.
commit 729fcc8ab295149c6ac3f0a57e48cc9770d009ac Author: Rick W. Chen <stuffcorpse@archlinux.us> Date: Wed Jun 2 20:30:41 2010 +1200 Prevent thumbnail cache pruning at every startup / settings change When settings changed, App::applySettings() is called (fair enough); it is also called every time Amarok starts up. In it, "unneeded" cover thumbnails are deleted from the cache directory. Furthermore, an image is deemed "unneeded" if its size is not from a list of hard coded sizes. A better place to prune the cache would be in the cover manager, and initiated by the user. To be done later. CCBUG:240300 diff --git a/src/App.cpp b/src/App.cpp index 5d74b8e..040884b 100644 --- a/src/App.cpp +++ b/src/App.cpp @@ -544,9 +544,12 @@ void App::applySettings( bool firstTime ) DEBUG_BLOCK - if ( AmarokConfig::showTrayIcon() && ! m_tray ) { - m_tray = new Amarok::TrayIcon( mainWindow() ); - } else if ( !AmarokConfig::showTrayIcon() && m_tray ) { + if( AmarokConfig::showTrayIcon() && ! m_tray ) + { + m_tray = new Amarok::TrayIcon( m_mainWindow ); + } + else if( !AmarokConfig::showTrayIcon() && m_tray ) + { delete m_tray; m_tray = 0; } @@ -556,31 +559,18 @@ void App::applySettings( bool firstTime ) //on startup we need to show the window, but only if it wasn't hidden on exit //and always if the trayicon isn't showing - QWidget* main_window = mainWindow(); - - // show or hide CV - if( mainWindow() ) - mainWindow()->hideContextView( AmarokConfig::hideContextView() ); - - if( ( main_window && firstTime && !Amarok::config().readEntry( "HiddenOnExit", false ) ) || ( main_window && !AmarokConfig::showTrayIcon() ) ) + if( m_mainWindow ) { - PERF_LOG( "showing main window again" ) - main_window->show(); - PERF_LOG( "after showing mainWindow" ) - } + // show or hide CV + m_mainWindow->hideContextView( AmarokConfig::hideContextView() ); - if( firstTime ) - { // delete unneeded cover images from cache - PERF_LOG( "Begin cover handling" ) - const QString size = QString::number( 100 ) + '@'; - const QDir cacheDir = Amarok::saveLocation( "albumcovers/cache/" ); - const QStringList obsoleteCovers = cacheDir.entryList( QStringList("*") ); - foreach( const QString &it, obsoleteCovers ) - //34@ is for playlist album cover images - if ( !it.startsWith( size ) && !it.startsWith( "50@" ) && !it.startsWith( "32@" ) && !it.startsWith( "34@" ) ) - QFile( cacheDir.filePath( it ) ).remove(); - - PERF_LOG( "done cover handling" ) + if( ( firstTime && !Amarok::config().readEntry( "HiddenOnExit", false ) ) + || !AmarokConfig::showTrayIcon() ) + { + PERF_LOG( "showing main window again" ) + m_mainWindow->show(); + PERF_LOG( "after showing mainWindow" ) + } } }
just a little fact i have missed in argumentation: cover art can also be very large. most likely 1 to 2 MB of size a single image, some (rare) times 3 to 13MB. depends on the compression rate and resolution. Loading 50 x 2mb files (100 MB) at expanding a artist plus rescaling is much work, even for local hard drives, so chaching would realy be useful. i dont know what you think about when caching sould happen, but my opinion is that it would be good to cache on scanning the collection plus cache on expanding if no chache image exists (i.e. for shared databases where only one people scans). It also would be good to implent Cover Caching in a general way so plugins like coverbling (or what will be next) can also use it to save higher resolution cached images, as they use many covers. i dont like the idea to have 1000'ths of thumb images flying around in filesystem (like internet explorer does for caching). storing in a container file will give better (? not sure, but i think so) random access performance and avoid having 1000'th of files (like firefox does with caching) in the filesystem.
I also want to add - also cache the whole media sources list (if there is RAM available on the system, you may add some advanced tab in amaork configure tool). When I click an album it just takes some pause to show the songs and them with a jerk it opens. And then later when I close or open it it happens with slide animation. If its cached early it will be smooth functioning.
That jerking behaviour is not related to caching; it's something to do with the tree view implementation. I'd want to fix that also, but even if it was made to open smoothly that pause will still occur the first time it is done.
Well agreed as you obviously know more being the developer. However to expand an album in tree it takes quite a few seconds and hdd activity.
(In reply to comment #7) cover thumbnail caching is already done the first time that cover is loaded. After that the thumb is used and not the full size image. It's not cover specific. Most images used in amarok are cached the same way. (In reply to comment #10) Imagine how many seconds and the amount of hdd activity will ensue if that happened for the entire collection.
(In reply to comment #10) > Well agreed as you obviously know more being the developer. However to expand > an album in tree it takes quite a few seconds and hdd activity. Also, tracks in the collection browser are "lazy loaded" from the database. This is to drastically decrease memory usage and increase general navigation speed in the collection browser (think of people with tens or hundreds of thousands of tracks). It shouldn't take a long time, but it is normal for there to be a slight delay (should be on the order of less than half a second). If for some reason your machine is already loaded and the SQL query hiccups then it could account for some of the delay.
Tried approx 1100 albums with covers on a modern PC with SSD. While Amarok was starting up, loading covers for them all was done during less than 2.5 seconds and the browser was ready to display. The album cover cache resides in ~/.local/share/amarok/albumcovers/cache - not sure since when, but that should cover the original described issue. There's also mentions of sluggishness when expanding tree items in later comments, but there's another bug report for that, I think, so closing this one.