Not working on Pop!_OS 20.10 with new Spotify about gnome-shell-spotify-artwork-fixer

[stuarthayhurst]

I'll start work on this, see where I end up. I'll make another PR when I get it working and polished up.

[Cubevoid]

It seems that the domain Spotify uses for its images is still correct, for example https://i.scdn.co/image/ab67616d0000485142b0696dd9f10f6cea96e10e works.

❯ qdbus org.mpris.MediaPlayer2.spotify /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.Metadata

mpris:artUrl: https://open.spotify.com/image/ab67616d00001e0242b0696dd9f10f6cea96e10e
mpris:length: 155000000
mpris:trackid: spotify:track:37s8uwIjw72XfMseKJXNOO
xesam:album: Rockefeller Street (New Nightcore) [#Rockefellerstreet Remix]
xesam:albumArtist: Getter Jaani
xesam:artist: Getter Jaani
xesam:autoRating: 0.61
xesam:discNumber: 1
xesam:title: Rockefeller Street (New Nightcore) [#Rockefellerstreet Remix]
xesam:trackNumber: 1
xesam:url: https://open.spotify.com/track/37s8uwIjw72XfMseKJXNOO

So maybe the URL domain just isn't being replaced properly for some reason? Toggling the extension on and off doesn't seem to change the output of this command.

[wjt]

The extension would not change the output of that command – it replaces the URL within the gnome-shell process.

You could add some debug prints to the extension? :)

[Cubevoid]

The extension would not change the output of that command – it replaces the URL within the gnome-shell process.

You could add some debug prints to the extension? :)

Sorry I am not familiar with Javascript, where/what kind of print statements should I add, and how do I see their output when the extension is running?

Edit: so I figured out that adding print(this._player._trackCoverUrl); on line 36 outputs a correct URL when I view the log in journalctl /usr/bin/gnome-shell -f -o cat, so I'm not sure what is going wrong.

Could it be that the URL is somehow not being applied to GNOME shell?

[wjt]

Sorry, I don't have the cycles to help here. Perhaps https://gjs.guide/extensions/development/debugging.html and related pages might help.

[stuarthayhurst]

I've been doing some debugging of this, and found out that the Gio.File object created in MediaMessage.prototype._update() is invalid, and no I/O can be done on it.
Code used:

    enable() {
        if (this._originalUpdate === undefined) {
            let originalUpdate = this._originalUpdate = Mpris.MediaMessage.prototype["_update"];
            Mpris.MediaMessage.prototype["_update"] = function() {
                //if (this._player._trackCoverUrl) {

                originalUpdate.call(this);

                let tempIcon = this._player.trackCoverUrl;
                log("testing: tempIcon pre-replace = " + tempIcon);
                tempIcon = tempIcon.replace(BAD_URL_RX, GOOD_URL);
                log("testing: tempIcon post-replace = " + tempIcon);

                if (tempIcon) {
                    let file = Gio.File.new_for_uri(tempIcon);
                    log(file.query_exists(null));
                    this._icon.gicon = new Gio.FileIcon({ file });
                    this._icon.remove_style_class_name('fallback');
                } else {
                    log('WARNING: USING FALLBACK ICON');
                    this._icon.icon_name = 'audio-x-generic-symbolic';
                    this._icon.add_style_class_name('fallback');
                }


                //log(this._player.trackCoverUrl)
                //this._player.trackCoverUrl = this._player.trackCoverUrl.replace(BAD_URL_RX, GOOD_URL);
                  //this._player._trackCoverUrl = this._player._trackCoverUrl.replace(BAD_URL_RX, GOOD_URL);
                //}

                //originalUpdate.call(this);
                //Mpris.MprisPlayer.prototype.emit('show');
            }
        }
    }

And the output:

testing: tempIcon pre-replace = https://open.spotify.com/image/ab67616d00001e02e626d8740c283d5aaed3141c
testing: tempIcon post-replace = https://i.scdn.co/image/ab67616d00001e02e626d8740c283d5aaed3141c
false

And according to the Gio docs, false indicates that the Gio.File object is invalid.

[stuarthayhurst]

Running setcap -r /usr/bin/gnome-shell as root fixed this, @Cubevoid, are you able to test?

[Cubevoid]

Running setcap -r /usr/bin/gnome-shell as root fixed this, @Cubevoid, are you able to test?

Yes, it worked perfectly! Is this a permanent fix or would I have to run this every time I login?

[stuarthayhurst]

I'm fairly sure it's permanent. Fixing this extension side isn't really feasible by the looks of things, as it's an issue to do with gnome-shell and mutter.

[stuarthayhurst]

Alternatively, it may be possible to download the file temporarily and set the album art using that. If not, the command-line fix could be documented instead, until it's fixed upstream.

[Cubevoid]

Alternatively, it may be possible to download the file temporarily and set the album art using that. If not, the command-line fix could be documented instead, until it's fixed upstream.

Yeah I think that's actually what Firefox does, it puts the album art in a temp folder.

[stuarthayhurst]

I think I've got it working, but I've got to do cleanup and make a fresh VM for testing
EDIT: Never mind, my attempt ran into the same issue as before. I'll try again tommorow, hopefully with more luck.

[stuarthayhurst]

Okay I have some code that works for this without the shell command to fix it. However, it's very slow and the album art takes a while to load:

    enable() {
        if (this._originalUpdate === undefined) {
            let originalUpdate = this._originalUpdate = Mpris.MediaMessage.prototype["_update"];
            Mpris.MediaMessage.prototype["_update"] = function() {

                if (this._player._trackCoverUrl) {

                    originalUpdate.call(this);

                    if (this._player._trackCoverUrl) {
                        this._player._trackCoverUrl = this._player._trackCoverUrl.replace(BAD_URL_RX, GOOD_URL);
                        log('Cover url: ' + this._player._trackCoverUrl); //DEBUG

                        Gtk.init(null);

                        let session = new Soup.Session();
                        let url = this._player._trackCoverUrl;
                        let message = Soup.Message.new_from_uri("GET", new Soup.URI(url));
                        let file = Gio.File.new_tmp(null)[0];

                        session.queue_message(
                            message,
                            (sess, msg) => {
                                let outstream = file.replace(null, false, Gio.FileCreateFlags.NONE, null);
                                outstream.write_bytes(
                                    msg.response_body.flatten().get_as_bytes(),
                                    null)
                                Gtk.main_quit();
                            }
                        )

                        Gtk.main();

                        log(file.query_exists(null)); //DEBUG

                        this._icon.gicon = new Gio.FileIcon({ file });
                        this._icon.remove_style_class_name('fallback');
                    } else {
                        this._icon.icon_name = 'audio-x-generic-symbolic';
                        this._icon.add_style_class_name('fallback');
                    }
                }
            }
        }
    }

I know the code is messy, it's for debug :)

[stuarthayhurst]

To be honest, this issue isn't an issue with the extension, rather GNOME Shell instead. @wjt I can submit a PR with some code that fixes it extension side, however the album art takes a while to show up and update for some reason I can't figure out, if you want.

EDIT: This work-around code is so buggy I really wouldn't go with that. I think the best approach is probably to document the command-line fix and add it to the extension's description to avoid future bug-reports.

[stuarthayhurst]

I'm closing this as a workaround is documented, and a code work around is a little too messy for my liking. If this becomes an issue again, I can reopen this or feel free to submit another issue.