Post

Replies

Boosts

Views

Activity

Reply to Tracks missing from Apple Music API listening history
Adding another confirmed case with a clear reproduction pattern. Setup: Apple ID region Turkey (storefront tr), "Use Listening History" ON, Sync Library ON. Endpoint: GET /v1/me/recent/played/tracks. What I observe: Play a track from the Library (e.g., the auto-generated "Favorite Songs" playlist or Media Library) → the play never appears in the API response. Play the same track from the catalog (e.g., found via Search) → it does appear — even though the track is in my library. Plays from a Station (including briefly skipped tracks) appear normally. The in-app listening history (Music app → History) shows all of these plays correctly, including the library ones. So the app records library-sourced plays, but the API listening history silently drops them. The deciding factor seems to be the surface the playback was started from (Library vs. catalog/Station), not the track itself. I checked both immediately after playback and hours later — the library plays never show up. Is this a known server-side filtering, or should library-sourced plays be included? Happy to run more diagnostics if helpful. Update with more data: Plays from my own playlists are also missing — even when the tracks are NOT in my library (pure catalog tracks added to a user playlist). So the exclusion is not about library content. Updated pattern: Catalog Search play → appears Station plays (even skipped) → appear Library / "Favorite Songs" plays → missing User playlist plays (catalog tracks) → missing This looks like the endpoint deliberately excludes playback initiated from user-curated sources (library, own playlists) while including Apple-curated flows (search, stations). Could you confirm whether this is intended behavior? It makes the endpoint unusable for whole-history use cases, since most listening typically happens from the user's own playlists. Final update — pattern confirmed: Plays from Apple's editorial playlists (e.g., New Music Daily) do appear. So the rule is consistent: ✅ Apple-curated flows: Search, Stations, editorial playlists ❌ User-curated flows: own playlists (even with pure catalog tracks), Library, Favorite Songs The deciding variable is the initiating surface, not the track. Unless this is intended (in which case the endpoint is discovery-only by design and should be documented as such), it seems like a server-side filtering bug that makes whole-history use cases impossible.
Topic: Media Technologies SubTopic: Audio Tags:
Sep ’26
Reply to Tracks missing from Apple Music API listening history
Adding another confirmed case with a clear reproduction pattern. Setup: Apple ID region Turkey (storefront tr), "Use Listening History" ON, Sync Library ON. Endpoint: GET /v1/me/recent/played/tracks. What I observe: Play a track from the Library (e.g., the auto-generated "Favorite Songs" playlist or Media Library) → the play never appears in the API response. Play the same track from the catalog (e.g., found via Search) → it does appear — even though the track is in my library. Plays from a Station (including briefly skipped tracks) appear normally. The in-app listening history (Music app → History) shows all of these plays correctly, including the library ones. So the app records library-sourced plays, but the API listening history silently drops them. The deciding factor seems to be the surface the playback was started from (Library vs. catalog/Station), not the track itself. I checked both immediately after playback and hours later — the library plays never show up. Is this a known server-side filtering, or should library-sourced plays be included? Happy to run more diagnostics if helpful. Update with more data: Plays from my own playlists are also missing — even when the tracks are NOT in my library (pure catalog tracks added to a user playlist). So the exclusion is not about library content. Updated pattern: Catalog Search play → appears Station plays (even skipped) → appear Library / "Favorite Songs" plays → missing User playlist plays (catalog tracks) → missing This looks like the endpoint deliberately excludes playback initiated from user-curated sources (library, own playlists) while including Apple-curated flows (search, stations). Could you confirm whether this is intended behavior? It makes the endpoint unusable for whole-history use cases, since most listening typically happens from the user's own playlists. Final update — pattern confirmed: Plays from Apple's editorial playlists (e.g., New Music Daily) do appear. So the rule is consistent: ✅ Apple-curated flows: Search, Stations, editorial playlists ❌ User-curated flows: own playlists (even with pure catalog tracks), Library, Favorite Songs The deciding variable is the initiating surface, not the track. Unless this is intended (in which case the endpoint is discovery-only by design and should be documented as such), it seems like a server-side filtering bug that makes whole-history use cases impossible.
Topic: Media Technologies SubTopic: Audio Tags:
Replies
Boosts
Views
Activity
Sep ’26