After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 680930 - Lfm scrobbling not working at all
Lfm scrobbling not working at all
Status: RESOLVED DUPLICATE of bug 667499
Product: banshee
Classification: Other
Component: Last.fm
2.4.1
Other Linux
: Normal normal
: ---
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-07-31 17:59 UTC by Alex
Modified: 2012-11-28 11:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
banshee debug log (84.28 KB, text/plain)
2012-07-31 22:49 UTC, Alex
Details

Description Alex 2012-07-31 17:59:44 UTC
Last.fm scrobbling seems to be completely broken (at least for me). I've tried logging out & re-authenticating with last.fm but nothing. Rhythmbox scrobbles fine. There are no error messages and I can click on the last.fm entry in the sidebar and view my profile as normal. The 'enable song reporting' checkbox is enabled. 

I can't seem to get any more debug info out of banshee. Starting banshee with --debug --debug-sql or --debug-addins doesn't seem to print anything about last.fm scrobbling.
Comment 1 Phil Trimble 2012-07-31 22:25:06 UTC
Hi Alex, there have been some recent troubles that might be similar to the ones that you are facing. But first let's try to figure out what is up with the logs so we can confirm or deny.

If you are launching correctly with debug enabled then there should be messages printed out that say exactly what we are trying to do with our interaction with Last.fm. Here are some messages I see when scrobbling with debug enabled (this is also with 2.4.1, on Ubuntu 12.04):

>> [22 Debug 17:19:28.596] Audioscrobbler sign-on succeeded - Session ID received
>> [22 Debug 17:19:29.017] Submitted NowPlaying track to Audioscrobbler
>> ...(unrelated logging messages)
>> [1 Debug 17:21:16.136] Track John Frusciante - 909 Day (on Letur-Lefr EP) 
>> <00:02:24.0130000> [file:///media/sdb1/music/John%20Frusciante/Letur-
>> Lefr%20EP/John%20Frusciante%20-%2002%20-%20909%20Day.mp3] had playtime of
>> 120460 >>msec (120sec), duration 144013 msec, queued: False
>> [1 Debug 17:21:16.138] Player state change: Loaded -> Playing
>> [1 Debug 17:21:17.144] TrackInfoDisplay RenderAnimation: 31.00 FPS
>> [22 Debug 17:21:20.141] Last.fm scrobbler sending '&a[0]=John+Frusciante&t[0]=909+Day&i[0]=1343773155&o[0]=P&r[0]=&l[0]=144&b[0]=Letur-Lefr+EP&n[0]=2&m[0]=' to http://post2.audioscrobbler.com:80/protocol_1.2

Do you not see anything similar to this? Do you see any other unrelated debug messages? Just in case, here are some instructions for obtaining the debug logs we will need to help you solve this: https://live.gnome.org/Banshee/CommonQuestions/Logs

Once we have more log info we can plan our next steps.
Comment 2 Alex 2012-07-31 22:49:16 UTC
Created attachment 220032 [details]
banshee debug log
Comment 3 Alex 2012-07-31 22:50:38 UTC
I've attached the log - interesting. I've no idea what it's trying to send, this log comes with only trying to play 1 track (it seems to be trying to send about 50 tracks to the api?

I've tried clearing out ~/.config/banshee-1/ with no joy.
Comment 4 Phil Trimble 2012-07-31 23:01:53 UTC
Okay, I see the problem. Buried in there is an error we received back from last.FM. It says that one of those tracks has an invalid time stamp. We submit all tracks in a batch and last.FM reports back an overall error for the whole batch. Since one track is bad it rejects all of them and then tries over and over.

So one track was bad and it causes a pile-up. Good news is that we have already addressed this issue on another bug (which I will reference in this ticket once I get home, I am on my phone now). The bad news for you is that the fix is only in our development branch right now. It should be released officially sometime soon.

It is possible to address this by removing the offending track from an XML file that stores the tracks to submit. I will respond again with instructions on how you can get things working (again, once I get home in a few hours).
Comment 5 Alex 2012-07-31 23:26:38 UTC
Found the file! ~/.cache/banshee-1/extensions/lastfm

Removed audioscrobbler-queue.xml and all is right in the world again!

Thanks for your guidance.
Comment 6 Phil Trimble 2012-08-01 01:13:58 UTC
Good deal! Glad that things are working again. If it happens in the future you could also try to find the entry in that file that has a negative StartTime. This is generally the first track. In your case:

>>&a[0]=Frank+Turner&t[0]=The+Real+Damage&i[0]=-62135596584

If you remove just that bad XML entry (while Banshee is closed) then we will attempt to submit the rest of your tracks. If there are other bad tracks then things will pile up again but in my experience it's usually just the one that hiccuped for some unknown reason. I'm still unsure of the root cause but some recent patches that have been submitted will automatically clean out the Last.fm submission queue in situations like yours, saving you the trouble of messing around with that XML file at all.

Maintainers, this is a dupe of https://bugzilla.gnome.org/show_bug.cgi?id=667499 and can be marked as such. 

Thanks for taking the time to file a bug report, Alex.
Comment 7 Phil Trimble 2012-11-28 11:34:53 UTC
Maintainers, friendly bump, this is a dupe and should be closed. See above.
Comment 8 Andrés G. Aragoneses (IRC: knocte) 2012-11-28 11:41:00 UTC
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

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