Blank Grey Screen

[trainzkid]

When the application is started (via spotify-launcher at the terminal), a grey screen opens but nothing displays on it. If I close it (via i3 WM's $mod+shift+Q), the grey screen goes away, but the app continues to stay alive in the background as a zombie (verified with ps -eF --sort=-pcpu|grep spotify) until killed (via pkill -9 spotify or kill -9 $PID). Here is the log output from the terminal. There isn't a directory at /home/$USER/.config/spotify-launcher/, and the config file at /etc/spotify-launcher.conf appears default ([spotify] header with a bunch of comments).

The application was installed from the AUR via paru. I'm successfully using spotify (also from the AUR) in the meantime. EDIT: I lied, the newest version of spotify from the AUR gives me the same behavior, but an older version of spotify (version 1:1.1.84.716-2) seems to work fine. Here is the log from the successful run of the older version.

ENV:

spotify-launcher 0.5.1-2
linux-zen 6.5.3.zen1-1
alsa-lib 1.2.10-2
at-spi2-core 2.48.4-1
desktop-file-utils 0.26-2
gtk3 1:3.24.38-1
libayatana-appindicator 0.5.92-2
libcurl-gnutls 8.3.0-1
libsm 1.2.4-1
libxss 1.2.4-1
nss 3.93-1
openssl 3.1.2-1
sequoia-sqv 1.1.0-1
zenity 3.44.2-1

Hopefully, it's something obvious/simple! Lemme know if there's anything else you need to further troubleshoot.

[kpcyrd]

The output looks similar to what I get, except those two lines:

(spotify:4378): libayatana-appindicator-WARNING **: 03:22:12.914: Unable to get the session bus: Unknown or unsupported transport “disabled” for address “disabled:”

(spotify:4378): LIBDBUSMENU-GLIB-WARNING **: 03:22:12.914: Unable to get session bus: Unknown or unsupported transport “disabled” for address “disabled:”

There might be an issue with your dbus setup. Everything is working fine for me on fully upgraded Arch Linux with gnome, you unfortunately need to mimic the environment spotify expects (though it can be difficult to determine which part it's not happy with).

On the zombie I can't say much without seeing the process tree.

[trainzkid]

Not sure what's going wrong on my system, but I did get it working again thankfully!

For anyone else who runs into similar issues, I loosely followed this and this.

Both mention that applications that utilize the system's DBUS will try to access it via the value of system variable $DBUS_SESSION_BUS_ADDRESS. If this variable is blank for some reason, apparently newer versions of spotify suicide out. You can manually set it (via export DBUS_SESSION_BUS_ADDRESS="/run/user/$UID/bus", where $UID is your user's UID, assuming there is indeed a bus file in that directory, and spotify may open but still refuse to play, I'm guessing because it can't communicate with your sound daemon, such as pulseaudio or whatever), or, according to this, you can change the line in your .xinitrc or .profile (or wherever you start your window manager/desktop environment) from exec $WM to dbus-launch --exit-with-session $WM, where $WM is your window manager/desktop environment.

If you choose to use dbus-launch, the $DBUS_SESSION_BUS_ADDRESS will point to a location in /tmp/dbus-*. I'm not even remotely sure why this works (including sound actually playing!), but it does on my system so I'm happy.

I initially thought maybe this was an issue with i3, that other WMs/DEs automatically set that variable on their own after being started, since the dbus-launch docs imply some distros are already configured to run the dbus-launch command on their own, but I don't believe this is actually the issue, as I was able to run spotify successfully from my Arch-based server across X11 forwarding (which also happens to have plasma running in the background, possibly explaining why this worked), AND from a fresh Arch VM I spun up (thanks to Arch's provided VM images/virtual drives) with i3 configured to run.

In the future, I'll do a fresh install of this system and this will hopefully eradicate this issue for me entirely.