Same on SVN.

Could you check the content of the following file :

~/.cache/banshee-1/extensions/last.fm/audioscrobbler-queue.xml

It contains the info for the tracks for which scrobbling has failed.

If it's not empty, you could try to remove it (backup first !), and see if that helps.

(In reply to comment #2)
> Could you check the content of the following file :
> 
> ~/.cache/banshee-1/extensions/last.fm/audioscrobbler-queue.xml
> 
> It contains the info for the tracks for which scrobbling has failed.
> 
> If it's not empty, you could try to remove it (backup first !), and see if that
> helps.

Looks like that did the trick. Thank you!

I think the problem was that one of the queued tracks had negative start time. How can that happen?

This is it:
    <QueuedTrack>
        <Artist>Modest Mouse</Artist>
        <Album>We Were Dead Before The Ship Even Sank</Album>
        <Title>Dashboard</Title>
        <TrackNumber>2</TrackNumber>
        <Duration>246</Duration>
        <StartTime>-62135596800</StartTime>
        <MusicBrainzId />
        <TrackAuth />
    </QueuedTrack>
-62135596800? Makes no sense at all.

I had the same problem. First element in this file had StartTime with - at beginning. Something went wrong. But what? I'm not a fairy and I won't guess, I'll leave this for the developers ^^ .

Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address.  It's usually quite apparent who is working on a given bug by the comments and/or patches attached.

No patch so far, trying to wrap my head around getting started with the code.

Last.fm seems to require the unix timestamp (i.e. number of seconds since 1.1.1970) for the scrobble event. The sample value above corresponds (roughly, we're talking about local time not UTC as far as the code concerned) to -epoch on my machine (-62135600400).

Starting from there I assume the calculation for the timestamp is happening at least once with start_time uninitialized (ending up scrobbling at (DateTime)0 - epoch, result see above).

Since I'm new to the code this is pure theory so far, but one comment in the SongTimer class says roughly "number of events to ignore, since they can happen in wrong order". IF (big one) it is possible that someone tuning into last.fm, directly hitting skip after seeing the first title generates PlayerEvent.StartOfStream and PlayerEvent.EndOfStream and they end up being in wrong order the calculation would be off as described above.

Commits since this bug has been filed don't seem to address this problem.

Two ways to fix this in my very humble opinion: The quick one (initialize start_time to DateTime.Now, in a race the scrobbling event would be off a bit) or the long one (understand in which order the events can happen and if these FIXME comments in DateUtil need more work, going for the root of the problem).

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

I just committed a patch implementing the quick fix suggested by Benjamin :
http://git.gnome.org/browse/banshee/commit/?id=f8fd8b986339a09d6132219e8b1a2862247fd90d