Bug 116046

Is it still valid with tunepimp 0.4.X? 

I've been trying to test this for you but I haven't been able to get MusicBrainz support working at all in my svn build. If you could have I quick look at this post on the amarok forum and help me out I'd greatly appreciate it: http://amarok.kde.org/forum/index.php/topic,12211.0.html

I've been experiencing this for some tracks too. Strange thing is that I _know_ some of them have been found earlier.
I _think_ it's a tunepimp issue, since I see some web traffic, but then nothing happens. Might be a problem in Amarok's "KTRM" code too.

It's similar here.
In my case it doesn't find any matching tag information at all. I tried about 50 songs (some of them definitely worked one or two month ago. The mouse cursor stays the "waiting" one with the clock aside for the rest of the Amarok session (even days if I do not restart it). So the cursor also doesn't change if I hover the barrier between the fields in the header of the playlist. (e.g. between track and length)

Debian SID
KDE 3.5.4
Amarok 1.4.1
Tunepimp 0.4.2

cheers

With Amarok 1.4.4 and tunepimp 0.4.1 it seems to be working fine.  I know there are problems with tunepimp 0.5.  

Additionally, some distros don't compile amarok against tunepimp for various reasons, so even if you have tunepimp installed, it won't work.  Amarok is not linked to it.  Any chance that is the case here?

Use tunepimp 0.5.2 or 0.4.4

This occurs with me as well. I've found that simply canceling out of the tag dialog does nothing. CPU usage is still being sucked up by the fail(ing|ed) lookup. The only way to end this was to restart Amarok. Here is a patch (my first!) to stop the processing when you cancel the dialog:

Index: tagdialog.cpp
===================================================================
--- tagdialog.cpp       (revision 608612)
+++ tagdialog.cpp       (working copy)
@@ -295,6 +295,7 @@
     m_mbTrack = m_bundle.url();
     KTRMLookup* ktrm = new KTRMLookup( m_mbTrack.path(), true );
     connect( ktrm, SIGNAL( sigResult( KTRMResultList, QString ) ), SLOT( queryDone( KTRMResultList, QString ) ) );
+    connect( pushButton_cancel, SIGNAL(clicked()), ktrm, SLOT(deleteLater()));

     pushButton_musicbrainz->setEnabled( false );
     pushButton_musicbrainz->setText( i18n( "Generating audio fingerprint..." ) );

wm161@wm161.net, I've committed your fix. Thanks! :)

Reopening..

Resolving as FIXED now, thanks wm161 for the patch, I used to have that same issue here on Gentoo, and the patch fixes it.

kde 3.5.7, amarok 1.4.6, libtunepimp 0.5.3 -- still happens.  And very much repeatable, too.  How do I debug this?

Debug output from amarokapp:

OK (the track isn't in MB database and amarok says so):

amarok: [void TagDialog::musicbrainzQuery()]
amarok: Status is: 2
amarok: [virtual void KTRMLookup::unrecognized()] .../Reservior Dogs/10 Super
amarok: Status is: 1
amarok: Status is: 4
amarok: BEGIN: virtual void KTRMLookup::puidGenerated()
amarok:   [virtual void KTRMLookup::puidGenerated()] .../Reservior Dogs/10 Sup
amarok:   cb3db725-3fff-71f8-a4f7-3f6ee23c7a61
amarok:   [KDE::ProgressBar::ProgressBar(QWidget*, QLabel*)]
amarok: END__: virtual void KTRMLookup::puidGenerated() - Took 0.011s

NOT OK (MB lookup never completes):

amarok: [void TagDialog::musicbrainzQuery()]
amarok: Status is: 2
amarok: [virtual void KTRMLookup::unrecognized()] .../Reservior Dogs/16 Home O
amarok: Status is: 1
amarok: Status is: 2
amarok: [virtual void KTRMLookup::unrecognized()] .../Reservior Dogs/16 Home O
amarok: Status is: 1
<...loops forever...>