bug: "duplicate_timestamp" error when scrobbling to Maloja 3.2.3 #254
Labels
bug
Something isn't working
Comments
Fratt
changed the title
|
This somewhat expected from the Maloja side, actually. In Maloja < 3.2.3 it still detected a duplicate timestamp but did not return an error, instead just silently failing and not scrobbling. This was fixed in January 2024 so it would return an error response but was not released until 3.2.3. In general, we do not want to be scrobbling tracks with the same timestamp. From the MS side...I think I know the issue but would like to verify your behavior and what is expected. As I mentioned in our discussion on scrobble thresholds MS will scrobble only when 1) the track changes or the Source becomes stale (no update for some time) 2) the played track has met the traditional scrobble thresholds IE 50% played or 4 minutes(?) of play time. What I'm guessing is happening is that:
And the reason its rejecting it is because MS only set the "first seen at" date, which it uses as scrobble timestamp, once, when it first encountered the track. Since it never drops the track from the Source player (in MS) the second scrobble uses the original timestamp, instead of a timestamp from when you resumed the track. Does that align with what you are seeing behavior wise from MS? IE Do you see |
|
Hello, This is not exactly what is happening, I looked at it more closely. What seems to happen is that when a track becomes stale (and has reached the threshold before), MS will scrobble it with the same timestamp as the previous track that he scrobbled before, instead of using a more "recent" timestamp. Maloja then rejects that scrobble. This just happened now : I went to eat, so I paused the music. 15-20 minutes later, I got a notification from MS telling me that it couldn't scrobble the song that I was listening before going to eat... I checked, the timestamp it tried to use was the same timestamp as the previous song (that I can see in Maloja). I assume that when such thing happen, if I resume the play and there was not enough time to hit the threshold (a second time), then the scrobble is lost forever. Does that make sense to you ? A dirty workaround I see (if you cannot find a "better" timestamp for the track that got stale) is to keep the "last timestamp used" in the client, and simply increment it by 1 if trying to scrobble a song with the same timestamp... |
|
Would it help you to see some logs? |
|
Hmm ok that is definitely unexpected then. More logs are always helpful but your description is enough to get started on. Thanks for the input, I'll see if I can isolate this bug. |
FoxxMD
added a commit
that referenced
this issue
Jan 17, 2025
… timestamp Missing arg to pass to getPlayedObject to ensure the timestamp used for playDate is the same as normally discovered tracks. Without the arg two tracks played with the second being scrobbled on stale would cause the latter to have the same TS as the former fixes #254
2 tasks
2 tasks
|
Try out docker image |
|
Just saw your message now, I will try immediately, thanks a lot ! In the meantime, I gathered this for you (probably for nothing :D) - Since I did the job, I'll post it anyway.
|
|
I tried
Logs: (PS : I made sure I'm using |
|
I think there may be a problem with some changes I made today to the docker image publishing github actions. It looks like it didnt include the actual changes, for some reason. I'll figure that out later... I have manually built and pushed the PR tag again. Please try updating your image, the correct version should now be |
|
I can confirm that it works as expected, thanks a lot! The scrobble made when a track is stale has a different timestamp than the previous one. One final point : When the track resumes, if there is enough time left to reach the threshold (again), it scrobbles the track a second time. Is it by design / a limitation ? I can live with that, I'll take duplicate scrobble over missed scrobble anytime :D Thanks a lot again for the fast fix! |
FoxxMD
added a commit
that referenced
this issue
Jan 18, 2025
fix(spotify): Generate played object from cleanup with correct TS
|
It is by design. I treat it as a second play because enough time passed between the original "session", which became stale (not listening), and this new "listen" of the same track. I might consider adding a "staleAfter" configuration option to allow making that buffer time longer |
|
Thanks for the explanation! Would be a very nice configuration option, I often pause music for a few hours |
|
Released in 0.9.1 and available in the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please check existing knowledge before opening an issue
Describe the Bug
Maloja 3.2.3 has been released 2 days ago ! (yay!)
But... I have been experiencing some issues with Multi-Scrobbler since I updated to it :-(
When I pause a song in the middle of it, and I resume it later, the scrobble for that song cannot be pushed to Maloja, and I receive the following error in Multi-Scrobbler (see below).
It is not clear yet to me if this is every time the case, but it seems to happen often.
Pressing "Retry" in Multi-Scrobbler doesn't work : It returns the same error from Maloja.
This error seems "justified" from Maloja : If I look at the timestamp in question, I find a scrobble there : A scrobble for a different song.
When I find the time, I will try to find a reproduction scenario + submit more logs to help you debug it.
Thanks in advance!
Platform
Docker
Versions
Logs
Additional Context
No response
The text was updated successfully, but these errors were encountered: