Hi all, I'm currently having a quite odd issue with last.fm submission. The last song on whatever playlist I load into Amarok 2 - be it one with one, two or ten songs - does not get stored on the "Recently Played" list under my profile, despite the song being shown as "Listening Now" on my profile page during its execution. Common sense would tell the problem comes from last.fm (and not Amarok) issue; however, I tried loading a single song with VLC 0.9.8a with last.fm submission activated and it got scrobbled properly after its execution.

I'm using the latest package for Amarok 2.0 available under Fedora 10. For various reasons, I have reinstalled Amarok and reset ~/.kde/shre/apps/amarok and re-imported my collection several times now, the latest of them earlier today, with no influence on the scrobbling problem. I tried to look for the file where Amarok stores last.fm submissions, but I couldn't find the submit.xml file that used to exist with Amarok 1.4 at ~/.kde/shre/apps/amarok or elsewhere... information on where that file should be would be appreciated too.

Any suggestions on how to troubleshoot this will be helpful, as I'm not willing to give up on Amarok 2.0 too easily... Thanks in advance!

Yes, I think this issue has been discussed before, but we forgot about it. Could you please make a bug report?

In the Help menu, click "Report Bug".

It took me a month, but I finally reported it: https://bugs.kde.org/show_bug.cgi?id=183518 (the issue still remains in 2.0.1)

My bug report was identified as a duplicate of bug 167489, which was closed as "FIXED" at 2008-11-14. As the problem never ceased existing (and still occurs on 2.0.2, I have just tested), could some developer please reopen one of the reports?

It's not likely to change until 2.1 is released, and Leo can concentrate on, as he said in the bug report, reworking last.fm support.

Sure, I have no problem with developers putting on queue the resolution of a non-critical issue like this one, or waiting for 2.1 in order to have an opportunity to rewrite the whole thing - but does that mean that an existing bug should be left closed as "fixed"?

Duplode wrote:Sure, I have no problem with developers putting on queue the resolution of a non-critical issue like this one, or waiting for 2.1 in order to have an opportunity to rewrite the whole thing - but does that mean that an existing bug should be left closed as "fixed"?

Please keep in mind that FIXED means "fixed in SVN trunk", which doesn't necessarily imply it's fixed in the stable branch (2.0.x currently) as well.

We backport some of our bugfixes, but for technical reasons (too many changes, risk of regressions) it's sometimes not possible to backport everything.

Mark Kretschmann wrote:Please keep in mind that FIXED means "fixed in SVN trunk", which doesn't necessarily imply it's fixed in the stable branch (2.0.x currently) as well.

Oh well, thanks for educating me it's just I had got the impression the bug was closed as a non-issue, but that is not the case it seems. You can take your time of course...

Mark Kretschmann wrote:

Duplode wrote:Sure, I have no problem with developers putting on queue the resolution of a non-critical issue like this one, or waiting for 2.1 in order to have an opportunity to rewrite the whole thing - but does that mean that an existing bug should be left closed as "fixed"?

Please keep in mind that FIXED means "fixed in SVN trunk", which doesn't necessarily imply it's fixed in the stable branch (2.0.x currently) as well.

We backport some of our bugfixes, but for technical reasons (too many changes, risk of regressions) it's sometimes not possible to backport everything.

I found, that the problem exist in latest SVN version with .flac files (tags are from .cue)
Sorry, but I don't have a time to reporting bugs (or maybe learning how to do it) - so I am writing here.

Michal.