Bug 240300

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.