Amarok freezes everytime I scan my collection

[hhfischer]

Binary package hint: amarok

I'm using Ubuntu 10.4 since beta 2 until final release today. I installed amarok via repo. Made updates via repo twice a week.
I was never able to scan, or rescan my collection. It happens that:
- scan freezes after maybe 5 min, no error message, amarok is crashed, collection has 0 titels or
- it scans for instance 12% of the collection, then crashes
- rescan is all the same,

today I removed /purged amarok, apt-get clean, manually deleted ....kde/shares/amarok... (I beleave)
installed amarok once again,
started via Terminal. > amarok -d
it freezes again
last messages from terminal:
---------------------------------------------------------------------------------
amarok: Skipping file with uniqueid "amarok-sqltrackuid://853dbc75f1cf4462761918c95affd333" as it was already seen this scan, file is at "/home/rudi/Musik/#_MP3-Archiv - sync/!_Alphabetisch Interpreten/_Alphabet einzeltitel/M/METHOD MAN REDMAN-rock da wilder.mp3" , original file is at "/home/rudi/Musik/#_MP3-Archiv - sync/!_Alphabetisch Interpreten/_Alphabet einzeltitel/M/METHOD MAN REDMAN- blackout.mp3"
TagLib: MPEG::Header::parse() -- Invalid sample rate.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc
amarok: BEGIN: void ScanManager::slotError(QProcess::ProcessError)
amarok: Error: 1
amarok: BEGIN: void ScanManager::handleRestart()
amarok: Collection scanner crashed, restart count is 1
amarok: END__: void ScanManager::handleRestart() - Took 0.00011s
amarok: END__: void ScanManager::slotError(QProcess::ProcessError) - Took 0.00027s
amarok: BEGIN: void ScanManager::restartScanner()
amarok: Success. Committing result to database.
amarok: END__: void ScanManager::restartScanner() - Took 0.0031s
amarok: BEGIN: void DatabaseUpdater::cleanPermanentTables()
amarok: END__: void DatabaseUpdater::cleanPermanentTables() - Took 0.0015s
amarok: BEGIN: void ScanResultProcessor::copyHashesToTempTables()
amarok: obtained max_allowed_packet is "1048576"
amarok: urls key size is 985
amarok: tracks key size is 985
amarok: END__: void ScanResultProcessor::copyHashesToTempTables() - Took 0.18s
amarok: temp_tracks: ("985")
amarok: tracks before commit: ("0")
amarok: BEGIN: void DatabaseUpdater::copyToPermanentTables()
amarok: END__: void DatabaseUpdater::copyToPermanentTables() - Took 1s
amarok: tracks after commit: ("985")
amarok: BEGIN: void DatabaseUpdater::removeTemporaryTables()
amarok: END__: void DatabaseUpdater::removeTemporaryTables() - Took 0.0016s
amarok: Sending changed signal
amarok: END__: virtual void XmlParseJob::run() - DELAY Took (quite long) 4.8e+02s
------------------------------------------------------------------------------------------------------------------------------------------------

collection_scan.log
has only one entry (Path and name of a mp3 file, no errors )
---------------------------------------------------------------------------------------------------------------------------
rudi@ubuntu13:~$ lsb_release -rd
Description: Ubuntu 10.04 LTS
Release: 10.04
---------------------------------------------------------------------------------------------------------------------------
rudi@ubuntu13:~$ apt-cache policy amarok
amarok:
  Installiert: 2:2.3.0-0ubuntu4
  Kandidat: 2:2.3.0-0ubuntu4
  Versions-Tabelle:
 *** 2:2.3.0-0ubuntu4 0
        500 http://de.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

in:
usr/bin/amarok
---------------------------------------------------------------------------------------------------------------------------------

I wonder:
In >properties > collection - I sayed: scan " home/music/mp3 " only
because in home/music/books
are many audiobooks located.

But in "collection_scan.files" are many files from the other path.
(from home/music/books)

What can I do, to be able to scan my files?

[Chris Guirl (thelusiv-gmail)]

I have the same problem (add this to the huge list of disappointments from Amarok 2 compared to 1.4). I had just become able to use it on 9.10...Sigh.

For what it's worth, here's what I get when I run amarok --debug and then rescan my whole collection.

...
TagLib: MPEG::Header::parse() -- Invalid sample rate.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
TagLib: MPEG::Header::parse() -- Invalid sample rate.
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc
amarok: BEGIN: void ScanManager::slotError(QProcess::ProcessError)
amarok: Error: 1
amarok: BEGIN: void ScanManager::handleRestart()
amarok: Collection scanner crashed, restart count is 1
amarok: Success. Committing result to database.
amarok: END__: void ScanManager::handleRestart() - Took 0.00013s
amarok: END__: void ScanManager::slotError(QProcess::ProcessError) - Took 0.00027s
amarok: BEGIN: void ScanManager::restartScanner()
amarok: END__: void ScanManager::restartScanner() - Took 0.0035s
amarok: BEGIN: void DatabaseUpdater::cleanPermanentTables()
amarok: END__: void DatabaseUpdater::cleanPermanentTables() - Took 0.0017s
amarok: BEGIN: void ScanResultProcessor::copyHashesToTempTables()
amarok: obtained max_allowed_packet is "16777216"
amarok: urls key size is 2734
amarok: tracks key size is 661
amarok: END__: void ScanResultProcessor::copyHashesToTempTables() - Took 0.22s
amarok: temp_tracks: ("661")
amarok: tracks before commit: ("0")
amarok: BEGIN: void DatabaseUpdater::copyToPermanentTables()
amarok: END__: void DatabaseUpdater::copyToPermanentTables() - Took 0.12s
amarok: tracks after commit: ("661")
amarok: BEGIN: void DatabaseUpdater::removeTemporaryTables()
amarok: END__: void DatabaseUpdater::removeTemporaryTables() - Took 0.0031s
amarok: Sending changed signal
amarok: END__: virtual void XmlParseJob::run() - DELAY Took (quite long) 5.6s

After that I have to force-quit Amarok because it just freezes.

When I restart, it does show some tracks were added to my collection, but nowhere near all of it has been scanned. Since the debug output doesn't list the individual files it is scanning, I can't be sure if it's choking on a certain file or something like that, and am unable to try to eliminate such a problem.

[Eric Lacombe (goretux)]

Hi,

I've exactly the same problem here.

[Eric Lacombe (goretux)]

It seems that the problem starts here :

[...]
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc
[...]

FYI amarok 2.3 worked perfectly fine before I update to Lucid 10.04...

[Eric Lacombe (goretux)]

I tried with amarok 2.3.1 beta 1 from ppa, and the same problem arose.
It may come from the new Qt libraries (embedded with kubuntu 10.04) that have changed somehow ?!

[AttilioSuccio (ehol)]

I can confirm I have the same log file of Chris Guirl.
I launched amarok with -debug and I attach the results
It's frustrating because with Ubuntu 9.10 my collection was correctly scannned even if I have more than 25000 files in it...

BTW : I have Ubuntu 10.04 and not Kubuntu (and I upgraded from 9.10)

[Jeff Mitchell (jefferai)]

@Chris before you get all sigh-y and piss and moan, you may want to consider the fact that this is a problem that is only affecting *buntu 10.04 users. So sigh in the right direction, please.

[Horrendus (stefan-derkits-net)]

Workaround that worked for me:

-) Scanned my Collection via amarokcollectionscanner and this Description:
http://amarok.kde.org/wiki/Batch_Mode
-) When it crashed (with above Error), I checked the File
amarokcollectionscanner_batchfullscan.log and moved the File it should have
read next outside of my Collection
-) Started the Scan again, it crashed again, but much later
-) Repeated the second Step and then started the scan again :)

This way I found out which Files crashed the collectionscanner and moved them out of my Collection.
Another tip: If you have your Collection on a NFS Share or so ... scan it directly on your Server, is much faster, especially it doesn't really hang for that long when it gets to a File where it crashes.

[Jeff Mitchell (jefferai)]

One of the affected users posted some files and it's been confirmed that this bug is nonreproducable on Arch Linux and Funtoo/Gentoo Linux. FWIW, it's also very likely not an Amarok bug at all. Most probably they have screwed up their Qt, TagLib, GLib, or glibc packages.

I'm assigning this to TagLib since it is dependent on particular files, and when that happens it's almost always a TagLib bug. But given the backtrace, it's probably not TagLib's fault either.

[Jeff Mitchell (jefferai)]

OK, I'm revising my opinion. I think it's a problem with TagLib 1.6.2 and that it's fixed in TagLib 1.6.3, which is not in 10.04. Talking to Kubuntu maintainers about it.

[Jeff Mitchell (jefferai)]

Looks like it's a known, fixed problem:

http://bugs.kde.org/show_bug.cgi?id=231075

Not really a taglib bug so much as corrupted files; the fix implements logic to handle this. Looks like the Kubuntu maintainers are just lax at getting 1.6.3 out to fix this problem.

Bad Harald, bad. No biscuit.

[Jonathan Thomas (echidnaman)]

I guess if by "lax" you mean "in final freeze" then you'd be correct.

[Jeff Mitchell (jefferai)]

So touchy. It was a joke for Harald.

But if you must get all technical, they've had more than a week since release...

[Jonathan Thomas (echidnaman)]

I don't think jokes blaming us for uncontrollable circumstances are funny. We get blamed enough for stuff as it is.

And if you really, really want to get technical, we're still in final freeze, and it's not as if 1.6.3 was touted as a major bugfix release or even announced anywhere other than the website.

[Jonathan Riddell (jr)]

Uploaded taglib 1.6.3 to lucid-proposed awaiting approval

It's a well tested bugfix only upstream release which fixes this important issue.

TEST CASE:
download http://muse.19inch.net/~jr/tmp/mp3.tar.gz

run `amarokcollectionscanner $DIR` on the directory you extracted it to. will result in a bad_alloc termination with the old taglib.

[Jeff Mitchell (jefferai)]

Having just spent the better part of an hour working through the problem with Harald on IRC, yes, I thought the joke, which was clearly targeted towards him, was fine. You're free to ignore it.

And if you really, really, really want to get technical, 1.6.3 was indeed announced -- with full details as to what bugs it fixes -- elsewhere than on the website. In fact, it was announced on the exact place you would expect to see it since it's the same place all of the release announcements are made -- the taglib-devel mailing list.

[John Dong (jdong)]

ACK from the SRU team.

[Scott Kitterman (kitterman)]

Accepted into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Jonathan Riddell (jr)]

Tested successfully. The old packages when scanning caused high CPU usage making the computer unusable. The new packages successfully scanned the file.

[Chris Guirl (thelusiv-gmail)]

Thanks for the fix folks, I tested this successfully as well with the lucid-proposed package. Sorry about the pissing and moaning, Jeff, but what can I say, I enjoy it sometimes. ;)

[Jeff Mitchell (jefferai)]

We've taken enough flack (justified and not) over A2, so when we're taking flack for something that's not actually our fault it tends to rankle :-)

[hhfischer (hhfischer)]

I testet the fix from lucid-proposed and ...it worked.
-YOU MADE MY DAY-

thanks a lot for your good work.

[Launchpad Janitor (janitor)]

This bug was fixed in the package taglib - 1.6.3-0ubuntu1

---------------
taglib (1.6.3-0ubuntu1) lucid-proposed; urgency=low

  * New upstream bugfix release, stable release update
   - Closes LP: #572432 "Amarok freezes everytime I scan my collection"
   - Fixed definitions of the TAGLIB_WITH_MP4 and TAGLIB_WITH_ASF macros.
   - Fixed upgrading of ID3v2.3 genre frame with ID3v1 code 0 (Blues).
   - New method `int String::toInt(bool *ok)` which can return whether the
     conversion to a number was successfull.
   - Fixed parsing of incorrectly written lengths in ID3v2 (affects mainly
     compressed frames). (BUG:231075)
 -- Jonathan Riddell <email address hidden> Fri, 07 May 2010 17:37:15 +0100

[Martin Pitt (pitti)]

Copied to maverick.

[devnulljp (sendittodevnull)]

Upgraded to TagLib 1.6.3 (the package taglib - 1.6.3-0ubuntu1 from the proposed repository).
It still crashes on scanning. It's not a particular file as far as I can tell.

[Jeff Mitchell (jefferai)]

You probably have a different problem than the O.P. Please post a bug on bugs.kde.org and assign me to it (and then put the URL here for refrence).

FWIW, I won't be able to help you much until you narrow down if it's a file causing your crash or Amarok. A good backtrace from Amarok will help; even better is scanning your collection on the command line via amarokcollectionscanner and seeing if you can reproduce the problem.

[domain.invalid (domain-invalid)]

Just filed a report with bugs.kde.org about 15 minutes ago. This bug still affects me. I did a clean fresh install yesterday, upgrading from Ubuntu 9.10 to 10.04, and instantly the Amarok/whatever bug stung me. My CPU usage is at least 30% to 50% as soon as Amarok is invoked, if not higher. Even when Amarok is closed down, the CPU usage remains consistently and indefinitely high. Other functions are somewhat affected, and my poor stupid machine heats up a bit. Thanks.

[domain.invalid (domain-invalid)]

Just to further note, I have experienced no crashes, but merely very high CPU usage. Perhaps I should have noted that originally. Screenshot attached showing high CPU usage.

[domain.invalid (domain-invalid)]

I experimented with killing certain processes (not just stopping or ending them), and as soon as I killed the process 'pulseaudio' my CPU levels went down to normal. This is probably not a bug directly related to Amarok, but PulseAudio again. Any fixes for this matter?

[Jeff Mitchell (jefferai)]

Ditch *buntu?