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.
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
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?
*** This bug has been confirmed by popular vote. ***
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.
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
Created attachment 18969 [details] gdb output with --enable-debug=full turned on
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
Created attachment 18970 [details] gdb output with --enable-debug=full turned on
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 ) {
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...
Nevermind, we found out what the real problem is. Looking into a fix now.
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 );
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.
Just as an update, rescanning is not necessary, since it won't recreate the indices. Since r614774, they created on startup when missing.
*** Bug 138682 has been marked as a duplicate of this bug. ***