Bug 344655

First things first: please check that you have write permissions in your $HOME and in the folders where your music is. Without write permissions there is no way Amarok can build a collection.

Also, if you are running Ubuntu instead of Kubuntu, you should make sure you have Amarok and all MySQL dependencies installed correctly. Also activating the Kubuntu PPA and Kubuntu backports PPA is highly recommended.

Then please run amarokcollectionscanner as a standalone (without having Amarok running) and see where it stalls. This is most often caused by a faulty file.

The command is amarokcollectionscanner -r ~/your/music/directory

And as suggested by this command: you really should have your music files in a dedicated folder, any faulty file on your system can cause the scanner to abort

Thanks. I ensured writing permissions all the way down to ~/.kde/share/apps/amarok/ (already had rwx for owner) and to the music folder (already had rwx for owner and group) - so this shouldn't be an issue. The music folder is in fact a dedicated one, but there are other files included that somehow correlate to the music (lyrics, covers, origins etc) which I'm not allowed to remove.

I also rechecked mariadb server and client were installed (which was the case). But a direct call to amarokcollectionscanner should be working fine even without these installed, right?

When calling amarokcollectionscanner -r /media/data/music it crashes as described above, and the stdout/stderr-files don't point out which file(s) caused the crash:

xxx@xxx:~/Desktop$ amarokcollectionscanner -r /media/data/music/ > amarokdb.xml 2> amarokdb.xml
Segmentation fault (core dumped)

Before the crash the scanner works for some minutes, after the crash the stdout log file contains ~ half a million of lines (they seem fine), and the stderr log file contains warnings about all the non music files (txt etc.), so nothing special either. How should I best find out "where it stalls", as you suggested?

Thanks

PS: yes, the system in fact uses Gnome Shell, so Kubuntu PPA and Kubuntu backports PPA could help. I'm going to try that out next.

Just added Kubuntu PPA and Kubuntu backports PPA and reinstalled Amarok (hope my steps were correct):

add-apt-repository ppa:kubuntu-ppa/backports
add-apt-repository ppa:kubuntu-ppa/ppa
apt-get update
apt-get purge amarok && apt-get autoremove
apt-get install amarok

Installed Amarok version: 2:2.8.0-0ubuntu3, exactly the same behaviour as before.

Well, I can tell you what is wrong: your MariaDB installation. Amarok is compiled by default for MySQLe ( or optionally a MySQL server) use in Kubuntu, so if you are using another database version, you will have to recompile it against MariaDB. There is really no reason to use MariaDB, as MySQL is default on Kubuntu. If you change the default installation, you also have to recompile packages so they fit the changed settings

Ok, completely removed MariaDB. Without having anything related to MariaDB or MySQL installed, amarokcollectionscanner still shows exact same behaviour (I know that this seems to be dependend somehow - but shouldn't it be independend?)

Installed MySQL server and client (5.5.41-0ubuntu0.14.04.1), did not configure the MySQL database yet (ensured that the schema was dropped; Amarok is configured to to not use MySQL anyway). amarokcollectionscanner still shows exactly same behaviour (stdout/stderr look exactly the same).

How can I find out which file amarokcollectionscanner is trying to process when it crashes?

Thanks

I am pretty sure there are some missing libraries due to your database system changes. In particular, you should have the following packages:

mysql-common
libmysqlclient18
mysql-cleint-core-5.5
libmysqld-pic
mysql-server-core-5.5

libmysqld-pic and libmysqlclient-dev (dependency?) were both not installed. Installed them, but still exactly the same amarokcollectionscanner behaviour. Just to ensure we are meaning the same here: these packages are required to be installed for amarokcollectionscanner to work correctly, even if amarokcollectionscanner is called by hand and without Amarok actually using MySQL?

Those are required to ensure you can actually have a working database, yes. And Amarok is using MySQLe by default, the use of a separate MySQL server is just an option.

did you check the last file where amarokcollectionscanner is chocking on? Usually these are the cause for amarokcollectionscanner to abort. Mind you, this is not a crash, it is an abort because it finds unsuitable files. Move the respective file away and try again.

I'm well aware that for Amarok MySQL is an option, and that depending on configuration either MySQLe or MySQL libraries are needed for a working *Amarok* database. But does *amarokcollectionscanner* - which outputs XML to stdout - really need MySQL to work? (I wouldn't mind if it would need MySQLe to work, but MySQL?)

I seem to not understand what you mean by the amarokcollectionscanner exit by a seg fault signal is not a crash. I'm not talking about Amarok but amarokcollectionscanner. Of course Amarok does not crash if the collection scanner crashes, but I'm directly calling amarokcollectionscanner from terminal.

I already pointed out that I would like to check which is the last file amarokcollectionscanner is chocking on - but, unfortunately, I don't find any corresponding logfiles. This is my main problem - since the bugreport I can't track down the file(s) that are problematic for amarokcollectionscanner. Could you point me out how to do so?

You can start the amarokcollectionscanner by hand.
There is a -h option to get a short list of parameters.
You will probably need "-r" for something sensible.
The result will be a .xml file where you can see which was the last file that was scanned successfully.

When Amarok is using the scanner it will restart it for a couple of tries and jump over offending files.
The reason for this mechanism is that we just can't be sure that taglib behaves sensible for all strange kind of input files and so it was decided to go this way.

Thanks. I'm already using amarokcollectionscanner by hand with -r and optionally -s (see above). The resulting XML in fact just shows files that were ok, but don't point out which file *is* processed when amarokcollectionscanner crashes. Hence with the > 100000 files I have here it's difficult to find out which files could cause the troubles. 

PS: can I configure how often Amarok restarts amarokcollectionscanner to jump over offending files? Maybe that could resolve the issue as well with Amarok just jumping over all problematic files (may take long, but that's not an issue for me).

Hi,
you are right. However you can see what is not included in the xml file.
It' usually the next folder in alphabetic order.

Amarok "should" (and I am not sure on that) report crashes and the offending files.

You can of course always use gdb to find out which file is causing issues.

Hey, thanks for the suggestion. I already tried that: the order amarokcollection goes through the files seems random, although it always processes all files inside the last subdirectory. E.g. all tracks from one album, but the other albums are checked neither directly before or after. Nevertheless I tried moving away the alphabetically next folder, but it didn't change amarokcollectionscanner behavior (still crashes with exactly same output).

The underlying FS is ext4 (and all files got freshly copied here using cp shortly before configuring Amarok). Could it the way the inode system of ext4 works that causes strange order of files with amarokcollectionscanner? ls -u shows that the subfolders inside the music folder are not sorted alphabetically. Hence I also tried moving away the folder right after the last one listed as processed in amarokcollectionscanner XML output before it crashes - but that didn't chance it's behaviour either, still crashes at the same point.

To clarify: all albums of an artist are subfolders within on folder. amarokcollectionscanner bunch processes all files inside one album, but none of the other albums from the same artist are processed directly before or after. So I cannot predict which album contains the problematic file based on the last, successfully processed album.

Any news on this? Still waiting for a backtrace, please see also https://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB

FWIW: since the collection scanner works through individual subdirectories recursively, you can easily tell which file is the offending one, as it follows the last one processed correctly.

see also the --help option for more details on the collection scanner

Hello Miriam,

"FWIW: since the collection scanner works through individual subdirectories recursively, you can easily tell which file is the offending one, as it follows the last one processed correctly." - no, see comment #13.

I've not been able to get any backtrace from Amarok so far - if you know how to do so please provide me the details.

Best

(In reply to _F_ from comment #16)
> Hello Miriam,
> 
> "FWIW: since the collection scanner works through individual subdirectories
> recursively, you can easily tell which file is the offending one, as it
> follows the last one processed correctly." - no, see comment #13.
> 
> I've not been able to get any backtrace from Amarok so far - if you know how
> to do so please provide me the details.

Check out the link I gave you :)

Created attachment 92134 [details]
Apport crash log from /var/crash

Produced by steps described in variant #3 in the post.

Thanks. After installing amarok debugging symbols I've tried several approaches using gdb (#3 is probably the one you want to look at), all by following https://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_with_GDB:


#1 "Retrieving a backtrace with GDB"

echo "--debug" > parameters
gdb amarok > gdb-stdout 2> gdb-stderr
(gdb) run < parameters
"settings" -> "configure amarok..." -> "local collection" -> "full rescan"
Many errors like this one start get piped to gdb-stderr: 
"It is of size 1048576 bytes but we need more than 1163070 bytes. 
void CollectionScanner::ScanningState::writeFull() QSharedMemory is too small to hold the data."
After some minutes apport reports a crash, see apport log (taken from /var/crash/)

gdb-stdout does not contain any useful information concerning the crash at this point. gdb-stderr only contains these errors (last lines of the log):
"[...]
It is of size 1048576 bytes but we need more than 1162880 bytes. 
void CollectionScanner::ScanningState::setLastFile(const QString&) QSharedMemory is too small to hold the data. 
It is of size 1048576 bytes but we need more than 1162986 bytes. 
QWidget::setMinimumSize: (Media Sources dock/BrowserDock) Negative sizes (200,-1) are not possible"

"(gdb) thread apply all backtrace" does not print anything, it just droppes me back to the gdb promt.



#2 "Retrieving a backtrace when an uncaught exception is causing a crash"

echo "--debug" > parameters
gdb amarok > gdb-stdout 2> gdb-stderr
(gdb) start < parameters
(gdb) set logging file gdblog.txt
(gdb) set logging on
(gdb) break __cxa_throw
(gdb) break __cxa_rethrow
(gdb) cont
"settings" -> "configure amarok..." -> "local collection" -> "full rescan"
Many errors like this one start get piped to gdb-stderr: 
"It is of size 1048576 bytes but we need more than 1163070 bytes. 
void CollectionScanner::ScanningState::writeFull() QSharedMemory is too small to hold the data."
After some time the errors stop showing up in gdb-stderr, last lines are again:
"[...]
It is of size 1048576 bytes but we need more than 1162986 bytes. 
QWidget::setMinimumSize: (Media Sources dock/BrowserDock) Negative sizes (200,-1) are not possible"

At this point I assume the error has happened (I can't tell from Amarok's UI as it is not frozen due the collectionscanner runs separately), but logs seem to not contain any useful information.



#3 "Retrieving a backtrace with GDB" with forking disabled/syncing enabled

echo "--debug --nofork --sync" > parameters
gdb amarok > gdb-stdout 2> gdb-stderr
(gdb) run < parameters
"settings" -> "configure amarok..." -> "local collection" -> "full rescan"
Many errors like this one start get piped to gdb-stderr: 
"It is of size 1048576 bytes but we need more than 1163070 bytes. 
void CollectionScanner::ScanningState::writeFull() QSharedMemory is too small to hold the data."
Again, after some time the app crashes, see apport log (taker from /var/crash/). Sadly, also here "(gdb) thread apply all backtrace" does not print anything, it just droppes me back to the gdb promt.

gdb-stderr just contains the lines shown above,  gdb-stdout contains 

"(gdb) run < parameters
Starting program: /usr/bin/amarok < parameters
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 22842) exited normally]
(gdb) thread apply all backtrace
(gdb)"

So my hope now lies on that the apport log contains info that is useful for you (see attachment in post above).

Created attachment 92138 [details]
stripped crash report from Apport

stripped the apport crash as it contained a binary core dump...

Any possibility I can debug amarokcollectionscanner (alone, without amarok) with gdb? The following seem to not be working, as the parameters handled via gdb to amarokcollectionscanner are not recognized: 

echo " -r /media/data/music/" > parameters
gdb amarokcollectionscanner > gdb-stdout 2> gdb-stderr
(gdb) run < parameters

amarokcollectionscanner just prints usage information to stdout:

For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from amarokcollectionscanner...Reading symbols from /usr/lib/debug/.build-id/1a/0f42ee56fead3461b2dc54b35557dac93f6ee9.debug...done.
done.
(gdb) 
(gdb) run < parameters
Starting program: /usr/bin/amarokcollectionscanner < parameters
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Amarok Collection Scanner
Scans directories and outputs a xml file with the results.
For more information see http://community.kde.org/Amarok/Development/BatchMode

Usage: amarokcollectionscanner [options] <Folder(s)>
User-modifiable Options:
<Folder(s)>             : list of folders to scan
-h, --help              : This help text
-v, --version           : Print the version of this tool
-r, --recursive         : Scan folders recursively
-i, --incremental       : Incremental scan (modified folders only)
-s, --restart           : After a crash, restart the scanner in its last position
    --idlepriority      : Run at idle priority
    --sharedmemory <key> : A shared memory segment to be used for restarting a scan
    --newer <path>      : Only scan directories if modification time is newer than <path>
                          Only useful in incremental scan mode
    --batch <path>      : Add the directories from the batch xml file
                          batch file format should look like this:
   <scanner>
    <directory>
     <path>/absolute/path/of/directory</path>
     <mtime>1234</mtime>   (this is optional)
    </directory>
   </scanner>
                          You can also use a previous scan result for that.

[Inferior 1 (process 19086) exited normally]
(gdb)

The amarokcollectionscanner is set to abort when it encounters a bad file, so check your xml file, as it will tell you which files are scanned correctly. The bad file would be the next in that directory, in alphabetical order, if it is at the end of a folder the first file in the next folder, still in alphabetical order. Try running the collectionscanner with -rv to get a verbose output.

That is not a segmentation fault AFAICS, or does it really print that out? Aborting doesn't mean a crash.

Thanks Miriam, to clarify: amarokcollectionscanner crashes with a segfault (stated clearly in the issue itself and in comment #2, comment #11 and comment #13). For comment #21 you are right, there is no crash - this is because I somehow incorrectly handle parameters to amarkcollectionscanner through gdb (for debugging the reported crash) and would appreciate help for that minor problem as well.

"The bad file would be the next in that directory, in alphabetical order, if it is at the end of a folder the first file in the next folder, still in alphabetical order. Try running the collectionscanner with -rv to get a verbose output."

The last thing amarokcollectionscanner reports in the xml is finishing all files in a music album (I have a music-collection->interpret->album->track structure here). All files in that folder are in fact in alphabetical order, but the ALBUMS ARE NOT, not even the ones from the same interpret (see comment #13, comment #14, comment #15 and comment #16). Hence I don't have any clue which album is touched my the scanner when it crashes (as there is nothing in the xml after the last finished album, it seems to be the alphabetically first file in a new folder). I don't know my amarokcollectionscanner behaviour differs here from the expected behaviour, but I'm happy to provide details if you state which and how to obtain them :)

Concerning parameters -rv, in my 2.8.0 amarokcollectionscanner (the ones from backports for Ubuntu 14.04), -v is for version:

       -v, --version
              Show version information

If the albums are folders, the same rule applies, if not, I strongly suggest you organize your music in that way.(In reply to _F_ from comment #23)
> Thanks Miriam, to clarify: amarokcollectionscanner crashes with a segfault
> (stated clearly in the issue itself and in comment #2, comment #11 and
> comment #13). For comment #21 you are right, there is no crash - this is
> because I somehow incorrectly handle parameters to amarkcollectionscanner
> through gdb (for debugging the reported crash) and would appreciate help for
> that minor problem as well.

Try this:

gdb amarokcollectionscanner
run (list of arguments) of course without the brackets

When the crash happens

thread apply all bt
> 
> The last thing amarokcollectionscanner reports in the xml is finishing all
> files in a music album (I have a music-collection->interpret->album->track
> structure here). All files in that folder are in fact in alphabetical order,
> but the ALBUMS ARE NOT, not even the ones from the same interpret (see
> comment #13, comment #14, comment #15 and comment #16).

For the system, the folders are also treated in alphabetical order, so the crash is likely triggered by the first track of the next album (provided you have nothing else in the previous folder, after the track file)

> Hence I don't have
> any clue which album is touched my the scanner when it crashes (as there is
> nothing in the xml after the last finished album, it seems to be the
> alphabetically first file in a new folder). I don't know my
> amarokcollectionscanner behaviour differs here from the expected behaviour,
> but I'm happy to provide details if you state which and how to obtain them :)
> 
> Concerning parameters -rv, in my 2.8.0 amarokcollectionscanner (the ones
> from backports for Ubuntu 14.04), -v is for version:
> 
>        -v, --version
>               Show version information

oops, sorry, I expected this to be the verbose option.

I just wonder why you use mariadb and not the default MySQLembedded Amarok uses, could be part of the problem why you can't get your collection. Ubuntu (and Kubuntu) use MySQL as default, not MariaDB, so that might be a bad setup?

I've removed MariaDB / MySQL a long time ago, completely pruned and reinstalled different versions of Amarok since then - I can assure you, MariaDB / MySQL is not part of the problem ;)

To further clarify the non-alphabetical-order-issue I'm appending the last piece of the amarokcollectionscanner XML output before the SEGFAULT, generated by:

amarokcollectionscanner -r /media/data/music/ > gdb-stdout-xml 2> gdb-stderr

"If the albums are folders, the same rule applies, if not, I strongly suggest you organize your music in that way.(In reply to _F_ from comment #23)"

What do you mean by reorganize? If you mean bring files/folders in alphabetical order: that's not something users can infuence. I meant: amarokcollectionscanner does NOT process folders in alphabetical order, and I don't understand why. But I further understand that ext4 style "avoiding of fragmentation by spreading files across the FS" can cause non-alphabetical arrangement of files on the FS itselt. My guess is that it is highly unlikely that this is causing the problem (this is usually compensated by lower-lvl-commands such as ls auto-sorting files alphabetically, and I really hope you use those to access the FS), and even if that would really be the problem: that's no something users can change by file re-arrangement (users usually can't influence how their files and folders are sorted on the FS as it's intentionally done automatically).


Debugging amarokcollectionscanner directly with gdb works with the updated call:

gdb amarokcollectionscanner > gdb-stdout-xml 2> gdb-stderr
(gdb) run -r /media/data/music/
[...]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5aad9ad in ?? () from /usr/lib/libtag-extras.so.1
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fc27c0 (LWP 1620)):
#0  0x00007ffff5aad9ad in ?? () from /usr/lib/libtag-extras.so.1
#1  0x00007ffff5aafa66 in TagLibExtras::RealMedia::File::~File() () from /usr/lib/libtag-extras.so.1
#2  0x00007ffff5aafa99 in TagLibExtras::RealMedia::File::~File() () from /usr/lib/libtag-extras.so.1
#3  0x00007ffff5d552e6 in ?? () from /usr/lib/x86_64-linux-gnu/libtag.so.1
#4  0x00007ffff76d1af9 in Meta::Tag::generateUniqueId (path=...) at ../../shared/MetaTagLib.cpp:149
#5  0x00007ffff76d2fb4 in Meta::Tag::readTags (path=...) at ../../shared/MetaTagLib.cpp:269
#6  0x00007ffff76dbc26 in CollectionScanner::Track::Track (this=0x8bd5c0, path=..., directory=<optimized out>) at ../../shared/collectionscanner/Track.cpp:77
#7  0x00007ffff76d7007 in CollectionScanner::Directory::Directory (this=<optimized out>, path=..., state=0x7fffffffdd00, skip=<optimized out>)
    at ../../shared/collectionscanner/Directory.cpp:114
#8  0x0000000000405218 in CollectionScanner::Scanner::doJob (this=0x7fffffffdcc0) at ../../../utilities/collectionscanner/CollectionScanner.cpp:213
#9  0x00007ffff7a8ac1e in QObject::event (this=0x7fffffffdcc0, e=<optimized out>) at kernel/qobject.cpp:1194
#10 0x00007ffff7a724dd in QCoreApplication::notifyInternal (this=0x7fffffffdcc0, receiver=receiver@entry=0x7fffffffdcc0, event=event@entry=0x63f490)
    at kernel/qcoreapplication.cpp:953
#11 0x00007ffff7a75b3d in sendEvent (event=0x63f490, receiver=0x7fffffffdcc0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#12 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x6140c0) at kernel/qcoreapplication.cpp:1577
#13 0x00007ffff7a75fe3 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1470
#14 0x00007ffff7a9ff83 in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236
#15 postEventSourceDispatch (s=0x627600) at kernel/qeventdispatcher_glib.cpp:287
#16 0x00007ffff66f7e04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff66f8048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff66f80ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff7a9f7a1 in QEventDispatcherGlib::processEvents (this=0x621e50, flags=...) at kernel/qeventdispatcher_glib.cpp:434
#20 0x00007ffff7a710af in QEventLoop::processEvents (this=this@entry=0x7fffffffdc70, flags=...) at kernel/qeventloop.cpp:149
#21 0x00007ffff7a713a5 in QEventLoop::exec (this=this@entry=0x7fffffffdc70, flags=...) at kernel/qeventloop.cpp:204
#22 0x00007ffff7a76b79 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#23 0x00000000004036d0 in main (argc=3, argv=<optimized out>) at ../../../utilities/collectionscanner/CollectionScanner.cpp:72

But that still does not point out which file causes the problem, does it?

Created attachment 92211 [details]
last lines of amarokcollectionscanner XML output before the segfault

hm, you removed MySQL after installing Amarok? Or did you install Amarok and checked that mysqle is indeed installed?

The crash shows a problem with taglib (which is tracked on github, not in bugs.kde.org unfortunately) and apparently the crash happens in ", m_charset( false )". Do you have your system set to UTF only? Mabye one file or folder has a character that is not allowed in the file or folder name? I think of {,}, & or % in particular...

Moved to https://github.com/taglib/taglib/issues/525

This is not really a TagLib bug. It's an old bug in the TagLib-Extras package, which was written by some of the Amarok devs.

https://bugs.kde.org/show_bug.cgi?id=252805
https://bugs.kde.org/show_bug.cgi?id=257289

http://websvn.kde.org/trunk/kdesupport/taglib-extras/

Hey, any news on this one? Unfortunately, I'm still unable to use Amarok atm :(

(In reply to _F_ from comment #30)
> Hey, any news on this one? Unfortunately, I'm still unable to use Amarok atm
> :(

see the questions in comment #27, please

Dear Myriam,

yes, my system is set to UTF-8:
$ echo $LANG
en_US.UTF-8

I've replaced all {, }, & and % characters in the music collection file names now. These affected a huge amount of files (something in the thousands). Some of these files have been in the collection for many years while amarokcollectionscanner did work properly, so I guess this was not the problem.

Concerning MySQL: after you mentioned that MySQL and similar might be problematic in my setup I removed everything MySQL related and configured amarok to not use an external MySQL DB anymore in its settings starting with comment #5. So my guess would be that MySQL too is no longer part of the problem, but that some tags etc. just cause the amarokcollectionscanner to crash (see crash log of comment #25)

Any ideas what I could do next to find out which files cause the scanner to crash?

To clarify: removing all {, }, & and % characters from the file names did not stop amarokcollectionscanner from crashing - the problem still exists.

Which exact Kubuntu version do you run currently? Did you try with a new user?

I'm using Ubuntu 14.4.3 LTS. Yes, I just tried with another user, amarokcollectionscanner runs into the segfault with that user too.

I just wonder: how about removing Amarok completely (with purge), and the reinstall it, and use a completely default setup (no changes in MySQL on your behalf)? You should also remove the amarok* configuration files located in ~/.kde/share/config/ 
Another option would be to use Amarok 2.9 beta, there have been changes made to the database and it is ahead of Amarok 2.9 by several hundred commits.

FWIW: if it crashes on a particular tag then we can only guess, how did you tag your files? Are you sure there are no restricted characters in those tags?

Changing status

Seems to be a duplicate of a taglib-extras bug. Fixing should happen there (although probably won't, as last commit in taglib-extras was 8 years ago), closing.

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