Fix: use extended-metadata endpoint to acquire metadata

[photovoltex]

As noticed by @michaelherger in #1621 the metadata endpoint seems to be broken again and does not contain anymore the file data.

This changes uses the extended metadata endpoint instead, which currently still contains that data.

Fixes #1623, Fixes #1620

[Copilot]

Pull Request Overview

This PR refactors metadata retrieval to use the extended metadata API endpoint instead of the legacy metadata endpoint, fixing an issue where metadata didn't include audio files.

• Replaced the legacy /metadata/4/{scope}/{id} endpoint with the /extended-metadata/v0/extended-metadata endpoint
• Updated all metadata methods to accept &SpotifyUri instead of &SpotifyId
• Removed the SPCLIENT_FALLBACK_ENDPOINT constant that was previously needed for the legacy endpoint

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
metadata/src/track.rs	Updated to pass full SpotifyUri to get_track_metadata instead of extracting the ID
metadata/src/show.rs	Updated to pass full SpotifyUri to get_show_metadata instead of extracting the ID
metadata/src/episode.rs	Updated to pass full SpotifyUri to get_episode_metadata instead of extracting the ID
metadata/src/artist.rs	Updated to pass full SpotifyUri to get_artist_metadata instead of extracting the ID
metadata/src/album.rs	Updated to pass full SpotifyUri to get_album_metadata instead of extracting the ID
core/src/spclient.rs	Refactored metadata methods to use the extended metadata API, changed signatures to accept &SpotifyUri, and updated get_extended_metadata return type
CHANGELOG.md	Documented the breaking changes and bug fix related to metadata retrieval

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[hbsagen]

Great, saved my evening. Works nicely!

[michaelherger]

Working in my 30s of testing.

I'd still get multiple of the following messages per second (in debug mode):

[2025-11-06T19:15:18Z WARN  libmdns::fsm] error sending packet Os { code: 65, kind: HostUnreachable, message: "No route to host" }

[michaelherger]

And works with my fork, too!

[DamianRyse]

Works pretty good for me.

[OneTrueJASH]

I can also confirm this fix works as expected. I've successfully tested it with spotify-player v0.21.1.

Since the SpotifyUri API changes were already present in the dev branch (prior to this PR), I first updated spotify-player to be compatible with those changes:

• Updated functions to use SpotifyUri enum instead of checking SpotifyId.item_type
• Pattern matching on SpotifyUri variants (Track { id }, Episode { id }) to extract the underlying SpotifyId

With those compatibility changes in place, this PR's metadata endpoint fix works perfectly. Spotify-player now successfully uses the /extended-metadata/v0/extended-metadata endpoint and tracks play without the "Track should be available, but no alternatives found" errors.

I'm preparing a compatibility PR for spotify-player to ensure it's ready when the librespot dev branch changes land in a release.

Thanks @photovoltex!

[photovoltex]

Working in my 30s of testing.

I'd still get multiple of the following messages per second (in debug mode):

[2025-11-06T19:15:18Z WARN  libmdns::fsm] error sending packet Os { code: 65, kind: HostUnreachable, message: "No route to host" }

@michaelherger I don't have such warnings, so this might be something on your end then? But I wont rule out that there is still something we need to fix later down the line.

[OneTrueJASH]

@michaelherger I don't have such warnings, so this might be something on your end then? But I wont rule out that there is still something we need to fix later down the line.

I also gave this a spin to see if I could reproduce the libmdns warnings @michaelherger mentioned:

RUST_LOG=debug ./target/release/librespot --enable-oauth --name "test-device"
Duration: ~60 seconds
My setup:

• macOS Tahoe 26.1 (25B78)
• rustc 1.91.0 / cargo 1.91.0

What I saw:

• No "error sending packet Os { code: 65, kind: HostUnreachable, message: 'No route to host' }" errors on my end
• Just the normal libmdns DEBUG libmdns::fsm] received question messages for discovery queries (_spotify-connect._tcp.local, etc.)
• Everything authenticated and shut down cleanly

So yeah, looks like those warnings are probably specific to certain network setups, as @photovoltex suggested. I couldn't reproduce them here, but thought I'd share just in case it helps!

[michaelherger]

Thanks - I'll see whether I can find something. I'm using PiHole - maybe it's swelling a little too much.

[pienczyk]

I just built it for my Raspberry and it works. Thanks @photovoltex and @roderickvd !

[EduardLupu]

Thanks! I wonder why they removed the preview from https://spclient.wg.spotify.com/metadata/4/track/, it broke my app. Will use this solution!