Replies: 2 comments 5 replies
-
|
The reason for the change is that Maloja can additionally store the actual amount of time listened to the track alongside the scrobble. In order to get this data MS needs to wait until the track is changed (or finished) to know how long it was listened to. What is your usecase for wanting the it to scrobble as soon as the threshold is reached? |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Interesting, I had seen that field in Maloja but always thought it was meant to store the total length of the track, not then time spent listening to it during that scrobble. With Multi-Scrobbler 0.4.8, I had a 99.99% success rate (= songs that I listened fully that ended up in Maloja). Since I moved to 0.8.8, I feel it's more of a 97%, and I kind of assumed that there was a link between the two, but maybe my intuition is wrong. One scenario that feels problematic is the following :
In this scenario, it feels that the scrobble is not sent to Maloja at all, in 0.8.8. (or at least, not each time) I will run more tests and give you a reproduction scenario. Thanks for Multi-Scrobbler, I love it! |
Beta Was this translation helpful? Give feedback.
5 replies
-
|
MS calculates a "stale" and "orphaned" state for a Source based on the last time data from the Source was updated. The state is determined after some multiple of the polling interval has passed without seeing data for an individual player. After a Source becomes Stale MS attempts to scrobble the Play that was in-progress. The way Spotify's API works, they stop providing data for a "session platform" 1-2 minutes after the player is "closed" (web, desktop, mobile, auto), so MS would mark it as stale shortly after this happens. It's possible that the session is never closed if the player is truly paused and left in the foreground without closing. But in that scenario MS is still receiving "session platform" data and so keeps the Play (scrobble) data until you do something with the Spotify player again. You can see this in action for yourself. Make sure DEBUG logging is enabled for MS and then use spotify while watching MS's logs. Close a player and see that the logging marks it as stale and logs if it gets scrobbled or not. In either event...one of the other improvements since 0.4.8 is Consider this scenario where a Spotify track is 3:40 in length:
In 0.4.8 this would be 45s + 120s + 60s = 225s --> scrobble b/c over 50% of 3:40 Because in current MS when you pause it "ends" the current listening range (45s). MS then waits for it to resume before starting an additional range. When the track is finished (or the player becomes stale) it then adds all the ranges together to determine if scrobble threshold is met and then scrobbles if it does. So, even in your scenario where you resume the next day...if the player was in the foreground and did not become Stale then MS still has all the listening ranges for the session from the previous day and will accurately determine scrobble threshold after you resume. This should happen even if you resume on a different platform for the same Source ;) 1 2 You can see some of this range calculation in action in |
Beta Was this translation helpful? Give feedback.
-
|
Thank you so much for this very complete answer! |
Beta Was this translation helpful? Give feedback.
-
|
You can also log more to file to make it easier to track down what happened, if its not something you are checking on regularly. In {
"logging": {
"level": "debug"
}
}or set env This will log to rotating files for everything in MS Alternatively, if you have a bunch of sources and only one (spotify) is causing the issue you can enable the new, experimental source logger to only log to file for spotify 👀 In [
{
"name": "MySpotify",
"enable": true,
"clients": [],
"data": { /* ... */},
"options": {
"logToFile": "debug"
}
}
] |
Beta Was this translation helpful? Give feedback.
-
|
It just happened. I listened to the first part of a song this morning around 9:19, then I listened to the second half around 12:09. The song is 4:37 in total. It was never scrobbled to Maloja (name of the song : The song that came before ( Here are the logs in between : I have no clue what's happening, even after looking at the logs :-( |
Beta Was this translation helpful? Give feedback.
-
|
I see that you commited some improvements to logging. I'll deploy all these commits locally and come back to you next time this happens with even better logs. Thanks |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello,
I recently updated from Multi-Scrobbler 0.4.8 to 0.8.8.
A difference I noticed is that in version 0.4.8, it used to send the scrobbles to the clients as soon as the threshold was reached (with the default value, it was about 60 seconds after playback began).
I noticed that in version 0.8.8, it was waiting for the song to be entirely over to send the scrobbler to the client, even if the threshold was reached minutes before that.
Is there a setting to revert to the old behavior ? (and immediately send the scrobbler further as soon as the threshold is reached)
Thanks a lot!
PS : Here is my config:
config.json
maloja.json
spotify.json
Beta Was this translation helpful? Give feedback.
All reactions