gst-plugin-spotify has stopped functioning after the latest update

jonas

I realize that the new API credentials I created is in development mode, apparently it has some limitations like rate limiting and maximum number users, so I'll need to switch back to using the old.

jasmint

@tebriel

Maybe it builds from the git .tar.xz asset not truly directly from git which, if so, you can ignore me.

I had a poke around in the PKGBUILD of the official Arch package, and the source is

source=(git+https://github.com/strawberrymusicplayer/strawberry#tag=$pkgver
        https://github.com/strawberrymusicplayer/strawberry/releases/download/$pkgver/$pkgname-$pkgver.tar.xz)

So it does build from the .tar.xz asset (which may be a recent change after the credential thing). The more you know

@jonas
Oh i did notice I got rate limited before when trying to search up artists, so that's a nice change! I switched back to non-custom API credentials and can confirm there is no more rate limiting reported in the CLI

My Spotify tracks still don't play though (getting that same error of resource not found).
Running Strawberry with GST_DEBUG=3 strawberry --verbose

0:00:07.380990318     415737     415942 ERROR        spotifyaudiosrc audio/spotify/src/spotifyaudiosrc/imp.rs:278:<gstspotify::spotifyaudiosrc::imp::SpotifyAudioSrc as gstreamer_base::subclass::push_src::PushSrcImpl>::create:<spotifyaudiosrc0> track is not available
0:00:07.381084980     415737     415942 WARN                 basesrc gstbasesrc.c:3187:gst_base_src_loop:<spotifyaudiosrc0> error: Internal data stream error.
0:00:07.381095660     415737     415942 WARN                 basesrc gstbasesrc.c:3187:gst_base_src_loop:<spotifyaudiosrc0> error: streaming stopped, reason error (-5)
0:00:07.381131569     415737     415942 WARN                oggdemux gstoggdemux.c:4799:gst_ogg_demux_send_event:<oggdemux0> error: EOS before finding a chain
20:38:30.548 ERROR GstEnginePipeline:1867           ErrorMessageReceived ID: 1 Domain: 2267 Code: 3 Error: "Resource not found."
0:00:07.381152259     415737     415942 WARN                oggdemux gstoggdemux.c:2574:gst_ogg_demux_sink_event:<oggdemux0> EOS while trying to retrieve chain, seeking disabled
20:38:30.548 ERROR GstEnginePipeline:1868           ErrorMessageReceived ID: 1 Domain: 2267 Code: 3 Debug: "audio/spotify/src/spotifyaudiosrc/imp.rs(279): <gstspotify::spotifyaudiosrc::imp::SpotifyAudioSrc as gstreamer_base::subclass::push_src::PushSrcImpl>::create (): /GstPlayBin3:pipeline-1-pipeline/GstURIDecodeBin3:uridecodebin3/GstURISourceBin:urisourcebin0/GstSpotifyAudioSrc:spotifyaudiosrc0:\ntrack is not available"
20:38:30.548 ERROR GstEngine:640                    GStreamer error: 2267 3 "Resource not found."
20:38:30.575 WARN  IconLoader:129                   Couldn't load icon "media-playback-start" from system theme icons.
20:38:30.575 WARN  IconLoader:129                   Couldn't load icon "media-playback-start" from system theme icons.
20:38:30.576 WARN  IconLoader:129                   Couldn't load icon "media-playback-start" from system theme icons.
20:38:30.576 WARN  IconLoader:129                   Couldn't load icon "media-playback-start" from system theme icons.
0:00:07.410709571     415737     415737 ERROR                GST_BUS gstbus.c:1081:gst_bus_remove_watch:<bus1> no bus watch was present

I guess some part of my install is just borked... I did try deleting the Strawberry folder in .cache, but no change.

PeterB

So it does build from the .tar.xz asset (which may be a recent change after the credential thing). The more you know :thinking_face:

Not exactly. Its using the git tag.

jasmint

@PeterB

Not exactly. Its using the git tag.

Oh, nvm then lol

(edit: I thought the playback suddenly started working again, but I was actually playing from my local files LMAO. nvm!)

jonas

@kxfu
What version of gst-plugins-rs do you have?
The GStreamer Spotify plugin needs librespot 0.8 to play tracks, which is in version 0.14.4 and newer.

jonas

The issue could also occur of you don't have a premium subscription.

Garyzan

@jonas

Hi
I have the same issue, I tried with plugin versions 0.14.5 (with librespot 0.8.0) as well as versions 0.15.4 (0.8.0) and 0.16.0-alpha (0.8.0)
I do have Spotify Premium, and am playing songs that should be unrestricted where I am

iagonauta

Spotify Premium playback fails with track is not available — additional confirmation on openSUSE Leap 16.0

Hi everyone,

I can confirm the same playback issue on a different Linux distribution. I have performed several checks to distinguish an authentication problem from a Spotify audio playback problem.

System environment:

OS: openSUSE Leap 16.0 (x86_64)
Strawberry: 1.2.30 (native RPM)
GStreamer: 1.26.7
gst-plugin-spotify: 0.15.4, compiled from the official source
librespot: 0.8.0
Audio server: PipeWire 1.4.6 with PulseAudio compatibility
Spotify subscription: Premium

Verification results:

Spotify authentication in Strawberry: PASS.
Spotify catalogue access and synchronization: PASS.
Spotify tracks played in the official Spotify application: PASS.
The same tracks played through Strawberry: FAIL.
GStreamer successfully detects and loads the locally compiled gst-plugin-spotify 0.15.4.

The recurring error is:

Resource not found.

audio/spotify/src/spotifyaudiosrc/imp.rs(279):
GstSpotifyAudioSrc::create():
track is not available

I also reviewed the source code of the installed plugin. The GStreamer element reports this error after receiving PlayerEvent::Unavailable from the librespot playback layer, which is subsequently propagated as gst::ResourceError::NotFound.

This suggests that authentication and catalogue access are functioning, while the audio retrieval path is failing. The evidence does not yet identify the underlying cause within librespot or Spotify.

Questions for the developers and community:

Is this now considered a known regression in the librespot 0.8 playback implementation or the GStreamer Spotify plugin?
Has anyone identified a reproducible fix or a version combination that restores playback?
Would additional sanitized GStreamer/librespot debug logs help identify the underlying failure?
Is there an existing upstream issue where affected users should contribute their evidence?

For now, I have chosen to use Strawberry for my local music library and the official Spotify application for streaming.

Thank you for maintaining Strawberry and for any guidance on investigating this issue.

jonas

Can you run this and paste the output here, replace "<access token>" with a real access token, you can locate it from strawberry.conf in the [Spotify] section.

GST_DEBUG="spotify*:6" RUST_LOG=debug gst-launch-1.0 spotifyaudiosrc access-token=<access token> track=spotify:track:3i3P1mGpV9eRlfKccjDjwi ! fakesink silent=false -v

temol7977

Might be related: https://github.com/mopidy/mopidy-spotify/issues/437