Bug 180248

Summary:	Collection Scanning Hang 100% CPU
Product:	[Applications] amarok	Reporter:	Andy <dr.diesel>
Component:	Collections/Local	Assignee:	Amarok Developers <amarok-bugs-dist>
Status:	RESOLVED DUPLICATE
Severity:	crash	CC:	net-account, nietzsche.w.friedrich
Priority:	NOR
Version:	2.0.1
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	"amarok-nightly --debug" available information by scrolling with kate

Description Andy 2009-01-10 13:54:50 UTC

Version:           amarok-2.0.1-1.fc10.i386 (using KDE 4.1.3)
OS:                Linux
Installed from:    Fedora RPMs

Running Amarok 2.0.1 build Date Jan 6th.  Amarok was started with amarok --debug.  Collection scanner after 2 days of processing is only at 68%.

There is no disk activity and no network activity and my collection is stored on a NFS share.  Console output seems to only be this Parsing IMAGE popping up every 5 minutes or so:

amarok: BEGIN: bool Meta::SqlPlaylist::saveToDb(bool) 
amarok:      Checking  "/main/uploads/MP3s/mp3/Various Artists (Soundtrack) - 28 Days Later OST.m3u"  against db 
amarok:      Got existing playlist with id  174 
amarok:      Updating existing playlist 
amarok: END__: bool Meta::SqlPlaylist::saveToDb(bool) - Took 0.0054s 
amarok: BEGIN: virtual SqlPlaylistViewItem::~SqlPlaylistViewItem() 
amarok: END__: virtual SqlPlaylistViewItem::~SqlPlaylistViewItem() - Took 5.8e-05s 
amarok: END__: bool PlaylistManager::save(const QString&) - Took 0.72s 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:

 
Wait a minute, just found this, notice the duration of PlaylistManager::save.

amarok:      Checking  "/main/MP3/Unsorted/The Rolling Stone Magazines 500 Greatest Songs Of All Time/000 - The Rolling Stone Magazines 500 Greatest Songs Of All Time.m3u"  against db 
amarok:      Got existing playlist with id  172 
amarok:      Updating existing playlist 
amarok: END__: bool Meta::SqlPlaylist::saveToDb(bool) - Took 0.2s 
amarok: BEGIN: virtual SqlPlaylistViewItem::~SqlPlaylistViewItem() 
amarok: END__: virtual SqlPlaylistViewItem::~SqlPlaylistViewItem() - Took 5.4e-05s 
amarok: END__: bool PlaylistManager::save(const QString&) - Took 44s 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:

It is actually amarok at 100% and not the collection scanner process.  The collection_scan.log file only shows a single entry = /main/MP3/Thumbs.db.

Please let me know how to help further.

Comment 1 Mark Kretschmann 2009-01-10 17:08:56 UTC

Would it be possible that you attach this particular image here? Otherwise this is hard to debug for us.

Comment 2 Andy 2009-01-10 17:14:15 UTC

Mark, I'm beginning to think this image is not the cause.  It has been processing for hours, since I first posted the bug, is now at 71% but has not written any more debug info.  I would think the collection scan percentage would not increment if it was still stuck on the same image?

If I run this in gdb is it possible to output what fucntion/thread is hug/hogging or looping?

Comment 3 Mark Kretschmann 2009-01-11 17:54:55 UTC

*** Bug 180346 has been marked as a duplicate of this bug. ***

Comment 4 Andy 2009-01-11 23:24:22 UTC

Ok, after the collection scanning got to 76% I quit the application, actually had to kill the task.  But when I fired it back up the collection was there and Amarok did not attempt or try to continue scanning?  v2 doesn't show the song count but the majority must been there.

I've installed today's 2.0.1.1 (Fedora repo) and completely blasted the configs/DBs and deleted the Thumbs.db file from post 1 and fired up a new scan.

Comment 5 Carlos Mata 2009-01-18 14:19:01 UTC

I want to confirm this bug, it has been around for ~10 days (more or less). From one neon nightly update to another my entire collection wasn't anymore available in the collection browser but the correct ratings etc. are shown for songs that are in the playlists. After launching amarok it spikes to 100% CPU usage while the collection scanner is running. I didn't do anything to my collection for this bug to happen (collection is local).

Comment 6 mathesis 2009-01-24 23:10:29 UTC

I confirm this bug.
Each update I hope this is fixed but it is not.
Amarok2 is not workable if the collection cannot be scanned properly.

Comment 7 Carlos Mata 2009-01-24 23:59:13 UTC

I recovered from the 100% CPU doing this:
1. turn off "watch folders for changes"
2. restart amarok
3. let the collection scanner recan the collection

during the rescan amarok still is at 100% cpu but the scan completes as
usual and after that my collection is again available.

I suspect that this bug will return, when I turn on the watch 
folders option again.

Comment 8 mathesis 2009-01-25 00:09:58 UTC

Thanks Carlos, but unfortunately it doesn't work with my system. The scan still freezes at 85%.

Comment 9 mathesis 2009-01-25 15:29:09 UTC

Note: I can't avoid the collection being scanning because if I try to remove any folder to be scanned and click OK or apply, amarok crashes. At next start, amarok remembers the folder(s) to be scanned.

I attach the amarok-nightly --debug (only the end, don't know how to get the whole information with Kate) for information as I would like this bug status being changed to confirmed.

Comment 10 mathesis 2009-01-25 15:30:52 UTC

Created attachment 30588 [details]
"amarok-nightly --debug" available information by scrolling with kate

Incomplete debug information (only the end).
I'm up to date regarding the nightlies.

Comment 11 Andy 2009-01-26 23:20:56 UTC

I built 2.1 SVN for testing, currently on 50 hours and collection scanning is up to 68%, the amarok process is/has been at 100%.

It appears to be "stuck" between parsing images?  I have thousands of the below.  The collectionscan.log file is empty.

amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:
 
amarok:  Parsing IMAGE:

Comment 12 Mark Kretschmann 2009-01-30 22:24:42 UTC

Ok, I think what we are dealing with here is a subset of the general scanner issues, which we already have a bug report for.

So I'm closing this report as a dupe - please see the sibling report for details.


*** This bug has been marked as a duplicate of bug 176154 ***

Comment 13 Carlos Mata 2009-02-01 14:13:56 UTC

Well, I don't think that it is a scanner issue because invoking amarokcollectionscanner manually works perfectly and amarok2 is the culprit.

Comment 14 Mark Kretschmann 2009-02-01 15:54:45 UTC

@Carlos: That may be so, but the scanner really consists of two parts, the amarokcollectionscanner binary, and then the part inside of Amarok 2 that talks to it.