In the past, if we attempted to scrobble a track dated earlier than our last submission, last.fm would catch that and trigger a spam protection warning. Now it appears that last.fm allows tracks earlier than the last submission.

My setup and how I can reproduce this:

At work, connect iPod and use it as my music source when listening to music in iTunes. Songs scrobble throughout the day. Life is good.

Leave work, listen to 10 songs on my iPod on my way home.

At home, sync my iPod with iTunes. Use iSproggler to scrobble tracks played on my iPod. Note this will include all songs played on my iPod including those that had already been scrobbled throughout the day.

Expected results: last.fm will ignore all but those last 10 tracks that I listened to on my way home from work because all others had been scrobbled already.

Actual results: *all* tracks are counted again.

My playcount before syncing & iPod track submission by iSproggler: 98748. My playcount afterwards 98831. Expected playcount afterwards: 98758.

Did spam protection go away in the last.fm overhaul? Is this a bug or expected behavior now?

Cheers.

Russ said:
Yes, we removed that particular part of spam protection a while ago because it was annoying people. We've got some more sophisticated spam protection logic now which you're much less likely to run into.

Well, I've lost a lot of tracks in the past due to this spam protection, and some of them are back since the new last.fm page was launched. Please, be consequent and decide either you bring back all the tracks that was deleted by the spam protection, or delete those few (or not 100%) brought back tracks from the past, because my stats are extremely inaccurate at the moment, to say this moment is lasting for at least a month and now I've virtually suspended my profile because I don't know anything about my stats. And I would like to mention that I'm looking forward also sorting out the 'deleted history tracks are back' problem, because it causes the same headache too.

Russ said:
Yes, we removed that particular part of spam protection a while ago because it was annoying people. We've got some more sophisticated spam protection logic now which you're much less likely to run into.Ah, thank you for the explanation.

I can totally understand the removal of the old spam protection. Users could listen to their iPod in the morning, then decide to listen to a friend's radio station via the last.fm client for a bit, then decide to sync & scrobble their iPod tracks. Obviously they'd want their earlier iPod tracks to be counted and not rejected because they were trying to scrobble tracks played earlier than the last submission.

So the new logic doesn't catch double scrobbles with the exact same "played on" timestamp though?

I would imagine anyone using their iPod as the source of their music while scrobbling via Winamp or iTunes or whatever throughout the day is going to fall prey to the double scrobble "feature" if they sync at night & let the last.fm client or iSproggler scrobble their iPod tracks from throughout the day.

Studogvetmed said:
If you ask to be prompted for iPod scrobbles before scrobbling, you would be able to untoggle all songs, and only select the ones you listened to on the way home to be sent in.

Alternatively, you can disable scrobbling at work if you don't mind people having to wait to see what you played during the day.

Cheers.I use iSproggler and it doesn't do any prompting. Are you referring to the last.fm client? If so, now that it supports iPod scrobbles maybe there's no reason for me to use iSproggler anymore. So thank you as I didn't know about the prompting thing.

I like to scrobble during the day hence why I listen via iTunes (otherwise I'd just stick with my iPod). In the past last.fm's spam protection always caught these double scrobbles and I only just noticed yesterday that it now allows multiple scrobbles with the same "played on" timestamp.

I dunno, in one respect I do think this is a teeny bug as there's nothing stopping a user from inflating their playcount by submitting the same tracks again and again over the course of a day or indeed days. Obviously I haven't seen the DB schema and could be *way* off base here but it seems odd that there's no unique index on "user_id, track_played_on" to eliminate users having multiple songs with the same track_played_on timestamp.