feat: Implement Deezer Internal (ARL) Source #296
Conversation
This file contains hidden or 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
UsageCreate a new [
{
"name": "MyDeezer",
"enable": true,
"data": {
"arl": "myArlHere01234",
}
}
]Retrieve ARL following these directions. The new Source is still pretty barebones. I need users to test it and report any issues they run across. |
|
Thanks a lot for the integration ! I will check this out and give feedback. |
|
I'm still getting this really strange behaviour when streaming deezer on my sonos speaker, where the song is put in the listening history at the beginning of the song and at the end. Recently PlayedPlaying music through sonos app:Playing music through airplay: |
|
Do you have multiple songs playing on different platforms/speakers at the same time? EX for this duplicate It looks like EDIT: Can you also verify if the timestamp shown for scrobbles is when you stopped listening to the song (either stopping player or track changes), or when you started listening (when track is first played) |
|
No I only play it on one speaker, it seems to be sonos implementation fault. Edit: yes it does definitely reflect starting and ending of the listening of the song (even if I changed to the next track). |
|
If this is an upstream Deezer issue I'm not sure I can do anything about it... MS does do some detection to see if a discovered play from a Source is a duplicate based on if the candidate timestamp matches another existing scrobble's But since Deezer is reporting two unique plays (with tracks between) it won't detect as duplicate. Being more aggressive about this would mean potentially ignoring scrobbles if the track was repeated consecutively, which would not be an improvement. I'll see what I can do though... |
Allows user-configurable decision on whether to ignore fuzzy-matched discovered plays
|
@Ectalite try out this new option in the deezer config: [
{
"name": "MyDeezer",
"enable": true,
"data": {
"arl": "myArlHere01234"
},
"options": {
"fuzzyDiscoveryIgnore": true
}
}
]When
That covers the behavior you were specifically seeing. With If you want MS to ignore all newer plays that match an older one (based on But this will likely cause MS to ignore consecutively repeated tracks. |
|
Cool ! It definitely seems to work on true. Edit: I wrote the comment to quickly, I still get the doubles. I think I will try the |
No, only if it finds two identical tracks who's timestamps are within 10 seconds of (timestamp +/- duration) |
|
@Ectalite is aggressive working for you? |
|
Tracks are rediscovered if I restart multi-scrobbler and even in aggressive mode I'm still getting duplicates. |
|
Can you include some info on the duplicates?
I've added tests that should me emulating the duplicate behavior you previously reported but if there is variance to the behavior or my tests are not reproducing it correctly then I need more data to determine why they aren't covering your usecase. |
|
Here is info you asked, I hope it can help: Recently Played (Deezer)Tracks Scrobbled (Maloja)Logs |
|
Thanks, that was informative. Looking at the deezer logs I took a sample of duplicates and checked their length against the timestamps reported by deezer for when they were listened to: So it seems that Deezer is reporting the duplicate as played at a timestamp with 15-30 seconds of delay AFTER when the track would have "ended" based on the track length. This is why MS is not catching it, as its only allowing up to 10 seconds of delay from expected ending. Example from the MS logs: I can increase that 10 seconds to ~40 seconds which may fix things but it'll make the duplicate culling even more aggressive...I'm trying to think of a more granular way to detect this that won't be so harmful to legitimate repeat plays. |
* Refactor fuzzy diff theshold to be configurable * Configure aggressive fuzzy discovery for Deezer to be 40 seconds #296
📦 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.
|
|
@Ectalite try the newest image with |
|
So I can't say for sure but it seems to be working. I will continue to try it and will give more feedback. Maybe unrelated, but Multi-Scrobbler couldn't send scrobbles to Majola for the past two days. I'm getting these debug logs: |
|
Maybe the only thing remaining is when I skip a song. For example here I skipped the song Arcade Fire - Suburban War. Recently Played (Deezer)Tracks Scrobbled (Maloja)Logs |
|
The timestamp difference between those two is 3:13 and the duration is 4:45 so its off by 92 seconds, much larger than the leeway allowed by MS. Are these all songs that are still being played on the Sonos speaker or just general Deezer listening that is also having this issue? Since Deezer doesn't return the time that a track was listened to (only returns the length of the track) I can't detect that a track was a skip. |
|
It's completely related to the sonos speaker, if I listen through the Deezer app directly it will only be put in the listening history if I hear the music for a minimum of 30s. From what I tested right now, it doesn't matter if I listen 10s at the beginning and then skip a part and listen 20s after. If the sum is 30s it will be put in the listening history. Do you think it's possible to have dynamic leeway dependent on the duration of the track ? Do you think it would have consequences on songs that are repeatedly played ? If yes would it be possible to have an option that discards repeated plays ? Maybe it would be simpler to report the problem to sonos directly at this point... I reported the issue to Sonos, let's see what they respond. |
Can you elaborate on what you mean by this?
Yeah I can implement this for deezer but it would be a bit of a nuclear option. |
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
Implement a new Deezer Source using ARL and internal/undocumented endpoints to get Deezer user listening history.
Thanks to @Ectalite for the proof of concept and providing their ARL/premium account for testing and development.
Issue number and link, if applicable