Bug 204251

Created attachment 36249 [details]
Command line output with --debug --nofork

Created attachment 36250 [details]
backtrace

Pasting backtrace inline:

Program received signal SIGSEGV, Segmentation fault.                                                               
[Switching to Thread 0x7f42ce331760 (LWP 10172)]                                                                   
0x00007f42b0f3b0dd in QHash<unsigned int, LIBMTP_track_struct*>::findNode (this=0x279c268,                         
    akey=@0x6c006900000001, ahp=0x7fffd637559c) at /usr/include/qt4/QtCore/qhash.h:855                             
855         uint h = qHash(akey);                                                                                  
(gdb) bt                                                                                                           
#0  0x00007f42b0f3b0dd in QHash<unsigned int, LIBMTP_track_struct*>::findNode (this=0x279c268,                     
    akey=@0x6c006900000001, ahp=0x7fffd637559c) at /usr/include/qt4/QtCore/qhash.h:855                             
#1  0x00007f42b0f3c466 in QHash<unsigned int, LIBMTP_track_struct*>::operator[] (this=0x279c268,                   
    akey=@0x6c006900000001) at /usr/include/qt4/QtCore/qhash.h:720
#2  0x00007f42b0f34f9f in Meta::MtpHandler::setAssociateTrack (this=0x279c0e0, track={d = 0x7fffd63755e0})
    at /home/cerneelb/Code/amarok/src/collection/mtpcollection/handler/MtpHandler.cpp:997
#3  0x00007f42b0f3e18a in Handler::MtpReadCapability::setAssociateTrack (this=0x25a7190, track=
      {d = 0x7fffd6375770})
    at /home/cerneelb/Code/amarok/src/collection/mtpcollection/handler/capabilities/MtpReadCapability.cpp:55
#4  0x00007f42cd5b0ecc in Meta::MediaDeviceHandler::parseTracks (this=0x279c0e0)
    at /home/cerneelb/Code/amarok/src/collection/mediadevicecollection/handler/MediaDeviceHandler.cpp:831
#5  0x00007f42cd5a334d in MediaDeviceCollection::startFullScanDevice (this=0x2790320)
    at /home/cerneelb/Code/amarok/src/collection/mediadevicecollection/MediaDeviceCollection.cpp:176
#6  0x00007f42cd5a33b7 in MediaDeviceCollection::slotAttemptConnectionDone (this=0x2790320, success=true)
    at /home/cerneelb/Code/amarok/src/collection/mediadevicecollection/MediaDeviceCollection.cpp:219
#7  0x00007f42b0f3846d in Meta::MtpHandler::slotDeviceMatchSucceeded (this=0x279c0e0, job=0x27cced0)
    at /home/cerneelb/Code/amarok/src/collection/mtpcollection/handler/MtpHandler.cpp:1391
#8  0x00007f42b0f328eb in Meta::MtpHandler::qt_metacall (this=0x279c0e0, _c=QMetaObject::InvokeMetaMethod, _id=0,
    _a=0x7fffd63759f0) at /home/cerneelb/Code/amarok/build/src/collection/mtpcollection/moc_MtpHandler.cpp:69
#9  0x00007f42cbffcea2 in QMetaObject::activate (sender=0x27cced0, from_signal_index=<value optimized out>,
    to_signal_index=5, argv=0x343f1e0) at kernel/qobject.cpp:3113
#10 0x00007f42c84add02 in ThreadWeaver::Job::done (this=0x279c268, _t1=0x27cced0)
    at /build/buildd/kde4libs-4.3.0/obj-x86_64-linux-gnu/threadweaver/Weaver/Job.moc:91
#11 0x00007f42c84adea8 in ThreadWeaver::Job::qt_metacall (this=0x27cced0, _c=QMetaObject::InvokeMetaMethod,
    _id=1, _a=0x2dcb3c0) at /build/buildd/kde4libs-4.3.0/obj-x86_64-linux-gnu/threadweaver/Weaver/Job.moc:71
#12 0x00007f42b0f3280d in Meta::WorkerThread::qt_metacall (this=0x27cced0, _c=QMetaObject::InvokeMetaMethod,
    _id=5, _a=0x2dcb3c0) at /home/cerneelb/Code/amarok/build/src/collection/mtpcollection/moc_MtpHandler.cpp:117
#13 0x00007f42cbff75d8 in QObject::event (this=0x27cced0, e=0x2dcb740) at kernel/qobject.cpp:1111
#14 0x00007f42cc8f1f4d in QApplicationPrivate::notify_helper (this=0x2441cf0, receiver=0x27cced0, e=0x2dcb740)
    at kernel/qapplication.cpp:4056
#15 0x00007f42cc8fa18a in QApplication::notify (this=0x7fffd63763c0, receiver=0x27cced0, e=0x2dcb740)
    at kernel/qapplication.cpp:4021
#16 0x00007f42cdd6271b in KApplication::notify (this=0x7fffd63763c0, receiver=0x27cced0, event=0x2dcb740)
    at /build/buildd/kde4libs-4.3.0/kdeui/kernel/kapplication.cpp:302
#17 0x00007f42cbfe76ac in QCoreApplication::notifyInternal (this=0x7fffd63763c0, receiver=0x27cced0,
    event=0x2dcb740) at kernel/qcoreapplication.cpp:610
#18 0x00007f42cbfe831a in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x233f930)
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:213

This crash doesn't happen in Amarok, so I'm not sure what we can really do about it.

I assume bad data is being put into the QHash, causing the crash. Had a similar problem recently.
Alejandro will likely know what goes wrong. I've tried to fix it but broke functionality completely.

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

This is happening with my creative zen vision m as well.

This is still happening in beta 2.

This seems to be fixed in RC 1

Great. Thanks for following up.

Well, apparently it is not fixed :(

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

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

I can confirm it's fixed for the Nokia XpressMusic 5800. Perhaps the Zen Vision
just does something different?

Or this could be a race condition and then it might appear again at any time.
Need to get feedback from Alejandro on this.

Changed title.

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

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

Changing target. Alejandro, any input?

Changing title since the Nokia works.

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

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

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

commit 01fceca4a612c106380962171b0d7bd1a6ead0e9
Author: Mark Kretschmann <kretschmann@kde.org>
Date:   Sat Nov 21 09:05:44 2009 +0100

    Try to fix some MTP related crashes: Added safety checks.

    CCBUG: 204251

bug # 215387 is still perfectly reproducable with the following backtrace:

Thread 1 (Thread 0x7ffe411e8770 (LWP 30533)):
[KCrash Handler]
#5  0x00007ffe27b94353 in Meta::MtpHandler::libGetType (this=0x221c4f0, track=...) at /home/mikko/amarok/src/collection/mtpcollection/handler/MtpHandler.cpp:1082
#6  0x00007ffe27b953c8 in Meta::MtpHandler::prepareToPlay (this=0x221c4f0, track=...) at /home/mikko/amarok/src/collection/mtpcollection/handler/MtpHandler.cpp:1296
#7  0x00007ffe40174449 in Meta::MediaDeviceTrack::prepareToPlay (this=0x4a1ba30) at /home/mikko/amarok/src/collection/mediadevicecollection/MediaDeviceMeta.cpp:353
#8  0x00007ffe403a17cd in EngineController::setNextTrack (this=0x1e3eb30, track=...) at /home/mikko/amarok/src/EngineController.cpp:652
#9  0x00007ffe400468f9 in Playlist::Actions::play (this=0x226cf40, trackid=668801282180004845, now=false) at /home/mikko/amarok/src/playlist/PlaylistActions.cpp:216
#10 0x00007ffe400463bb in Playlist::Actions::requestNextTrack (this=0x226cf40) at /home/mikko/amarok/src/playlist/PlaylistActions.cpp:136
#11 0x00007ffe403a330d in EngineController::slotAboutToFinish (this=0x1e3eb30) at /home/mikko/amarok/src/EngineController.cpp:880
#12 0x00007ffe403a5cf7 in EngineController::qt_metacall (this=0x1e3eb30, _c=QMetaObject::InvokeMetaMethod, _id=23, _a=0x7fffc8c3d5c0) at /home/mikko/amarok/build/src/EngineController.moc:149
#13 0x00007ffe3f65b425 in QMetaObject::activate (sender=0x1e3f3e0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x1) at kernel/qobject.cpp:3274
#14 0x00007ffe3ab9d6e0 in Phonon::MediaObjectPrivate::_k_aboutToFinish() () from /usr/lib64/libphonon.so.4
#15 0x00007ffe3ab9e19e in Phonon::MediaObject::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/libphonon.so.4
#16 0x00007ffe3f65b425 in QMetaObject::activate (sender=0x1e390e0, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x1) at kernel/qobject.cpp:3274
#17 0x00007ffe2fd7b7ed in Phonon::Xine::MediaObject::needNextUrl() () from /usr/lib64/kde4/plugins/phonon_backend/phonon_xine.so
#18 0x00007ffe2fd7e572 in Phonon::Xine::MediaObject::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/kde4/plugins/phonon_backend/phonon_xine.so
#19 0x00007ffe3f6578d1 in QObject::event (this=0x1e390e0, e=0x508b200) at kernel/qobject.cpp:1240
#20 0x00007ffe3ea5b69c in QApplicationPrivate::notify_helper (this=0x1cd4550, receiver=0x1e390e0, e=0x508b200) at kernel/qapplication.cpp:4242
#21 0x00007ffe3ea63e4a in QApplication::notify (this=0x7fffc8c3e3d0, receiver=<value optimized out>, e=0x508b200) at kernel/qapplication.cpp:4125
#22 0x00007ffe40bb8d50 in KApplication::notify (this=0x7fffc8c3e3d0, receiver=0x1e390e0, event=0x508b200) at /var/tmp/paludis/kde-base-kdelibs-9999/work/kdelibs-9999/kdeui/kernel/kapplication.cpp:302
#23 0x00007ffe3f64664b in QCoreApplication::notifyInternal (this=0x7fffc8c3e3d0, receiver=0x1e390e0, event=0x508b200) at kernel/qcoreapplication.cpp:704
#24 0x00007ffe3f647493 in QCoreApplication::sendEvent (receiver=0x0, event_type=<value optimized out>, data=0x1ba4c70) at kernel/qcoreapplication.h:215
#25 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=<value optimized out>, data=0x1ba4c70) at kernel/qcoreapplication.cpp:1345
#26 0x00007ffe3eb03054 in QCoreApplication::sendPostedEvents (this=<value optimized out>, flags=<value optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
#27 QEventDispatcherX11::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qeventdispatcher_x11.cpp:75
#28 0x00007ffe3f644e52 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149
#29 0x00007ffe3f64521d in QEventLoop::exec (this=0x7fffc8c3e370, flags=) at kernel/qeventloop.cpp:201
#30 0x00007ffe3f64775b in QCoreApplication::exec () at kernel/qcoreapplication.cpp:981
#31 0x000000000040aab4 in main (argc=2, argv=0x7fffc8c40238) at /home/mikko/amarok/src/main.cpp:229

See my comment #8 in bug 210477

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

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

This might potentially have been fixed by this commit (in Git master), please
test, and reopen the report if the problem persists. Thanks.


commit acf150893523a4c1693abb2ccae32f91140cb01d
Author: Mark Kretschmann <kretschmann@kde.org>
Date:   Mon Dec 21 08:53:42 2009 +0100

    Fix many MTP crashes caused by dangling pointers.

    The main cause for many crashes in MtpHandler were dangling pointers to
    structures from LibMTP. Using the new QSharedPointer (from Qt 4.5) makes it
    easy to fix such issues elegantly and safely. Please consider using it in
    other places too. It's often worth the tiny overhead.

    Note: I'm not sure how many bug reports this affects. Probably several.

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

For me it's not fixed in 2.2.1.90

Reopening then.

2.2.1.90 is irrelevant here, as I had only recently made this commit that could potentially fix it. However, due to problems with my distro, I can't properly test it (device not found).

At any rate, the commit was after the Beta tagging, so we need testers using Git master.

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

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

I can confirm that this bug disappears using a Samsung YP-Q2 when building the debian package in unstable (2.2.2~beta1-1) adding the above mentioned commit as a patch (acf150893523a4c1693abb2ccae32f91140cb01d).

I've checked not git master, but I think it will behave in a same way.

Hope that helps

what is however not fixed is, that amarok crashes when I want to copy something from the mtp device to my laptop, then amarok continues to crash, copying from laptop to the player is however no problem at all.

(In reply to comment #36)
> what is however not fixed is, that amarok crashes when I want to copy something
> from the mtp device to my laptop, then amarok continues to crash, copying from
> laptop to the player is however no problem at all.

Yes, but that is a different bug, already reported: bug 219678

I think Bug 219458 is not a duplicate of this.

I think https://bugs.kde.org/show_bug.cgi?id=218506 is no duplicate too.

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

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

Created attachment 39915 [details]
New crash information added by DrKonqi

Amarok doesn't start. It crash in every try to turn it on. Creative Zen V Plus is connected. Error that is shown in recent notification is: lcd error, cannot connect to amarok.

reopening this since the fix that markey commited was reverted later.

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

Adapting title

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

Created attachment 40005 [details]
Log from KDE crash handler

When copying files to Creative Zen vision:m crash occured.
Pasted output from KDE crash handler.

For me, I temporarily solved the problem by downgrading libmtp version to 0.3.0. Transfer seems to work mostly after that. The details of my situation are in bug  223046, which was marked as dublicate of this one.

By the way, I started to suspect libmtp after I enabled mtp plugin in rhythmbox and it also crashed, and would crash every time I tried to start it while my player was connected to the computer :)

I also think that there are bugs in the new libmtp.

I also tried mtpfs and there are freezes with my Creative Zen Touch.

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

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

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

I can second Donatas' belief that the problem really lies with libmtp - I downgraded my libmtp (libmtp8) back to 0.3.4 and now both Amarok and Nomad work again.
Mind you, it would help if Amarok threw up a message of some sort rather than just crashing when I plug in my Zen ;-)
(openSUSE 11.1, Amarok 2.2.2)

Another confirmation that libmtp8 is the culprit...

Downgrading libmtp8 from 1.0.1-0ubuntu1~karmic1 to 0.3.7-3ubuntu2 solved my issues with amarok 2.2.2 crashing when plugging in my Creative Zen Vplus.

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

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

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

I wasn't using an MTP device!

On Mon, Feb 8, 2010 at 3:42 PM, Mikko C. <mikko.cal@gmail.com> wrote:

> https://bugs.kde.org/show_bug.cgi?id=204251
>
>
> Mikko C. <mikko.cal@gmail.com> changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                 CC|                            |maisieandme7@gmail.com
>
>
>
>
> --- Comment #58 from Mikko C. <mikko cal gmail com>  2010-02-08 21:42:24
> ---
> *** Bug 225909 has been marked as a duplicate of this bug. ***
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

Sam, have a look at these lines of your backtrace:

[KCrash Handler]
#5  Mtp::MtpHandler::getFormat (this=0x4db8d20, mtptrack=0x90) at
/usr/src/debug/amarok-2.1.1/src/collection/mtpcollection/handler/MtpHandler.cpp:1100

And please, upgrade to 2.2.2, Amarok 2.1.1 is unmaintained.

The only thing I can think of was a nokia phone which shows up solely as a
usb mass storage. Sorry to get excitable. I did notice that.

On Mon, Feb 8, 2010 at 5:28 PM, Myriam Schweingruber <myriam@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=204251
>
>
>
>
>
> --- Comment #60 from Myriam Schweingruber <myriam kde org>  2010-02-08
> 23:26:55 ---
> Sam, have a look at these lines of your backtrace:
>
> [KCrash Handler]
> #5  Mtp::MtpHandler::getFormat (this=0x4db8d20, mtptrack=0x90) at
>
> /usr/src/debug/amarok-2.1.1/src/collection/mtpcollection/handler/MtpHandler.cpp:1100
>
> And please, upgrade to 2.2.2, Amarok 2.1.1 is unmaintained.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>

Oh, It is 2.2.2, btw. I don't know why it would say otherwise. This crashing didn't happen until I started using 2.2.2

I followed your instructions regarding bug #225909 (a dupe of this one), Mikko, and that fixed my problem.
Thank you!

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

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

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

Removing release_blocker keyword.

I had discussed this with Bart the other day, and we both came to the conclusion that there isn't really any way to fix the dangling pointer problem with the hash system used in MtpHandler. Only way would be redesigning the whole class.

And there is no way that this could happen before 2.3.0 release, sorry.

Pushing target

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

Created attachment 42891 [details]
New crash information added by DrKonqi

I was transferring mp3 files to my creative zen vision m

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

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

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

From looking at the backtrace, I am not sure if Bug 246654 is really a duplicate, but it certainly is a crash when using a media player.

Bruno, as you can see in the title, this is the master bug for crashes with the MTPHandler.

Nadine, yes and I know that bugzilla can not properly define parent/child dependencies, still, I wanted to make sure no one mistook Bug 246654 for a duplicate, but rather as additional/different information.

PS: SCNR, but my name is Richard :)

Bumping version.

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

is it possible to get a high-level status of this bug?
it seems to have existed for around two years, in some form or another, with no solution in sight.  it affects virtually all MTP devices.

if more crash info is required, i can post.  i have an affected device. (cowon S9)

Someone is working on an MTP kio slave, which I presume amarok will make use of when it is done.  Hopefully it will not have this problem.

As an additional data point, the Galaxy Nexus does not support USB mass storage any more, it's MTP all the way.

This will increase pressure and, hopefully, interest.

I think the reason that the MTP kio slave is being developed is because the developer uses android and wants to be able to access the files seamlessly through dolphin.  But it will also provide a shared interface that both digikam and amarok (as well as other media and picture apps) can use, instead of each having their own implementation.

Indeed. I do have a Galaxy Nexus and am working on a KIO-Slave. Due to the nature of LIBMTP that includes writing a daemon that detects MTP devices using udev, caches them and handles all operations and exposes them through DBus. That should be enough to remove the problems, as they are definitely related to that. Whether Amarok then uses that DBus Interface or the KIO-Slave (The first method would result in less overhead and I intend to add a track management API in addition to the file management) remains to be seen.

(In reply to comment #83)
> Indeed. I do have a Galaxy Nexus and am working on a KIO-Slave. Due to the
> nature of LIBMTP that includes writing a daemon that detects MTP devices
> using udev, caches them and handles all operations and exposes them through
> DBus. That should be enough to remove the problems, as they are definitely
> related to that. Whether Amarok then uses that DBus Interface or the
> KIO-Slave (The first method would result in less overhead and I intend to
> add a track management API in addition to the file management) remains to be
> seen.

You got a target date to get that in a working order? i.e. could we ship the next version of amarok with a new MTP plugin based on your work?

Even though I have more time to work on this right now since I just started my Master Thesis (Yes, I know how wrong that sounds, but before I had some other University stuff that took even more time :D) I cannot give a specific release date. Soon would be preferable, but my guess would be at least a month. I would like some extended testing before implementing it in other applications.

My recommendation would be that work starts on a new MTP-Implementation in Amarok once I have released a first version. I would keep it optional though and keep and possibly even fix the old version so a fallback is there if the daemon is not running (For whatever reason). That determination could easily be done at runtime.

I would also like to help with that implementation, but of course my focus would be on the KIO-Slave. So maybe we can have it for the version after next.

I promise to post on the amarok-ml once the daemon is ready for initial testing, so we can talk about the future plans then and there.

I cant reproduce this in v2.6.0-421-gf66a306

Do we already use the new KIO slave?

Philip: AFAIK the new KIO slave is shipping now, right?

Sadly: No and no. I started a rewrite of the slave that will hopefully fix most bugs but didn't get much done over the holidays. Now I'm fresh at my new job and as I am still sorting things out I don't get much time either. Once the slave is done I want to turn my attention over to the amarok part, if that is still needed then.

Thank you for the feedback, keeping this open until further notice, then.

Philip: any news on this?

Well, the Slave is working for devices with a tolerance to non-MS behaviour, which basically means all Nexus-Models, but not so much Samsung devices (Those are the ones I was able to test with).

The Problem is that if a second connection is opened to the device (which for example happens when you open the device from the notifier plasmoid) the devices react differently. With the Nexus devices LIBMTP can just reset them and everything is fine, Samsung devices are not capable of that. They just hang and ne to be unplugged and plugged in again and accessed directly.

The main problem here is the design of KIO which is inherently multi-connection. Even if I specify that only one connection is allowed, this still happens. Which reminds me that I need to open a bug against KIO for that. So while the Slave in itself is stable aenough and also fast (I use it daily with my Nexus devices without problems) there are sill problems that will hit a LOT of users since Samsung is the major Android player out there.

We could however do some brainstorming as to what would need to be implemented in the slave for Amarok, e.g. getting tracks etc. as right now it only enables file browsing, but as I am currently in the process of moving out of my parents house the actual coding would have to wait. I will however attend Akademy (Yay :D) so we should definitely meet then. I will try to raise the topic in IRC when I have the time.

(In reply to comment #92)
>...
> We could however do some brainstorming as to what would need to be
> implemented in the slave for Amarok, e.g. getting tracks etc. as right now
> it only enables file browsing, but as I am currently in the process of
> moving out of my parents house the actual coding would have to wait. I will
> however attend Akademy (Yay :D) so we should definitely meet then. I will
> try to raise the topic in IRC when I have the time.

Cool, thank you :)

MTP works good for me (I tested Sansa Clip+ with amarok v2.8.0) but when I am trying to open player's folders by Dolphin and Amarok is running nothing is happens. When Amarok is stopped it's works.

Yes, this is WIP, should be fixed for 2.9

Is anyone able to reproduce this with modern KF5 versions of the software? It looks like most of the crash reports are several years old.

(In reply to Nate Graham from comment #96)
> Is anyone able to reproduce this with modern KF5 versions of the software?
> It looks like most of the crash reports are several years old.

you are asking a bit much here, the kf5 port is still pre-alpha :-) This report is clearly for the kde4 based version, we will check on old bugs once we have a first beta release of the kf5 port.

Thank you for the crash report.

As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved.

I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.

Closing this as unmaintained, as it refers to both an old Amarok version and a very old mtp stack upstream.