feat(source): Stale/orphan scrobble and timestamp improvments #256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
FoxxMD
added
enhancement
FoxxMD
force-pushed
the
configurablePlayerStale
branch
from
973efde to
6c30135
Compare
|
@Fratt please try out this PR. You can specify stale after X seconds like this in [
{
"name": "MySpotify",
"data": {
// ...
"staleAfter": 60, // seconds after which Player becomes stale from no activity
"orphanedAfter": 360 // seconds after which Player becomes orphaned from no activity (removed after 2x interval)
}
}
]Though I would suggest trying it without these, first. I made a change that should prevent "resumed" plays from scrobbling again if the previous "paused" (before stale) play was scrobbled. There was a bug that let the "paused" listen time count towards the "resumed" (post-stale) listen time that has now been fixed. Also, can you remind me what platform you are using spotify on when you see it goes stale after pausing? From my own experience -- if on web/desktop and the application remains open the Player never goes stale even if paused for a long time. I haven't tested what this is like on mobile but I imagine that might be where you see it becoming stale. |
|
Thanks a lot! I'll try I know for a fact that it happened on mobile, indeed. But I cannot say for sure that it never happend on Desktop. (I listen 90% of the time on my phone, 10% of the time on my computer) |
|
I've been trying it for 2 days now, without any changes to my I will now try with
Thanks a lot! |
|
The default values are
The "no activity" mentioned in my previous comment means that the Source (spotify) is no longer returning any data for the unique player ID it was monitoring. This is not the same as the Player being in the same state (paused) for a long time -- it's literally "the data returned from the spotify API for Stale and Orphaned are two different levels of "what should MS do when player has no activity for X seconds"
You'd probably only want to set would be 8 hours in seconds. But I would also like to address the double scrobble if this really is a bug, or find out if your idea of how scrobbling should work is just different from MS. From the above explanation, [1] should be working but I don't think it fits your scenario since likely your Player is being orphaned/removed. For [2] you should only see a "double scrobble" if the track you resumed still had enough time left to meet the scrobble threshold of 4 minutes. For the tracks you've seen double scrobbled, is this the case? Put plainly:
|
|
I will take the time to answer your points properly soon. In the meantime, I added last evening But it seems to cause problems : It does double scrobbling even when I take a break of only 5 minutes while listening to a song, which is way worst than before :-(
Any idea why? I'll rollback the config for now |
…obble on resume Clearing pre-stale listening range prevents any future resume (player becomes non-stale) from using old listening range to scrobble. Represents a physical "break" between listening sessions for the same song
Makes logs easier to read when looking for stale source/player
FoxxMD
force-pushed
the
configurablePlayerStale
branch
from
6c30135 to
0ea5463
Compare
…T player Prevents listen duration from being reported as overdrift RT position due to lack of player updates
Makes testing easier
📦 A new release has been made for this pull request.To play around with this PR, pull an image:
Images are available for x86_64 and ARM64.
|
|
@Fratt please try the newest image, without |
|
I will, thanks! |
|
First, thanks a lot for all the efforts trying to improve multi-scrobbler! I'm not sure exactly what you fixed, but I can confirm that I still get double scrobbles, when I don't set Song : Epica - Sacred & Wild (duration : 4:47)
It looks like this in Maloja (as if I listened to the song twice, which isn't the case) Can I try again this config? Here are the logs: |
|
(beside the double scrobbles, the rest seems to work as usual) |
|
Do you have This log line indicates the time required for a track to be listened to in order to scrobble it is only 20 seconds while the default is 240s (4 minutes). |
|
Yes, here is my configuration : config.json maloja.json spotify.json Should I remove from my FYI, I added this as an attempt to have scrobbles for very short songs as well (songs shorter than 1 minute seemed to never get scrobbled), and left it here... Really sorry for wasting your time... |
|
Yes, you should remove it.
Sacred & Wild -> 4:47 (287 seconds) length Second listen 11:28:03 - 11:29:26 = ~83s listen time So MS is working correctly but the track is being scrobble because of the short duration requirement. Normally its 4 minutes OR 50%, whichever is met first. In a scenario with default thresholds it would not have scrobbled since duration (83s) is under 4min and percent (23%) is under 50%. |
|
Thank you, I removed it and I will keep you updated. Edit : Though, if I understand correctly, I could still get double scrobbles on very long tracks (> 8 minutes). Such tracks are quite rare indeed, so I could clearly live with that. |
|
Hey @Fratt how's it been going with the change? |
|
Hi Foxx, thanks for checking in. With the change, I seem to no longer have "double scrobbles" anymore! So, that's great :-) thanks for that Though... I'm experiencing a few lost scrobbles again, and now I think I completely understand when and why. It seems to happen when I take 2 breaks in the same song... 😅 I clearly remember that two days ago, a coworker told me "sorry to bother you, I see that you had just put your earphones back on again a short while ago" just when I was trying to listen to a song whose scrobble ended up getting lost... (oh, the joys of being PM 😂) Which totally makes sense : none of the three "parts" reached either of the thresholds... I'm considering rolling back the config to 20 seconds, and fork multi-scrobbler to prevent the Maloja client from scrobbling the same song twice in a row (I just have to "cache" the last scrobble). I feel that I already took up too much of your time... Any opinion on that? Thanks a lot |
|
Glad to hear the double scrobbles are gone. I think your break issue can now be solved with I would set it to whatever you would consider to be a reasonable amount of time for multiple breaks to occur without scrobbling again. Like maybe 1 or 2 hours. This should then work so that if the amount of time between no activity on a single track is less than 1 hour at a time -- so you could take a break multiple times as long as they are each less than 1 hour -- then when the track does eventually change (or more than 1 hour passes OR it goes stale and has hit threshold) it will scrobble. If this still doesn't work as expected then
i have another idea of how to address this, generally, for MS so you don't need to do this. Just let me know. |
|
oh of course! I have set |
|
Dear Foxx, I have been experiencing a lot of lost scrobbles this weekend, despite having In this example, the song "Wake The World" here was not scrobbled, besides the fact that I listened to it fully (I'm not sure if it was in 2 or 3 parts) : |
|
Actually, it seems that now, every time a song is played in more than one sitting, it doesn't scrobble it. Edit 1: I can confirm that it's the case. I just did a test with a simple pause of 6 minutes, and the scrobble was lost. Song : "Wings of Freedom", duration: 5:34
Logs: Edit 2 : It's just too tedious at the moment :-( I removed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Checklist before requesting a review
Type of change
Please delete options that are not relevant.
Describe your changes