Spotify: playlist playback fails on accounts where the tracks/{id} endpoint is restricted

[charri]

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).

What happened?

Since 2.10, playing a Spotify playlist fails completely on a provider instance whose Spotify account cannot use the tracks/{id} Web API endpoint. Every track is skipped as unplayable and playback never starts. The same playlists played fine on 2.9.12.

I have three Spotify Premium accounts connected as three provider instances. Two of them are restricted by Spotify: me/albums, me/tracks, me/following, me/shows and tracks/{id} all return 404, while the playlist endpoints work normally. (Instance ids, track ids and titles redacted below.)

INFO  [player_queues.media_resolver] Fetching tracks to play for playlist <playlist>
WARN  [player_queues] Skipping unplayable item <track 1>: track://<track-id-1> not found on provider spotify--AAAAAAAA
WARN  [player_queues] Skipping unplayable item <track 2>: track://<track-id-2> not found on provider spotify--AAAAAAAA
WARN  [player_queues] Skipping unplayable item <track 3>: track://<track-id-3> not found on provider spotify--AAAAAAAA
WARN  [player_queues] Skipping unplayable item <track 4>: track://<track-id-4> not found on provider spotify--AAAAAAAA
WARN  [player_queues] Skipping unplayable item <track 5>: track://<track-id-5> not found on provider spotify--AAAAAAAA
WARN  [webserver] player_queues/play_media: No playable item found to start playback

music/playlists/playlist_tracks on that same instance returns all 17 tracks of this playlist, each with is_playable: true and a provider mapping with available: true. So MA already holds complete, playable Track objects - and then discards them and re-fetches each one individually.

The message track://... not found on provider ... is built in MediaController.get_provider_item, which points at the enrichment re-fetch in player_queues/queue_loader.py::_load_item:

elif not queue_item.media_item.image or queue_item.media_item.provider.startswith("ytmusic"):
    fetched_item = await self.mass.music.get_item_by_uri(queue_item.uri)

A failure inside get_stream_details would instead read Unable to retrieve streamdetails for ..., and that does not appear in the log. The library lookup on the line above misses, because library sync is also impossible on these accounts.

Net effect: a provider that can list a playlist but cannot fetch an individual track can never play a playlist, even though the listing already carried everything needed.

Possible fix

The re-fetch looks like an enrichment step (artwork / fuller metadata), so its failure arguably shouldn't make the item unplayable. Two options I can see:

1. Keep the item from the listing when the re-fetch raises MediaNotFoundError. YouTube Music appears to rely on this lookup to spot unavailable listing items, so it would need to keep raising.
2. Pass the track already in hand as the fallback argument that get_provider_item already accepts. No caller currently passes it, so it only falls back to a library item - which is absent in this case.

Happy to test a patch against my setup.

How to reproduce

1. Connect a Spotify account whose tracks/{id} endpoint returns 404 (playlist endpoints still work).
2. Play any playlist on that provider instance, from the UI or via the music_assistant.play_media action.
3. Every track is logged as Skipping unplayable item ... not found on provider <instance>, then No playable item found to start playback.

Control, in the same install: the same track id and the same playlist resolve and play fine through an unrestricted account's provider instance. So it is specific to the restricted account, not to the playlist or its tracks.

Music Assistant version

2.10.2

How do you run Music Assistant?

Home Assistant add-on

Diagnostics report or log file

Log excerpt above. I can attach a full diagnostics report if useful.

Anything else?

• Home Assistant 2026.9.0, HAOS 18.2, RPi4-64.
• Worked on 2.9.12; first failure here on 2026-09-03, when the 2.10 line was installed.
• Can't re-authenticate with Spotify: instance_id of type <class 'str'> is required." #6171 in 2.10.2 added the reason to the skip line - that is what made this diagnosable, thanks.

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

[musicassistant-bot]

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

In short

• Doing: Playing a Spotify playlist on a provider instance whose account cannot use the tracks/{id} endpoint
• Happened: Every track is skipped as unplayable and playback never starts, though the playlist listing already returned all playable tracks
• Expected: The playlist should play using the tracks already fetched from the listing instead of failing when the per-track re-fetch fails

_{Condensed from the report above by a bot, so it may be wrong — the reporter's own words are below.}

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

Here's what I found in the attached diagnostics:

🟠 Captured exceptions

The diagnostics captured these recurring errors, most frequent first:

• MediaNotFoundError ×2 — music_assistant/controllers/music/media/base.py:1059 in get_provider_item: Error executing command music/tracks/get: MediaNotFoundError: track://5ooZZjKyWRgpUayHhuGtaV not found on provider spotify--X7heyjdX

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

Reporter states that since MA 2.10, playing a Spotify playlist fails entirely on provider instances whose Spotify account has the 'tracks/{id}' Web API endpoint restricted (returns 404), even though 'music/playlists/playlist_tracks' already returns full, playable Track objects with 'available: true'. Diagnostics confirm MediaNotFoundError from 'music/tracks/get' via 'get_provider_item', and worked fine on 2.9.12.

Likely cause: queue_loader.py::_load_item appears to re-fetch each queue track individually via get_item_by_uri/get_provider_item (the snippet at L334-338 shows a re-fetch path originally intended for YouTube Music's poor-thumbnail/unavailable-item case) even when the playlist listing already supplied a complete, playable Track. On accounts where Spotify's 'tracks/{id}' endpoint is blocked (403/404), this unconditional re-fetch throws MediaNotFoundError and the item is marked unplayable, even though the already-fetched playlist item was valid. This matches the reporter's traced code path exactly and the regression timing (worked in 2.9.12, broke in/around 2.10) suggests the re-fetch condition was broadened or a guard was lost, rather than a Spotify-side change (playlist listing itself succeeds).

Evidence considered:

• Issue traceback: music_assistant/controllers/music/media/tracks.py:180 -> base.py:618 get_provider_item -> MediaNotFoundError for track:​//... not found on provider spotify--X7heyjdX, invoked via 'music/tracks/get'
• music_assistant/controllers/player_queues/queue_loader.py L334-338: conditional re-fetch of full item via get_item_by_uri, commented as originally for YouTube Music unavailable-item handling, now apparently also triggered for Spotify tracks
• music_assistant/controllers/player_queues/controller.py L1379-1385: MediaNotFoundError during stream-detail resolution causes queue_item.available=False and 'Skipping unplayable item' warning, matching reported log output
• Reporter's own inspection: 'music/playlists/playlist_tracks' on the same instance returns all 17 tracks with is_playable=true and available=true, indicating the initial fetch succeeds and only the later re-fetch fails
• Provider doc (music-providers/spotify#​known-issues-notes) documents other Spotify account-restriction quirks (Soloist/librespot) but does not mention a tracks/{id} restriction, so this is not a documented/expected limitation

Maintainer next step: Review queue_loader.py::_load_item around L320-340 to determine why the re-fetch branch (originally scoped to Youtube Music thumbnail/unavailable-item handling) is being hit for Spotify Track items that already came back fully populated and playable from playlist_tracks; add a guard to skip re-fetch when queue_item.media_item is already a complete, available Track, then test playback against a Spotify account known to have tracks/{id} restricted.

category: bug · confidence: 62%

📖 Provider documentation

• Spotify

🔁 Similar past reports

These earlier issues or discussions look related and might already have an answer (or indicate a duplicate):

• #5114: Spotify playlists return 403 Forbidden — /playlists/{id}/tracks endpoint removed Feb 2026 (closed)
• #5919: Spotify playlists created by users fail to load tracks (closed)
• #6086: Spotify playlists are found but playlist tracks fail with “playlists/{id}/items not found” (closed)
• #5476: Spotify playlists created by users fail to load tracks (closed)
• #6056: Fail to fetch Spotify tracks (closed)

---

🤖 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!

[charri]

i've attached diagnostics to the original post.

[OzGav]

Are you using your own client ID with the problem accounts? Why do you say "Two of them are restricted by Spotify"?