fix(deezer): paginate song.getFavoriteIds to fetch all loved tracks#1008
Open
berettavexee wants to merge 1 commit into
Open
fix(deezer): paginate song.getFavoriteIds to fetch all loved tracks#1008berettavexee wants to merge 1 commit into
berettavexee wants to merge 1 commit into
Conversation
## Problem song.getFavoriteIds silently caps responses at roughly 25 entries per call regardless of the nb= parameter. The previous implementation called get_user_tracks() / get_my_favorite_tracks() which suffer the same cap (default limit=25 in deezer-py). Users with more than ~25 favorites only had a fraction of their library downloaded. A secondary issue: comparing the URL user_id against logged_in_user_id to detect "own profile" is unreliable for family accounts. change_account() shifts current_user to a child profile whose id differs from the main account's USER_ID that authenticated the ARL, so the comparison always fell into the "other user" branch and called get_user_tracks() without the full limit. ## Fix - Paginate song.getFavoriteIds via start= until the server returns an empty page. advance start by the actual count returned (not the requested page size) so the loop handles any server page size. - Remove the uid comparison entirely: song.getFavoriteIds carries no user_id parameter and always returns the authenticated account's favorites, making it the correct call regardless of family setup. - Cache logged_in_user_id during login() from get_user_data() for future use without additional round-trips. - Add DeezerFavoriteURL to parse_url.py to support profile liked-track URLs: https://www.deezer.com/{locale}/profile/{user_id}/loved ## Verified with - User with 406 favorites: 6x getFavoriteIds calls (5 data pages of ~100 entries + 1 empty terminator), all 406 tracks resolved. - Family account (child profile id ≠ main account USER_ID): favorites fetched correctly without falling back to the wrong API method. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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
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.
Problem
song.getFavoriteIdssilently caps responses at roughly 25 entries per call regardless of thenb=parameter. The previous implementation (absent from upstream, proposed in #987) calledget_user_tracks()/get_my_favorite_tracks(), which suffer the same cap. Users with more than ~25 favorites only had a fraction of their library downloaded.A secondary issue affects family/multi-account setups: comparing the URL
user_idagainstlogged_in_user_idto detect "own profile" is unreliable becausechange_account()shiftscurrent_userto a child profile whose id differs from the main account'sUSER_IDthat authenticated the ARL. The comparison always fell into the "other user" branch and calledget_user_tracks()without pagination.Fix
song.getFavoriteIdsviastart=until the server returns an empty page.startadvances by the actual count returned (not the requested page size) to handle any server-side page size.song.getFavoriteIdscarries nouser_idparameter and always returns the authenticated account's favorites — making it the correct call regardless of account type.logged_in_user_idduringlogin()fromget_user_data()for future use without additional round-trips.DeezerFavoriteURLtoparse_url.pyto support profile liked-track URLs:https://www.deezer.com/{locale}/profile/{user_id}/lovedThis supersedes #987.
Verified with
getFavoriteIdscalls (5 data pages of ~100 entries + 1 empty terminator) → all 406 tracks resolved.USER_ID): favorites fetched correctly without falling into the wrong API branch.Test plan
rip url https://www.deezer.com/fr/profile/USER_ID/lovedwith own profile → resolves all liked tracks (not capped at ~25)🤖 Generated with Claude Code