Type in your question below and we'll check to see what answers we can find...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
My Question or Issue
I know this is like yelling into an echo chamber as nothing ever comes of these bug reports. We Linux users are basically just talking to ourselves. But here goes...
Recently the cover art url (mpris:artUrl) in the metadata leads to a dead end. The url itself is not malformed it just doesn't lead to anything but a file not found error.
As a side note, best practice for cover art is to cache it locally at least for the session and send the cached file url to MPRIS not only does that make covers load faster but it also cuts down on network traffic.
If all you're going to add is boilerplate advice to delete some folders and reinstall Spotify just don't... Maybe try actually fixing your software and/or CDN...
I would be ashamed of the state of the Spotify desktop app if I were you...
Don't be so aggressive.
There is who actually worked in this problem:
I'm upset because their desktop app is basically rotting and they know it yet they do nothing about it.
The daemon/service you're linking to is not a solution. It's ridiculous to run a standalone daemon just to workaround Spotify's broken desktop app.
The solution is for someone at Spotify to fix their garbage. If they're not going to fix their garbage then they should just toss it and start libspotify back up again.
I may see what can actually be done with the web api. I haven't really looked at it. If it can be used to create a proper backend for a player I may just write my own. I know my way around gtk, gstreamer and MPRIS. It wouldn't be my 1st guerilla music streaming service client (I am one of the main contributors to Pithos).
My custom OpenGL-Display that pulled the cover from dbus also broke.
The coverurl that Spotify provides is invalid.
$ qdbus org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Metadata mpris:artUrl: https://open.spotify.com/image/ab67616d00001e02d56e829cb8db19f77b1c79d1 mpris:length: 218174000 mpris:trackid: spotify:track:1En4GGPJDPtlGvrCkBIEpy xesam:album: Fly Octo Fly ~ Ebb & Flow (From "Splatoon 2: Octo Expansion") xesam:albumArtist: Qumu xesam:artist: Qumu xesam:autoRating: 0.47 xesam:discNumber: 1 xesam:title: Fly Octo Fly ~ Ebb & Flow (From "Splatoon 2: Octo Expansion") xesam:trackNumber: 1 xesam:url: https://open.spotify.com/track/1En4GGPJDPtlGvrCkBIEpy
The provided art-Url is invalid.
A quick check on the WebApp showed that using the ID from that url and the prefix "https://i.scdn.co/image/" makes it work again. Though the client is more throughly checked.
This also means, that native linux toolbars that show the Cover, currently can't with the data provided by the Spotify Linux App.
Good to know, thanks I'm also the author and maintainer of the mpris-indicator-button GNOME Shell extension I can use that info to workaround the issue.
I made patches for KDE Plasma media controller and task bar to work around this issue:
This is unlikely to be accepted upstream since the root cause is a bug in the official Spotify client, but in the meantime it solves the problem for me.
Thanks for reaching out to us here in the Community.
We've chatted to the right teams, and can confirm they're working on this. We'd recommend keeping the app up-to-date, and checking for a fix in new releases!
If anything else comes up - the Community is always a post away 🙂
thanks for your reply.
this is the linux forum. your last release is from march https://snapcraft.io/spotify and there has been 8 windows releases since then https://www.spotify.com/us/opensource/
That's basically the boilerplate response I specifically asked not to get but expected...
"Be on the look out for some mythical future update that just might fix the issue."
I've created a simple python script to patch the Spotify binary, if you don't want to wait for the patch... just copy it in a text file, chmod +x it and execute it, like `sudo ./spotify-mpris-art-fix.py --patch`
the issue is fixed for me in the Spotify client version 1.1.67
Can confirm! It is reporting the correct url now!
This issue seems to be resolved with that version! Huge thanks!
Hey there you, Yeah, you! 😁 Welcome - we're glad you joined the Spotify Community! While you here, let's have a fun game…