Bug 138913 - high cpu usage and slow reaction when cover-less songs/albums are involved
Summary: high cpu usage and slow reaction when cover-less songs/albums are involved
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 138682 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-17 14:14 UTC by highelf
Modified: 2006-12-24 13:58 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
gdb output with --enable-debug=full turned on (23.74 KB, text/plain)
2006-12-18 17:59 UTC, Justace Clutter
Details
gdb output with --enable-debug=full turned on (36.94 KB, text/plain)
2006-12-18 18:12 UTC, Justace Clutter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description highelf 2006-12-17 14:14:15 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Gentoo Packages
Compiler:          gcc 4 
OS:                Linux

since about one week amarok is taking a lot of time to start (240sec). It is also reacting very slow to click interaction (add song to playlist and stuff).
Hurra has the same issue and pointed to me, that the slowliness (and high cpu usage) will only occurs when interacting with songs without covers. 
A quick test confirmed it:
load a coverless album to your playlist. Select right-click queue Track. It take long time (5 s).
Then add a cover to that album, queue the next song, very fast.

Running amarok-svn on gentoo with p4 3 GHz and 1.5 GB ram.
highelf.
Comment 1 Lorenz Röhrl 2006-12-17 14:17:23 UTC
Hi

I deleted my complete amarok and did a very clean install, but still the same problems.

One thing from debug-log that might be interesting:
amarok: BEGIN: void CurrentTrackJob::showArtistsAlbums(const QString&, uint, uint)
amarok: END__: void CurrentTrackJob::showArtistsAlbums(const QString&, uint, uint) - Took 6.5s


Thanks
Cu hurra
Comment 2 Ljubomir 2006-12-17 15:28:29 UTC
Coverless albums takes ages to expand in Collection Browser, right click on no-cover image blocks UI for ~3-4s until menu shows. It also takes ~5 minutes to load amarok, with and without playlist. Using clean checkout from this morning, Ubuntu Dapper, x86. 

Oh, and full rescan of 60 GB of local files took me 20-30 minutes. I recall it to be faster in the past?
Comment 3 Ljubomir 2006-12-17 15:29:34 UTC
*** This bug has been confirmed by popular vote. ***
Comment 4 georg 2006-12-17 15:37:57 UTC
same here, got amarok-svn earlier that week and had non-cover-track-problems as mentioned above from the beginning. i'm on ubuntu dapper, amd64. 
Comment 5 Ricardo Silva 2006-12-17 18:07:08 UTC
Add me to the list of users noticing that problem!

This has happened after upgrading to the svn version just a few days ago ...

I've deleted all the config files and restarted the program ...
I've recompiled amarok ...
I've reduced the number of albums in the collection ...
But all remains the same!
Every single click takes more than 20 secs to get a response.

I'm using Suse 10.1 under a P IV 2.4 with 768 MB RAM
Comment 6 Justace Clutter 2006-12-18 17:59:21 UTC
Created attachment 18969 [details]
gdb output with --enable-debug=full turned on
Comment 7 Justace Clutter 2006-12-18 18:00:42 UTC
Ok
   Well, I had made a post on the amarok forums about this and was asked to porvide some debug outputs.  I recompiled amarok svn with --enable-debug=full and then ran a few times.  I then ran amarokapp in gdb and tried to catch some stack traces when it was hanging I am attaching this output...

For reference the amarok forum link is the following:

http://amarok.kde.org/forum/index.php/topic,13451.0.html
Comment 8 Justace Clutter 2006-12-18 18:12:50 UTC
Created attachment 18970 [details]
gdb output with --enable-debug=full turned on
Comment 9 Alexandre Oliveira 2006-12-18 18:38:21 UTC
SVN commit 614698 by aoliveira:

These queries were part of the reason for all the slowness.
CCBUG: 138913


 M  +19 -17    collectiondb.cpp  


--- trunk/extragear/multimedia/amarok/src/collectiondb.cpp #614697:614698
@@ -2188,21 +2188,23 @@
     if ( artist == i18n("Various Artists") || artist.isEmpty() ) {
         // VAs need special handling to not match on artist name but instead check for sampler flag
         rs = query( QString(
-                "SELECT embed.hash, embed.deviceid, embed.url FROM tags, embed, album "
-                "WHERE tags.url = embed.url "
-                "AND tags.album = album.id "
-                "AND album.name = '%1' "
+                "SELECT embed.hash, embed.deviceid, embed.url FROM "
+                "tags INNER JOIN embed ON tags.url = embed.url "
+                     "INNER JOIN album ON tags.album = album.id "
+                "WHERE "
+                "album.name = '%1' "
                 "AND tags.sampler = %2 "
                 "ORDER BY modifydate DESC LIMIT 1;" )
                 .arg( escapeString( album ) )
                 .arg( boolT() ) );
     } else {
         rs = query( QString(
-                "SELECT embed.hash, embed.deviceid, embed.url FROM tags, embed, artist, album "
-                "WHERE tags.url = embed.url "
-                "AND tags.artist = artist.id "
-                "AND tags.album = album.id "
-                "AND artist.name = '%1' "
+                "SELECT embed.hash, embed.deviceid, embed.url FROM"
+                "tags INNER JOIN embed ON tags.url = embed.url "
+                     "INNER JOIN artist ON tags.artist = artist.id "
+                     "INNER JOIN album ON tags.album = album.id "
+                "WHERE  "
+                "artist.name = '%1' "
                 "AND album.name = '%2' "
                 "ORDER BY modifydate DESC LIMIT 1;" )
                 .arg( escapeString( artist ) )
@@ -3965,17 +3967,17 @@
         if( m_moveFileJobCancelled )
         {
             disconnect( job, SIGNAL(result( KIO::Job * )), this, SLOT(fileOperationResult( KIO::Job * )) );
-            
+
             QString partFile = QString( "%1.part" ).arg( (job->destURL()).path() );
             job->kill();
             QFile file( partFile );
             if( file.exists() ) file.remove();
-            
+
             m_waitForFileOperation = false;
             m_fileOperationFailed = true;
             continue;
         }
-         
+
          usleep( 10000 );
          kapp->processEvents( 100 );
       }
@@ -4095,12 +4097,12 @@
         if( m_moveFileJobCancelled )
         {
             disconnect( job, SIGNAL(result( KIO::Job * )), this, SLOT(fileOperationResult( KIO::Job * )) );
-            
+
             QString partFile = QString( "%1.part" ).arg( (job->destURL()).path() );
             job->kill();
             QFile file( partFile );
             if( file.exists() ) file.remove();
-            
+
             m_waitForFileOperation = false;
             m_fileOperationFailed = true;
             continue;
@@ -5163,8 +5165,8 @@
     else
 #endif
     {
-        m_dbConfig = new SqliteConfig( 
-                        Amarok::config( "Sqlite" )->readPathEntry( "location", 
+        m_dbConfig = new SqliteConfig(
+                        Amarok::config( "Sqlite" )->readPathEntry( "location",
                                         Amarok::saveLocation() + "collection.db" ) );
     }
 
@@ -5845,7 +5847,7 @@
     QString rpath = escapeString( MountPointManager::instance()->getRelativePath( deviceid, url ) );
     QStringList labelIds = query( QString( "SELECT id FROM labels WHERE type = %1;" ).arg( type ) );
     QString ids;
-    if ( !labelIds.isEmpty() ) 
+    if ( !labelIds.isEmpty() )
     {
         foreach( labelIds )
         {
Comment 10 Justace Clutter 2006-12-18 20:40:38 UTC
I did an svn up, which brought collectiondb.cpp to version 614715, which has the corrections that you have above I think...I just verified that I did.  So, the problem opn my end is not fixed though.  I have decided to run the app in a profiller to see where the hold up is.  That is taking a long time to run though...
Comment 11 Mark Kretschmann 2006-12-18 20:52:30 UTC
Nevermind, we found out what the real problem is. Looking into a fix now.
Comment 12 Alexandre Oliveira 2006-12-18 22:33:53 UTC
SVN commit 614762 by aoliveira:

This fixes the index disappearing problem.
I'm very interested on feedback about how it affects the performance.
(You'll have to rebuild your collection for the indices to come back.)
BUG: 138913


 M  +6 -3      collectiondb.cpp  


--- trunk/extragear/multimedia/amarok/src/collectiondb.cpp #614761:614762
@@ -6229,14 +6229,17 @@
     QString text = QString::fromUtf8( (const char*)zB );
 
     int begin = pattern.startsWith( "%" ), end = pattern.endsWith( "%" );
-    pattern = pattern.mid( 1, pattern.length() - 2 );
+    if (begin)
+        pattern = pattern.right( 1 );
+    if (end)
+        pattern = pattern.left( pattern.length() - 2 );
     if( argc == 3 ) // The function is given an escape character. In likeCondition() it defaults to '/'
         pattern.replace( "/%", "%" ).replace( "/_", "_" ).replace( "//", "/" );
 
     int result = 0;
     if ( begin && end ) result = ( text.find( pattern, 0, 0 ) != -1);
-    else if ( begin ) result = text.startsWith( pattern, 0 );
-    else if ( end ) result = text.endsWith( pattern, 0 );
+    else if ( begin ) result = text.endsWith( pattern, 0 );
+    else if ( end ) result = text.startsWith( pattern, 0 );
     else result = ( text.lower() == pattern.lower() );
 
     sqlite3_result_int( context, result );
Comment 13 Justace Clutter 2006-12-18 23:37:57 UTC
Cool...  It looks to be fixed.  Amarok is running super fast (maybe faster than normal) Thanks for finding the bug!  I am rescanning my collection now.
Comment 14 Alexandre Oliveira 2006-12-18 23:41:16 UTC
Just as an update, rescanning is not necessary, since it won't recreate the indices. Since r614774, they created on startup when missing.
Comment 15 Alexandre Oliveira 2006-12-19 00:12:26 UTC
*** Bug 138682 has been marked as a duplicate of this bug. ***