Bug 174784

Sorry, I incorrectly filed this under 'bug report no crashes'.

Created attachment 28513 [details]
Backtrace from Amarok for crash in 'import collection'

I get a similar crash when trying to import my 1.4 collection using latest ubuntu packages

Application: Amarok (amarok), signal SIGSEGV
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb3b086e0 (LWP 4166)]
[New Thread 0xae80db90 (LWP 4218)]
[New Thread 0xaf00eb90 (LWP 4217)]
[New Thread 0xaf80fb90 (LWP 4216)]
[New Thread 0xb126eb90 (LWP 4215)]
[New Thread 0xb1f40b90 (LWP 4169)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[KCrash handler]
#6  0xb065a7e8 in ?? ()
   from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#7  0xb06599cd in ?? ()
   from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#8  0xb064ee14 in ?? ()
   from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#9  0xb5fb38b0 in ?? () from /usr/lib/libthreadweaver.so.4
#10 0xb5fb3a95 in ThreadWeaver::Job::execute ()
   from /usr/lib/libthreadweaver.so.4
#11 0xb5fb2762 in ?? () from /usr/lib/libthreadweaver.so.4
#12 0xb5fb2925 in ThreadWeaver::Thread::run ()
   from /usr/lib/libthreadweaver.so.4
#13 0xb74a76ae in ?? () from /usr/lib/libQtCore.so.4
#14 0xb53b150f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb6ad17ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 4 (Thread 0xaf80fb90 (LWP 4216)):
#0  0xb7fce430 in __kernel_vsyscall ()
#1  0xb53b5075 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb6adf9ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0xb74a86f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#4  0xb5fb0bfb in ?? () from /usr/lib/libthreadweaver.so.4
#5  0xb5fb452c in ?? () from /usr/lib/libthreadweaver.so.4
#6  0xb5faf49b in ?? () from /usr/lib/libthreadweaver.so.4
#7  0xb5fb466f in ?? () from /usr/lib/libthreadweaver.so.4
#8  0xb5fb1c73 in ?? () from /usr/lib/libthreadweaver.so.4
#9  0xb5fb4691 in ?? () from /usr/lib/libthreadweaver.so.4
#10 0xb5fb1c73 in ?? () from /usr/lib/libthreadweaver.so.4
#11 0xb5fb27ad in ?? () from /usr/lib/libthreadweaver.so.4
#12 0xb5fb2925 in ThreadWeaver::Thread::run ()
   from /usr/lib/libthreadweaver.so.4
#13 0xb74a76ae in ?? () from /usr/lib/libQtCore.so.4
#14 0xb53b150f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb6ad17ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (Thread 0xaf00eb90 (LWP 4217)):
#0  0xb7fce430 in __kernel_vsyscall ()
#1  0xb53b5075 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb6adf9ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0xb74a86f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#4  0xb5fb0bfb in ?? () from /usr/lib/libthreadweaver.so.4
#5  0xb5fb452c in ?? () from /usr/lib/libthreadweaver.so.4
#6  0xb5faf49b in ?? () from /usr/lib/libthreadweaver.so.4
#7  0xb5fb466f in ?? () from /usr/lib/libthreadweaver.so.4
#8  0xb5fb1c73 in ?? () from /usr/lib/libthreadweaver.so.4
#9  0xb5fb27ad in ?? () from /usr/lib/libthreadweaver.so.4
#10 0xb5fb2925 in ThreadWeaver::Thread::run ()
   from /usr/lib/libthreadweaver.so.4
#11 0xb74a76ae in ?? () from /usr/lib/libQtCore.so.4
#12 0xb53b150f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#13 0xb6ad17ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xae80db90 (LWP 4218)):
#0  0xb7fce430 in __kernel_vsyscall ()
#1  0xb53b5075 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb6adf9ed in pthread_cond_wait () from /lib/tls/i686/cmov/libc.so.6
#3  0xb74a86f2 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#4  0xb5fb0bfb in ?? () from /usr/lib/libthreadweaver.so.4
#5  0xb5fb452c in ?? () from /usr/lib/libthreadweaver.so.4
#6  0xb5faf49b in ?? () from /usr/lib/libthreadweaver.so.4
#7  0xb5fb466f in ?? () from /usr/lib/libthreadweaver.so.4
#8  0xb5fb1c73 in ?? () from /usr/lib/libthreadweaver.so.4
#9  0xb5fb4691 in ?? () from /usr/lib/libthreadweaver.so.4
#10 0xb5fb1c73 in ?? () from /usr/lib/libthreadweaver.so.4
#11 0xb5fb4691 in ?? () from /usr/lib/libthreadweaver.so.4
#12 0xb5fb1c73 in ?? () from /usr/lib/libthreadweaver.so.4
#13 0xb5fb27ad in ?? () from /usr/lib/libthreadweaver.so.4
#14 0xb5fb2925 in ThreadWeaver::Thread::run ()
   from /usr/lib/libthreadweaver.so.4
#15 0xb74a76ae in ?? () from /usr/lib/libQtCore.so.4
#16 0xb53b150f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#17 0xb6ad17ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb3b086e0 (LWP 4166)):
#0  0xb7fce430 in __kernel_vsyscall ()
#1  0xb6a8cde6 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb6aca59c in usleep () from /lib/tls/i686/cmov/libc.so.6
#3  0xb064c10d in ?? ()
   from /usr/lib/kde4/libamarok_collection-sqlcollection.so
#4  0xb75a5dec in qDeleteInEventHandler () from /usr/lib/libQtCore.so.4
#5  0xb75a77a3 in QObject::event () from /usr/lib/libQtCore.so.4
#6  0xb6c888ec in QApplicationPrivate::notify_helper ()
   from /usr/lib/libQtGui.so.4
#7  0xb6c9076e in QApplication::notify () from /usr/lib/libQtGui.so.4
#8  0xb7a66b2d in KApplication::notify () from /usr/lib/libkdeui.so.5
#9  0xb7597e61 in QCoreApplication::notifyInternal ()
   from /usr/lib/libQtCore.so.4
#10 0xb7598ae5 in QCoreApplicationPrivate::sendPostedEvents ()
   from /usr/lib/libQtCore.so.4
#11 0xb7598cdd in QCoreApplication::sendPostedEvents ()
   from /usr/lib/libQtCore.so.4
#12 0xb75c282f in ?? () from /usr/lib/libQtCore.so.4
#13 0xb4f336f8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0xb4f36da3 in ?? () from /usr/lib/libglib-2.0.so.0
#15 0xb4f36f61 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#16 0xb75c2478 in QEventDispatcherGlib::processEvents ()
   from /usr/lib/libQtCore.so.4
#17 0xb6d22ee5 in ?? () from /usr/lib/libQtGui.so.4
#18 0xb759652a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4
#19 0xb75966ea in QEventLoop::exec () from /usr/lib/libQtCore.so.4
#20 0xb7598da5 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4
#21 0xb6c88767 in QApplication::exec () from /usr/lib/libQtGui.so.4
#22 0x0804bf70 in _start ()
#0  0xb7fce430 in __kernel_vsyscall ()

Hi everyone.
Thanks for your reports. All of your backtraces are unhelpful since they have been stripped of debugging symbols.

  (no debugging symbols found)

Is a big hint that the traces are useless.

Could you please install an amarok-debug package and submit a better trace, as this would make it much easier for me to find the source of the problem.

@Seb I installed the dbg packages but still no backtrace. I will try to figure out what is going on and post a better trace up when I do.

(In reply to comment #5)
> @Seb I installed the dbg packages but still no backtrace. I will try to figure
> out what is going on and post a better trace up when I do.
> 

You have to append the debug flag: `amarok --debug`

I'm getting a different crash now (after uninstalling yesterday and reinstalling today) so I'm not going to post mine here.

> You have to append the debug flag: `amarok --debug` 

No, this is not necessarily true. --debug will show console output from the application, but I'm not interested in this. I need a stack trace of the application leading to the crash. Here's a quick run through with gdb:

gdb amarok
r --nofork
... wait/cause crash ...
bt

Created attachment 28684 [details]
gdb output

I have attached all the output from gdb. I have included absolutely everything, but I think the stuff you'll be interested in is at the end up to "ASSERT: "!isEmpty()" in file /usr/include/qt4/QtCore/qlist.h, line 246"

I don't have any debugging knowledge - so let me know if you need more and how to get it.

Your backtrace is still invalid (missing Amarok-debug package), but this could be an interesting hint:

amarok: BEGIN: virtual void SqlCollectionLocation::insertStatistics(const QMap<KSharedPtr<Meta::Track>, QString>&) 
ASSERT: "!isEmpty()" in file /usr/include/qt4/QtCore/qlist.h, line 246

Created attachment 28685 [details]
Another dbg trace

Apologies - I thought I had it installed, but there was a dependency problem with the kde libs dbg package on my machine.

amarok-dbg is now installed, is the attached more useful? - it looks substantively similar to the untrained eye.

This is much better, yes :)

Thanks for your patience!

Stephen, the main problem with this crash is that we have an assertion coming from within QList, which for some reason doesn't let us find out the line number of where we are trying to access the invalid index.

Do you have any experience compiling applications from source? Since I cannot reproduce this, it would be very helpful if you'd be able to apply a patch for me and try again so we can track down the cause of the problem.

Hi Seb, my experience is pretty much limited to ./configure && make && make install.

However I have given it a bash. I seem to have got most of the dependencies installed but I'm not sure what to do about:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
OPENGL_gl_LIBRARY (ADVANCED)
[snip]
QT_QTOPENGL_LIBRARY (ADVANCED)

I am on ubuntu so appreciate that it will be hard for you to support me installing from packages - I don't mind building those libraries manually too.

I do have the qt4-dev-tools package installed, but can't see one that sounds promising for offering qtopengl. I do have libgl1-mesa-dev installed too... though I'm confused as opengl in the README is optional and I didn't ask for it.

Also I used the tarball rather than svn - again is this unhelpful?

As you can tell, I'm a bit out of my depth - so thanks for your help.

Scrub the qt opengl one - I now have libqt4-opengl-dev installed ... just the "OPENGL_gl_LIBRARY (ADVANCED)" dependency to fathom now.

You'll have to find the right -dev package to solve the missing dependency. Alternatively, use svn since we've removed the opengl check as it's not needed.

Seb, good news - I have successfully compiled from SVN and can reproduce the crash with my new install (though you may in fact regard the latter as bad news).

Please let me know as and when you're ready for me to test anything out for you.

Thanks Stephen. I think we can take this discussion off the bug tracker for now. I'll mail you personally with a patch that can be applied.

If you need a 2nd tester, I also reproduce the problem (SVN 887886):

#0  0xb7fb3424 in __kernel_vsyscall ()
#1  0x4314dfa5 in raise () from /lib/libc.so.6
#2  0x4314f7b1 in abort () from /lib/libc.so.6
#3  0xb7dda59f in qt_message_output () from /usr/lib/qt4/libQtCore.so.4
#4  0xb7dda680 in qFatal () from /usr/lib/qt4/libQtCore.so.4
#5  0xb7dda707 in qt_assert () from /usr/lib/qt4/libQtCore.so.4
#6  0xb062cf8b in QList<QString>::first (this=0xada58018) at /usr/include/qt4/QtCore/qlist.h:252
#7  0xb0644de9 in SqlCollectionLocation::insertStatistics (this=0x9e7ce368, trackMap=@0xada58250)
    at /var/tmp/portage/media-sound/amarok-1.99/work/amarok-1.99/src/collection/sqlcollection/SqlCollectionLocation.cpp:334
#8  0xb78ef5cf in FastForwardWorker::run (this=0xafe6180)
    at /var/tmp/portage/media-sound/amarok-1.99/work/amarok-1.99/src/databaseimporter/amarok14/FastForwardWorker.cpp:162
#9  0xb678b2bd in ThreadWeaver::JobRunHelper::runTheJob () from /usr/kde/4.1/lib/libthreadweaver.so.4

For your interest, I have the same problem, self compiled from tarball of RC 1. Distribution is openSuSe 11.0 Current Beta, no self compiled packages except for Amarok. gdb trace attached. If you need further testers, pls consider contacting me.

Created attachment 28832 [details]
another trace

This crash has been fixed in SVN. Note, however, that I'm fixing the symptom and not the problem. I can justify this by saying that a crash is the worst possible outcome, and silently failing is better.

I suspect that this crash is caused by files with accented characters either in the filename or metadata.

If anybody can confirm this or provide more information, I would be happy to look into it further. I can't do this currently since I cannot reproduce this problem. Please open a new bug report if you can find a better more accurate trend.

Do you think you could reproduce the problem with my Amarok 1.4 database ? But the problem may be link to media or cover pictures on my disk...

No, since any database url references which are non physically on my disk will be simply skipped over.

I've tested the last SVN version and as expected, there is no more crash during import.

SVN commit 889579 by markey:

Use mysql_real_escape_string() for escaping, instead of our own
concoction of an escaping routine. This might fix escaping errors that
could affect the following bugs:

CCBUG: 176154
CCBUG: 174784

Please test.

 M  +10 -1     MySqlEmbeddedCollection.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=889579

The new code works (no crash) but I can't say if the result is better

@Frédéric: 

1) Have you tried with the latest SVN code after my commit 889579?

2) What do you mean with "I can't say"? Can you not tell if there is a difference, or is there none?

1) SVN 889595

2) I can't confirm there is a difference. With your code, 6626 tracks are imported but I don't remember how many tracks were imported with the previous code. If you have replaced the workaround of Seb Ruiz by a correct implementation, we could suppose that the problem is fixed as I have no more crash during import.

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

SVN commit 889579 did not change behaviour: Import of original Collection crashed exactely at the same last track. I tested against another collection that makes heavy use of an album with special chars: Sigur Rós - Ágætis Byrjun. No song at all got imported. Pls contact me if I can further support. 

SVN current (889690) did not change behaviour: Import of original Collection crashed exactely at the same last track. I tested against another collection that makes heavy use of an album with special chars: Sigur Rós - Ágætis Byrjun. No song at all got imported. Pls contact me if I can further support. 

Please try again with latest SVN trunk. We have a new patch in for an encoding problem:

SVN commit 890023 by woebbe:

escape():
- fix encoding (don't use implicit const char* -> QString cast)
- build with -pedantic

 M  +4 -3      MySqlEmbeddedCollection.cpp

Created attachment 28876 [details]
New Debug Trace

890023 did not change behaviour, but still the "fix" that makes the import exit silently exists, so that no backtrace can be provided. Nevertheless I attached a recent gdb output.

Why has this bug been marked as fixed and closed? There is obviously no fix by Seb Ruiz according to his comment - only a workaround to avoid crashing of the whole application due to misbehaviour of the import. I guess that with a fixed marked bug no activity takes place anymore?
Please reopen this bug!

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

Yes, I suppose the bug that caused the crash is still valid. I'm having a very hard time tracking down the problem as I cannot reproduce.

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

(In reply to comment #38)
> Yes, I suppose the bug that caused the crash is still valid. I'm having a very
> hard time tracking down the problem as I cannot reproduce.
> 

Hi Seb,
I can reproduce this with 100% reliability. I'm happy to test/try anything you want to try to track it down. The fact that it seems to occur at about the same point in the import (on the basis that I think I've got the same number of imported tracks) suggests there's something about a particular track that's causing the problem (I get that feeling from other comments). If there's a way to trace what track's being imported at the time of the crash I might be able to isolate it - maybe send a copy of the track to help you reproduce?

What about adding some debug output that displays the track that is going to be imported?

If you run amarok with the --debug argument you should be able to see a load of debug. I'll add some more this evening.

Created attachment 29025 [details]
Output of amarok --debug

Ran with --debug as suggested. Output attached. I've uploaded the Ogg it seems to be failing on to http://www.web-brewer.co.uk/008DaltonReed-GivingOnIntoLove.ogg

Thanks Tony. Looks like I might be able to make some headway with your output.

Looking more closely at the output, I think the Ogg I uploaded isn't the beast causing the problem after all.

amarok:      [ERROR!] GREPME MySQLe query failed! Duplicate entry 'file:////oggs/Johann%20Sebastian%20Bach%20-%20the%206%20Brandenb' for key 'uniqueid'  on  "INSERT INTO urls_temp(directory,deviceid,rpath,uniqueid) VALUES ( 0, -1, './oggs/Johann Sebastian Bach - the 6 Brandenburg Concertos - Yehudi Menuhin and the Bath Festival Orchestra/013 No 4: Presto.ogg', 'file:////oggs/Johann%20Sebastian%20Bach%20-%20the%206%20Brandenburg%20Concertos%20-%20Yehudi%20Menuhin%20and%20the%20Bath%20Festival%20Orchestra/013%20No%204:%20Presto.ogg' );" 

seems significant. Though I don't know if that's the original problem or an artefact of the fact that I've re-run the import (does it wipe everything each time?) But it could be that the database field that needs to be unique is too small to hold the whole string, so because there's more than one track matching the substring, it's clashing.

The actual file doens't help me at all. The debug (including that sql error), does.

For me it seems that I get different warnings, then the one above for thaose songs, that are not added. Revision: 893108

amarok:      [WARNING!] SQL Query returned no results: "SELECT id FROM urls WHERE deviceid = -1 AND rpath = './media/Bueffel/Musik/xyz.mp3';"

I'm not sure how amarok works, but the file is in /media... and depending where it starts, ./media might fail.

How do I get all of amarok's output into a file? amarok --debug > somefile.txt does not work.

for the albumart I get some of these:
"/home/rabauke/.kde/share/apps/amarok/albumcovers/large/11e105a9183afd1b37144e1e0857fe00"
QObject::connect: Cannot queue arguments of type 'KIO::filesize_t'
(Make sure 'KIO::filesize_t' is registered using qRegisterMetaType().)
QObject::connect: Cannot queue arguments of type 'KIO::filesize_t'
(Make sure 'KIO::filesize_t' is registered using qRegisterMetaType().)
amarok:    image copy: "11eab94b16bd30003d0641eca3ee5f9f"  :  "/home/rabauke/.kde/share/apps/amarok/albumcovers/large/11eab94b16bd30003d0641eca3ee

A new version (2.0, build date Dec 5) showed up on my Kubuntu updater this morning and it successfully imported my entire collection.So I reckon that's fixed it, thanks Seb (and others?)

Does not work here.

For me (on Debian unstable/experimental) it doesn't work either.

On Mandriva 2009.0, it's working but the score isn't imported.

Hi,

I just got amarok 2 installed and I run into the same problems: less than 1 percent of my collection is imported...

I basically get also those duplicate key errors. Before those another one:

amarok:        [ERROR!] GREPME MySQLe query failed! Specified key was too long; max key length is 1000 bytes  on  "CREATE UNIQUE
INDEX urls_id_rpath_temp ON urls_temp(deviceid, rpath);"


Is there separate script available as a workaround?

Best regards
Martin

SVN commit 897993 by seb:

Do some slight sanity checking when updating metdata of imported tracks.
eg:
 - don't set empty fields (rating, score, playcount)
 - don't set older lastPlayed or newer firstPlayed dates
This is useful since there may be multiple database entries which map to
single urls in the 1.4 database due to HDD changes and dynamic
collections. This tries to take the best of each statistic row as the
best heuristic.
BUG: 176237
CCBUG: 174784

 M  +20 -5     SqlMeta.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=897993

I just tried Amarok-nightly (20081218+svn898671-0neon1) and my entire collection was imported without any errors!

However, none of my cover art was imported..

Also, the information of whether a song belongs to a various artists album or not is lost.

(In reply to comment #54)
> SVN commit 897993 by seb:
> 
> Do some slight sanity checking when updating metdata of imported tracks.
> eg:

Still does not work for me, stops at exact the same position. If I provided you with my old Amarok Collection, would that help?

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

I checked with latest SVN (902502) and now it even crashes (and doesn't import anything)

Another strange thing is that it shows something like: amarok:    11459  no track produced for URL  "/mnt/zeug./zeug1/ ... 

The latter part of the shown URL is correct, but not the beginning: /mnt/zeug is the actual mount point of the disk containing files, and /mnt/zeug1 exists as well, because of backward compatibility issues. But the strange thing is the inserted dot, because there is no such directory as zeug. - maybe it comes from concatenating the mount point with something like ./ ...?

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

bug 174269 seems to be the same problem. Any news on this?

(In reply to comment #61)
> bug 174269 seems to be the same problem. Any news on this?

No - I simply did not try it anymore. And nowadays - I do not have any 1.4 Collection at hand anymore.

(In reply to comment #62)
> (In reply to comment #61)
> > bug 174269 seems to be the same problem. Any news on this?
> 
> No - I simply did not try it anymore. And nowadays - I do not have any 1.4
> Collection at hand anymore.

amarok2 is still unable to import correctly a collection from amarok1.4 ... 

i can provide you my collection if you want cause i'm still using amarok1.4

Changed priority. From the comments I get that the crash doesn't happen anymore, but the import ist still more than flaky.

Current git trunk (very similar to 2.2-beta1) imports my Amarok 1.4 collection correctly.

(while the previous versions of Amarok 2 had problems with my 1.4 collection)

So, from my PoV this WORKSFORME.

Please, everyone of those running current 2.2-git or 2.1.80 with an old 1.4 database at hand, could you try now if this bug is indeed fixed?

Would be nice if we could close this one.

It is fixed in 2.2-GIT, apart from one little oops with importing scores. We have a patch for that, it's in BUG 174444

So I'm closing this report, and we'll keep the other one open until the patch is applied.