Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lordhong]

Been running last.fm plugin fine for a while until lately when the last.fm web site started having heavy problems with timeouts.

My problem seems to be that the MC 12 plug in for last.fm doesn't behave properly with last.fm in regards to their spam filter. Let me try to explain...

If I listen to three tracks, A, B and C. A is submitted to last.fm, goes fine. B then gets a timeouts from the submission server at last.fm and gets queued in MC for submission, all fine up to here. C plays, get submitted before B is resubmitted, C is accepted. However whenever B will manage to get submitted, it will be rejected by last.fm because of the spam filter (it was played earlier than my last submission, track C).

With the awful lots of timeouts I get from last.fm, about half of my songs gets submitted and the rest are killed by the spam filter. I didn't have this problem a month ago, so I doubt it's something on my end that has changed...

Is there a way to set the plug-in so that it keeps resubmitting the same track before attempting to submit a new one?

[sithlord0338]

I have seen this behavior as well.

[p7389]

It has happened to me too. As you say, an option to keep it from resubmitting ahead of order of play would probably be a good solution.

But usually it isn't that much of a problem, because when last.fm doesn't respond for me, it doesn't respond indiscriminately... So what happens most of the times is that as I start MC the next day, everything will be submitted in turn.

[RhinoBanga]

If you do not go onto the next track it is possible that the entire submission queue could block because of that one track.

[Alex B]

If you do not go onto the next track it is possible that the entire submission queue could block because of that one track.

Why would submitting the next track be easier than resubmitting a queued track? Is the submitted data packet somehow different?

[RhinoBanga]

Each track is assigned a timestamp when it is played.

By default when a track fails to submit it gets pushed to the end of the queue and the next track is attempted.   last.fm changed their code to refuse tracks with a timestamp prior to the last successfully submitted track (although there is a bit of leeway).

This is the problem people are seeing.

To get around this I could keep reattempting the current track however as I said it is entirely possible that this can hold up the entire submission process if the track is refused due to some other reason, e.g. bad tags.


I suppose I could add an option to reapply the timestamp when the submission is reattempted but this will lose the real playback time.

[Alex B]

Each track is assigned a timestamp when it is played.

By default when a track fails to submit it gets pushed to the end of the queue and the next track is attempted.   last.fm changed their code to refuse tracks with a timestamp prior to the last successfully submitted track (although there is a bit of leeway).

This is the problem people are seeing.

I already understood all this, but I thought the reason for unsuccesful submission was a connection timeout problem. Doesn't the server provide feedback when the submission is refused because of bad data?

To get around this I could keep reattempting the current track however as I said it is entirely possible that this can hold up the entire submission process if the track is refused due to some other reason, e.g. bad tags.

If a file is refused because of incorrect format and the server provides feedback about the reason naturally the file should be removed from the list. (Though, if the used protocol does not create checksums and cannot resend a bad packet it should do a few retries for eliminating a possible data transfer error.)

I suppose I could add an option to reapply the timestamp when the submission is reattempted but this will lose the real playback time.

This would be better than to not submit at all. The timestamp would be from the same hour or day anyway.

In general, there is no sense in keeping the file in the queue if the submission is not possible anymore because of a newer successful submission.