Apple Music: date_added never populated for library playlists (and albums) — "recently added" sort is wrong

[chrisbeams-ops]

Before you begin

• I have searched the open and closed issues and this hasn't been reported yet.
• I have read the troubleshooting guide and it did not solve my problem.
• I am running a supported installation (Home Assistant add-on or Docker container).

What happened?

What happened?

Sorting the library by "recently added" does not work for Apple Music. Every playlist gets its Music Assistant import time as timestamp_added instead of the date it was actually added to the Apple Music library, so the order is meaningless (it degrades to alphabetical / import-batch order).

Apple does expose the data. Calling the same endpoint MA uses, with the documented extend parameter, returns dateAdded on library playlists:

GET https://amp-api.music.apple.com/v1/me/library/playlists?extend=dateAdded
→ "Billie Eilish Essentials": { "dateAdded": "2024-02-25T15:01:08Z", ... }

dateAdded is a documented LibraryPlaylists attribute, marked not-required, so it is only returned when requested via extend. (Playlists added before ~2016 legitimately have no dateAdded — those are unavoidable.) The same gap affects library albums (me/library/albums also supports extend=dateAdded).

What I already tried (to save you the dead ends)

On 2.10.2 I patched the provider locally:

1. Added extend="dateAdded" to the me/library/playlists and me/library/albums requests in providers/apple_music/library.py.
2. Added a _set_date_added() helper (mirroring the Tidal provider) reading item["attributes"]["dateAdded"] into media_item.date_added, for each yielded playlist/album.

get_library_playlists() then yields playlists with date_added set correctly — but the value is still lost by the time the row is written: a removed + re-synced playlist comes back with today's timestamp, not its real dateAdded.

Tracing it: MusicController.add_item_to_library() re-fetches the item via get_item() → provider.get_playlist() → _get_regular_playlist(), which never sets date_added (and for hasCatalog/editorial playlists reads the catalog endpoint, which has no dateAdded at all). So the date_added the sync generator set is discarded on the re-fetch.

3. I then patched add_item_to_library() to carry the caller's date_added onto the re-fetched item. It still comes back insert-time — so the value is dropped at a further point I could not pin from outside the running process.

Also: for existing rows, _library_item_needs_update() doesn't treat a date_added change as update-worthy, so a normal re-sync never backfills dates onto playlists already in the library.

How to reproduce

Music Assistant version

2.10.2 (Home Assistant add-on, Python 3.14)

How to reproduce

1. Add the Apple Music provider, let the library sync.
2. Sort the playlist library by "recently added".
3. Order reflects sync/import time, not Apple's dateAdded. Confirm via the API call above that Apple returns real, differing dateAdded values for the same playlists.

Music Assistant version

2.10.2 (Home Assistant add-on, Python 3.14)

How do you run Music Assistant?

Home Assistant add-on

Diagnostics report or log file

music-assistant-diagnostics-2026-09-06-130515.json

Anything else?

No response

[musicassistant-bot]

Hi, and thanks for taking the time to report this! 🙏

Version: 2.10.2 · Install: HA add-on · Python: 3.14.7 · Platform: Linux-6.18.34-haos-raspi-aarch64-with-glibc2.41 · Players: 37

I went through the attached diagnostics and didn't spot any obvious problems in the automated checks. A maintainer will take a closer look.

🤖 AI assessment — possible root cause (for maintainers; may be wrong)

Apple Music library playlists (and albums) always get date_added set to the Music Assistant import timestamp instead of Apple's real dateAdded, making 'recently added' sort meaningless. Reporter traced this to two gaps: (1) the provider's me/library/playlists and me/library/albums requests never pass extend=dateAdded, so Apple's dateAdded attribute is never fetched; (2) even when patched to fetch it, MusicController.add_item_to_library() re-fetches the item via get_item()->get_playlist()->_get_regular_playlist(), a separate code path that doesn't carry dateAdded through, so the real value is still overwritten on (re-)sync.

Likely cause: apple_music/library.py builds the me/library/playlists and me/library/albums endpoints without extend=dateAdded, so Apple's documented but opt-in dateAdded attribute is never present in the API response; separately, the playlist detail/re-fetch path (_get_regular_playlist in media.py, used by add_item_to_library -> get_item -> get_playlist) does not read or propagate attributes.dateAdded into Playlist.date_added, so it falls back to MA's own import time.

Evidence considered:

• providers/apple_music/library.py L141-156: get_library_playlists() calls endpoint 'me/library/playlists' with no extend parameter
• providers/apple_music/media.py L189-202: _get_regular_playlist() fetches 'me/library/playlists/{id}' via get_data() with no extend param and no visible dateAdded handling
• Reporter's local repro: adding extend="dateAdded" plus a _set_date_added() helper (mirroring Tidal provider) populates date_added in get_library_playlists(), but value is lost again after add_item_to_library() re-fetches via get_item()->get_playlist()->_get_regular_playlist()
• Apple Music docs (per issue): LibraryPlaylists.dateAdded and library albums both support extend=dateAdded, confirmed via direct API call returning dateAdded

Maintainer next step: In the current apple_music provider source, check whether extend=dateAdded is passed on the me/library/playlists and me/library/albums requests in library.py, and whether _get_regular_playlist()/_get_regular_album() in media.py parse attributes.dateAdded into date_added (compare against the Tidal provider's _set_date_added pattern the reporter references) — if absent, this confirms the regression and both fetch paths need the fix.

category: bug · confidence: 70%

📖 Provider documentation

• Apple Music

Heads-up @MarvinSchenkel — this looks like it may be your area. 🙇

---

🤖 I'm an AI-powered triage assistant. I can make mistakes, and a human maintainer will still review this issue. This automation helps the small Music Assistant team keep up with the high volume of reports on this open-source project — thanks for your patience and for helping us help you!

[MarvinSchenkel]

We have a fix available, could you please test this with the DEV App? This won't interfere with your existing installation of MA, as it is a completely isolated installation of MA. Just run a clean Apple Music sync and see if the library now contains the correct sort order.

• In Home Assistant, make sure that 'Advanced mode' is 'ON' in your profile settings
• Go to 'Settings > Apps' and stop your current MA App
• Click 'Install an app' and install the 'Music Assistant DEV SERVER'
• Go to the configuration tab of the App
• Type dev for server_repo
• Type main for frontend_repo
• Start the app. This will take longer than you are used to
• Test if the issue has been resolved