Flatpak Spotify Client not starting

Since upgrading to Leap 15.0 I’ve been having a bit of trouble with Spotify client (installed as flatpak). Sometimes, and I can’t really tell when it is happening specifically, Spotify client won’t start. Here is konsole output when it starts successfully:

filip@norm07:~> flatpak run com.spotify.Client
Could not determine display scale factor, running with default.
/app/extra/bin/spotify: /app/lib/libcurl-gnutls.so.4: no version information available (required by /app/extra/bin/spotify)
Gtk-Message: Failed to load module "canberra-gtk-module"
/app/extra/share/spotify/spotify: /app/lib/libcurl-gnutls.so.4: no version information available (required by /app/extra/share/spotify/spotify)
/proc/self/exe: /app/lib/libcurl-gnutls.so.4: no version information available (required by /proc/self/exe)
Fontconfig warning: "/etc/fonts/fonts.conf", line 5: unknown element "its:rules"
**and a lot of other fontconfig warnings and errors which doesn't really matter**

And here’s output when it won’t start

filip@norm07:~> flatpak run com.spotify.Client
No protocol specified
Could not determine display scale factor, running with default.
/app/extra/bin/spotify: /app/lib/libcurl-gnutls.so.4: no version information available (required by /app/extra/bin/spotify)
Gtk-Message: Failed to load module "canberra-gtk-module"
No protocol specified

(spotify:5): Gtk-WARNING **: cannot open display: :99.0
Traceback (most recent call last):
  File "/app/bin/spotify", line 18, in <module>
  File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command ''/app/extra/bin/spotify']' returned non-zero exit status 1

My current workaround for this issue is to reboot and start Spotify as soon as I log in.

Also, out of curiosity, I checked if I can start openTTD (also installed with flatpak) when the problem with Spotify occurs and it says:

Error: Couldn't find any suitable video driver

Ok, as I mentioned before it seems like it is a problem with all flatpak apps. I’m currently using two flatpak apps - Spotify and openTTD and when one of them wouldn’t start then I’m can be sure the other one can’t start too.

I can’t find any help online. I’m pretty sure the key clue is a message

Gtk-WARNING **: cannot open display: :99.0

As I said before, there is no problem if I start those apps shortly after login. But on the other hand my dad (who run more or less on the same configuration) got Spotify in autostart and sometimes it won’t start even there.

I also just noticed that it may be related to NetworkManager or something else what is managing network connections.

When I reboot my laptop and start spotify before WiFi connection is established, it would start but if I wait for WiFi connection to establish it won’t start and I would get those errors which I already posted in first post.

Also, may I ask to change the title of the thread to Flatpak apps not starting? It would be more accurate.

I’ve found 2 workarounds (unfortunately both works only until reboot):

  • run xhost +
  • go to Yasts Network Settings and set a valid hostname (everytime I get in there it is set to localhost without any domain name)

Regarding the second workaround I noticed that output of **echo $XAUTHLOCALHOSTNAME **and hostname commands are different (before setting a hostname in Network Settings):

filip@NORM07:~> hostname

For me it qualifies as a bug. Should I report it?

From what you’re posting, it appears to be a bug in the Flatpak platform, so you should submit a bug to https://bugzilla.opensuse.org.

Be sure to include everything you find in detail, if you’re posting everything you’ve found in this thread you can just include the URL to this Forum thread in your bug report.

Your description sounds like it’s related to passing a correct DisplayID.
I’m not so sure that you might also have a separate networking issue, IMO what you’ve posted so far doesn’t provide enough evidence yet. And, I can speculate that the reason why your Spotify might work if you start it before you have a working network connection is because without a network connection you can’t query a DNS server for name resolution… But going down that path isn’t something I’d want to do without a lot more info and might not be necessary for your immediate needs.

As for your machine’s hostname, for some apps… Yes, it’s very important to have it set correctly so that it’s consistent with what is in the application (assuming the app uses hostnames).

You should know that there are typically and minimally <two> places you need to set your hostname settings…

  • In Yast > Network Settings > Hostname tab
    IIRC this sets $HOSTNAME on your machine which is typically used for <internal> hostname identification and is the <preferred> name when broadcasting to other machines.
  • In /etc/hosts
    This is used for hostname networking lookups

So, why both for local name resolution?
It depends on how the app does its name lookups… If it knows how to return $HOSTNAME directly, then that would be what is used… But many apps which already use networking connections will simply do a name lookup using networking methods, and then the /etc/hosts file is read.

There is a third possible setting I rarely see used, $HOSTS
You can set that if you wish but I’ve rarely seen that used.


For me it doesn’t seem like a bug in Flatpak as I never had this issue in Leap 42.3 and I tried two different versions of flatpak on Leap 15 (0.10.4 and 0.11.7). I think it may be related to wayland being available (but not used by me) in Leap 15.0. Spotify’s error suggest that it can’t connect to X server and as I wrote before it seems to be true as just changing a hostname in Network Settings or disabling X access control (with xhost +) solves the problem.

Before changing hostname in Network Settings I get this outputs:

filip@NORM07:~> hostname

And after changing the hostname I get:

filip@NORM07:~> hostname

I already described this issue on Flatpaks GitHub anyway and also replied to other bug report (1024652) which seems to describe the problem with hostnames being changed after establishing a network connection.

I got it. I found the answer in bug 966671. All I have to do is to change my hostname with hostnamectl:

hostnamectl --static set-hostname NORM07

Not sure if it works permanently (when I change a network) but it survived a reboot.

For me it seems like a problem with setting the hostname in Yast