Skip to content

fix(deezer): paginate song.getFavoriteIds to fetch all loved tracks#1008

Open
berettavexee wants to merge 1 commit into
nathom:devfrom
berettavexee:fix/deezer-favorites-pagination
Open

fix(deezer): paginate song.getFavoriteIds to fetch all loved tracks#1008
berettavexee wants to merge 1 commit into
nathom:devfrom
berettavexee:fix/deezer-favorites-pagination

Conversation

@berettavexee

@berettavexee berettavexee commented Jun 25, 2026

Copy link
Copy Markdown

Problem

song.getFavoriteIds silently caps responses at roughly 25 entries per call regardless of the nb= parameter. The previous implementation (absent from upstream, proposed in #987) called get_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_id against logged_in_user_id to detect "own profile" is unreliable because change_account() shifts current_user to a child profile whose id differs from the main account's USER_ID that authenticated the ARL. The comparison always fell into the "other user" branch and called get_user_tracks() without pagination.

Fix

  • Paginate song.getFavoriteIds via start= until the server returns an empty page. start advances by the actual count returned (not the requested page size) to handle any server-side 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 account type.
  • 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

This supersedes #987.

Verified with

  • User with 406 favorites: 6× 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 into the wrong API branch.

Test plan

  • rip url https://www.deezer.com/fr/profile/USER_ID/loved with own profile → resolves all liked tracks (not capped at ~25)
  • Same with a family account (child profile) → resolves correctly
  • Standard track/album/playlist downloads unaffected

🤖 Generated with Claude Code

## 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant