Spotify 0.9.17 for GNU/Linux (and the upcoming 1.x beta!)

[nikreiman]

On 24 March 2015, we rolled out an update to the desktop client for GNU/Linux. For installation instructions, see:

https://www.spotify.com/download/previews/

The version of the client is 0.9.17, and it will be the final 0.9.x client released for this platform. It has been a long time since the previous release (with the prior version being 0.9.11), and for those interested in the release notes, they will be identical to those for other desktop platforms for the versions 0.9.12-17, with the addition of the following platform-specific fixes:

- The machine's hostname is shown to other devices from Spotify Connect

- A 512px icon is used for the taskbar and menubar (unity integration)

We have decided to make a final release of 0.9.x desktop so that our users can pin this package if desired. Also we will make a separate package for the 0.9.17 release so that it is easier to find in the apt repository in case users need to revert to the prior version.

*EDIT*: The 0.9.17 package is now available, it is called spotify-client-0.9.17. If you don't want to receive the 1.x version, you can install this package instead (note that it both provides and conflicts with the spotify-client package).

Going forward, the official Linux beta will be released very soon! There are already some unofficial beta links floating around the forum, but so far we have not published a deb package to our official apt servers yet. We have been very busy getting 1.x out the door and sadly have not had as much time to devote to the GNU/Linux releases as we would like. Also, it has been unfortunate that we have not been better at keeping up with releases for this platform in general, but we have taken some steps to improve this for future releases.

Specifically, this means:

- We will be releasing a regular tarball file alongside our debian package for the benefit of non-debian users

- Spotify client releases will be made available for GNU/Linux users at the same time as users on other platforms

- We will also make a public `testing` apt repository to house unstable beta builds for testing

- However, we do not have a 32-bit version of the client available now. This is difficult for us to do for a number of reasons, but we will consider doing this if there is enough demand from the userbase.

[nikreiman]

---

@olejon wrote:

---

@user-removed wrote:

As Linux users we have to face that we won't get the same priority Windows and Mac users receive. In some cases, develop a software for Linux is simple not profitable. At Opera Software they already said that their Linux version is made for other reasons than money because the Linux market is simply too small compared to Windows and Mac. I believe it's the same case with the Spotify client. Even when you (like me) pay for Premium.

---

Read the first post. Linux versions will be released at the same time as Windows and OS X versions, and with this change to cross-platform technology, from QT + Chromium Embedded to only Chromium Embedded, it shouldn't be more difficult than maintaining the small differences between Windows and OS X that are still native (maybe even easier), like audio playback, local files and playback. Not to mention Linux with its repository approach makes it very easy to make sure all users use the same version.

---

I should clarify my points here, since in retrospect they are contradicting each other. 🙂

- Yes, we will have regular linux releases at (roughly) the same frequency as Mac/Win clients, since we are investing in automating the infrastructure to do this, however

- Linux users are still a minority and thus we have fewer allocated resources for working on the Linux client. So the actual work that needs to be done to automate releases might take awhile. But we are getting closer to our goal here!

- Also Linux-specific features (for example, menubar applet integration, system menus, etc) that are missing in the 1.x client might take longer to re-appear in the new client. We just don't have as much time to work on these features as we'd like, unfortunately.

[nikreiman]

---

@olejon wrote:

---

@user-removed wrote:

As Linux users we have to face that we won't get the same priority Windows and Mac users receive. In some cases, develop a software for Linux is simple not profitable. At Opera Software they already said that their Linux version is made for other reasons than money because the Linux market is simply too small compared to Windows and Mac. I believe it's the same case with the Spotify client. Even when you (like me) pay for Premium.

---

Read the first post. Linux versions will be released at the same time as Windows and OS X versions, and with this change to cross-platform technology, from QT + Chromium Embedded to only Chromium Embedded, it shouldn't be more difficult than maintaining the small differences between Windows and OS X that are still native (maybe even easier), like audio playback, local files and playback. Not to mention Linux with its repository approach makes it very easy to make sure all users use the same version.

---

I should clarify my points here, since in retrospect they are contradicting each other. 🙂

- Yes, we will have regular linux releases at (roughly) the same frequency as Mac/Win clients, since we are investing in automating the infrastructure to do this, however

- Linux users are still a minority and thus we have fewer allocated resources for working on the Linux client. So the actual work that needs to be done to automate releases might take awhile. But we are getting closer to our goal here!

- Also Linux-specific features (for example, menubar applet integration, system menus, etc) that are missing in the 1.x client might take longer to re-appear in the new client. We just don't have as much time to work on these features as we'd like, unfortunately.

[nikreiman]

---

@olejon wrote:

---

@user-removed wrote:

As Linux users we have to face that we won't get the same priority Windows and Mac users receive. In some cases, develop a software for Linux is simple not profitable. At Opera Software they already said that their Linux version is made for other reasons than money because the Linux market is simply too small compared to Windows and Mac. I believe it's the same case with the Spotify client. Even when you (like me) pay for Premium.

---

@Rômulo Read the first post. Linux versions will be released at the same time as Windows and OS X versions, and with this change to cross-platform technology, from QT + Chromium Embedded to only Chromium Embedded, it shouldn't be more difficult than maintaining the small differences between Windows and OS X that are still native (maybe even easier), like audio playback, local files, sync and Spotify Connect. Not to mention Linux with its repository approach makes it very easy to make sure all users use the same version.

I seriously hope "Preview" will be removed when the final v 1.0 hits.

@nikreiman The page title of this page should seriously be changed. Remove Wine from it! There is no longer any mention of it on the page. And while you're on it, It shouldn't say "Debian" above the installation instructions. You Linux devs have many times said that Ubuntu is the only really supported flavor, and there are many more Debian users with problems here. Many noobs don't know that Debian basically equals Ubuntu (most used distro) when it comes to package system, and may be confused when Ubuntu is not mentioned.

And make it easier. Just like Windows users downloading an .exe and double-click it to install Spotify, instead of providing commands that are not noob-friendly, link directly to the latest .deb package. Users will only then have to double-click it to install it, and then in the .deb package you add the repository in the "postinst" script. It'll be even easier to install Spotify on Linux than on Windows and OS X, because no click Next > Next > Next etc., or drag and drop into Applications on OS X.

Sure, you can provide command line instructions for experienced users who want full control.

---

Yeah, I know... that page is really outdated. We want to redo it soon, most notably to add instructions for non-debian users (ie, with the distribution tarballs). Expect an update to the page sometime after we start doing regular linux releases.

Oh, yeah, and another thing, "Spotify Preview" is gone. 🙂 The app shows "Spotify" or "Spotify Premium" after you login, and then is simply replaced with the currently playing song after you start playing something.

[olejon]

---

@nikreiman wrote:

Yeah, I know... that page is really outdated. We want to redo it soon, most notably to add instructions for non-debian users (ie, with the distribution tarballs). Expect an update to the page sometime after we start doing regular linux releases.

Oh, yeah, and another thing, "Spotify Preview" is gone. 🙂 The app shows "Spotify" or "Spotify Premium" after you login, and then is simply replaced with the currently playing song after you start playing something.

---

@nikreiman Good to hear.

I assume you are referring to the beta version. Mine 0.9.17 still says Spotify Premium - Linux Preview in the app's title.

BTW: I like you being to active here  . Never has there been so much activity from a Linux dev. Very interesting getting insight into your inner workings for us geeks. Usually very difficult getting in touch with you Linux devs. I think I have talked to you on IRC, but that's more for devs, which I am. Keep it up  .

Regarding adding back features to v 1.0, I hope you prioritize D-Bus (which enables Unity sound menu integration, and many scripts out there depend on this).

[nikreiman]

---

@olejon wrote:

---

@nikreiman wrote:

Yeah, I know... that page is really outdated. We want to redo it soon, most notably to add instructions for non-debian users (ie, with the distribution tarballs). Expect an update to the page sometime after we start doing regular linux releases.

Oh, yeah, and another thing, "Spotify Preview" is gone. 🙂 The app shows "Spotify" or "Spotify Premium" after you login, and then is simply replaced with the currently playing song after you start playing something.

---

@nikreiman Good to hear.

I assume you are referring to the beta version. Mine 0.9.17 still says Spotify Premium - Linux Preview in the app's title.

BTW: I like you being to active here  . Never has there been so much activity from a Linux dev. Very interesting getting insight into your inner workings for us geeks. Usually very difficult getting in touch with you Linux devs. I think I have talked to you on IRC, but that's more for devs, which I am. Keep it up  .

Regarding adding back features to v 1.0, I hope you prioritize D-Bus (which enables Unity sound menu integration, and many scripts out there depend on this).

---

Regarding the "Spotify Preview" in the window title, yes, that change is only in the 1.x versions.

We have dbus support in the 1.x client but I am not 100% sure that it supports all of the bells and whistles as the previous client. Our dbus implementation has changed significantly in the 1.x client since we are no longer using QT in the client and sadly cannot leverage stuff like this which was present in the QT framework.

[user-removed]

I read the first post but that does not change the fact that Linux is still not a priority. Just take a look and see that Windows and Mac already have this version, while we are still behind. The developers do what they can and I appreciate that, but unfortunately the heads of Spotify just doesn’t care about Linux.

[perlsite]

I'm using Spotify version 1.0.1.1062.gaa7a606c for Linux.

The problem I face is the lack of 4K / HiDPI support which makes the texts extremely small and unreadble (4 times smaller than "normal") on 4k monitor like Dell P2415Q.

Looking at the attachment, the normal size text is the "Spotify Premium" title, which is automatically drew by the window manager.

Since the Spotify is build on Chromium and the Chromium already supports HiDPI (see https://wiki.archlinux.org/index.php/HiDPI ), can you please add an option for HiDPI support or detect it automatically!?

Thanks

[renebarbosa]

Okay. Where  I can find that beta version package?

[olejon]

@renebarbosa Deb package link at the bottom here:

https://aur.archlinux.org/packages/spotify-beta

Wouldn't recommend it at all, though.

[kigurai]

Considering "Linux specific features", I think it would be *awesome* if the Spotify client could implement the interface necessary to show playback controls on the GNOME 3 lock screen. I am pretty sure it is a standard DBUS interface that needs to be implemented, so I guess other DE's would benefit as well.

[perlsite]

Second bug report, that affects Spotify version 1.0.1.1062.gaa7a606c for Linux:

I'm using Gnome 3 but I'm not sure whether the problem is the way AUR package (Arch Linux here) is generated/compiled or it is just a missing feature that was/is aviable in 0.9 version of Spotify.

The issue with Spotify 1.x and Gnome 3 is (presumably) the lack of WM_CLASS property (checked with xprop), which cause the application on the task/favorites to be displayed with "Unknown" icon (see the screenshot), which unfortunatelly doubles the icons on the tast manager. Normally, when you run Spotify from the favourites it doesn't duplicate the icon, so when you click on the icon, the currently running application is set on focus. Right now, clicking again on the Spotify icon will open second instance of the application.

Running Spotify 0.9 works as expected. It would be great if other linux users that are testing the 1.x version to report on this issue.

$ xprop 
WM_NAME(STRING) = "Spotify Premium"
_NET_WM_NAME(UTF8_STRING) = "Spotify Premium"
XdndProxy(WINDOW): window id # 0x2200002
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 74, 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		window gravity: Static
_NET_WM_PID(CARDINAL) = 1460
WM_LOCALE_NAME(STRING) = "en_AU.UTF-8"
WM_CLIENT_MACHINE(STRING) = "stoffle"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING

[nikreiman]

---

@perlsite wrote:

Second bug report, that affects Spotify version 1.0.1.1062.gaa7a606c for Linux:

I'm using Gnome 3 but I'm not sure whether the problem is the way AUR package (Arch Linux here) is generated/compiled or it is just a missing feature that was/is aviable in 0.9 version of Spotify.

The issue with Spotify 1.x and Gnome 3 is (presumably) the lack of WM_CLASS property (checked with xprop), which cause the application on the task/favorites to be displayed with "Unknown" icon (see the screenshot), which unfortunatelly doubles the icons on the tast manager. Normally, when you run Spotify from the favourites it doesn't duplicate the icon, so when you click on the icon, the currently running application is set on focus. Right now, clicking again on the Spotify icon will open second instance of the application.

Running Spotify 0.9 works as expected. It would be great if other linux users that are testing the 1.x version to report on this issue.

$ xprop 
WM_NAME(STRING) = "Spotify Premium"
_NET_WM_NAME(UTF8_STRING) = "Spotify Premium"
XdndProxy(WINDOW): window id # 0x2200002
_NET_WM_STATE(ATOM) = 
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 74, 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 0, 0
		window gravity: Static
_NET_WM_PID(CARDINAL) = 1460
WM_LOCALE_NAME(STRING) = "en_AU.UTF-8"
WM_CLIENT_MACHINE(STRING) = "stoffle"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING

---

Actually a fellow employee using a tiling window manager reported this issue as well. You'll be pleased to know that the WM_CLASS thing has been fixed and will be in the next beta release.

~$> xprop | grep WM_CLASS
WM_CLASS(STRING) = "spotify", "Spotify"

[olejon]

---

@kigurai wrote:

Considering "Linux specific features", I think it would be *awesome* if the Spotify client could implement the interface necessary to show playback controls on the GNOME 3 lock screen. I am pretty sure it is a standard DBUS interface that needs to be implemented, so I guess other DE's would benefit as well.

---

@kigurai I guess this is the standard MPRIS interface that is used by most popular music players on Linux. It is used by the Ubuntu sound menu for instance, but is not yet implemented in the Linux Beta that is unofficially available on the Internet. It should work with 0.9.17, though.

[olejon]

For new users - Fixes for Ubuntu 15.04:

• Fix bug that stops Spotify from opening
• Fix local files playback

These are previous posts in the community, and applies to version 0.9.x of the Spotify client.

Linux beta (NOT RECOMMENDED):

• Download deb package

Link gotten from AUR.

[nikreiman]

Quick update (which I also mentioned in an edit in the main post in this thread): we have released a separate package today for 0.9.17, called "spotify-client-0.9.17". It both provides and conflicts with "spotify-client" package, so if you want to have this package you will need to uninstall the spotify-client package first.

Going forward, we will probably make similar packages for future releases so that our Linux users have the ability to easily revert to an older release if necessary. Of course, we prefer that our users stick with the latest version of our software, which will continue to be published under the spotify-client package. Since the 1.x Linux client still is missing some features (and specific Linux-integration stuff) from the 0.9.x versions, we understand that some users might not want to update to the 1.x client right away.

[perlsite]

@nikreiman: thanks for the feedback.

Did you get a chance to look into the HiDPI report (previous page)? That is really the bigest issue since I'm now using 4k display, which makes it really hard to use the Spotify client.

Right now I'm using Chromium Dev Version 44.0.2383.0 (64-bit) which is looking great - everything looks ok in 4k so far. I guess for development you are using an older version of Chromium and it will take some time to merge them.

The original bug report in the Chromium project: https://code.google.com/p/chromium/issues/detail?id=143619 gives some clues what have been done there and how to active it.
They basically offers enable_hidpi=1 configuration flag and some command line start up argument --force-device-scale-factor=2 that also might help. In the current Chromium Dev version I didn't pass any arguments to activate the HiDPI mode.

[nikreiman]

---

@perlsite wrote:

@nikreiman: thanks for the feedback.

Did you get a chance to look into the HiDPI report (previous page)? That is really the bigest issue since I'm now using 4k display, which makes it really hard to use the Spotify client.

Right now I'm using Chromium Dev Version 44.0.2383.0 (64-bit) which is looking great - everything looks ok in 4k so far. I guess for development you are using an older version of Chromium and it will take some time to merge them.

The original bug report in the Chromium project: https://code.google.com/p/chromium/issues/detail?id=143619 gives some clues what have been done there and how to active it.
They basically offers enable_hidpi=1 configuration flag and some command line start up argument --force-device-scale-factor=2 that also might help. In the current Chromium Dev version I didn't pass any arguments to activate the HiDPI mode.

---

Ah yes, sorry, I meant to respond to your post but got caught up with the packaging stuff today. Anyways, the difficulty here is not so much telling chromium to use hidpi mode, but rather detecting it from the OS. If you know of a convenient API call (either via X11 or Gnome/GTK), please let me know and I will experiment around a bit with hidpi in the client.

But, even if there is no API to detect hidpi displays, there is another solution at your disposal. The 1.x client actually has a "zoom" feature, which is currently only accessible in the Mac/Windows clients. It basically implements Zoom just as in any web browser, and actually works quite well since the UI of the client has an adaptive layout. You can see it in action on those platforms in the "View" menu... and since the menu isn't yet finished in Linux, it's not available yet on that platform.

Zoom is a bit of a hack that was added in and it needs a bit of polish -- namely, to be made accessible outside of the application menu, and also persisted properly as a user setting -- but when that is done this would be a good option for super hi-res displays. Also, we use it sometimes internally for demoing Spotify on projectors. 🙂

[lczekaj]

---

@nikreiman wrote:

But, even if there is no API to detect hidpi displays, there is another solution at your disposal. The 1.x client actually has a "zoom" feature, which is currently only accessible in the Mac/Windows clients. It basically implements Zoom just as in any web browser, and actually works quite well since the UI of the client has an adaptive layout. You can see it in action on those platforms in the "View" menu... and since the menu isn't yet finished in Linux, it's not available yet on that platform.

---

Maybe you could just add Zoom as a command-line parameter for the time being?

Any way to scale Spotify's fonts on Linux is greatly appreciated!

[perlsite]

What I know about Gnome environment is that the HiDPI is enabled with

$ gsettings set org.gnome.desktop.interface scaling-factor 2

To check it:

$ gsettings get org.gnome.desktop.interface scaling-factor

Unfortunatelly I'm not aware of an API that can be used to query the gnome database (I guess there is one).

Additionally the following command can be used to detect HiDPI mode:

$ xrdb -query
Xft.dpi:	192
Xft.antialias:	1
Xft.hinting:	1
Xft.hintstyle:	hintmedium
Xft.rgba:	none

It should be 192 for hidpi mode.

The same command is reported to work just fine for Unity (i.e. to return 192 for the Xft.dpi) when the scaling factor is set again to 2 (as long as I remember you can do that via system's Display settings in Ubuntu).

Unfortunatelly I don't know how all this behaves when you set some non-native scale factor like 1.5. As long as I remember, Ubuntu's official support for HiDPI allows only natural (integer) numbers, like: 1, 2, 4.

However I'm perfectly happy with an extra HiDPI checkbox/select menu/slider in the Spotify's advanced settings section 🙂

[lczekaj]

---

@perlsite wrote:

Additionally the following command can be used to detect HiDPI mode:

$ xrdb -query
Xft.dpi:	192
Xft.antialias:	1
Xft.hinting:	1
Xft.hintstyle:	hintmedium
Xft.rgba:	none

It should be 192 for hidpi mode.

---

Please don't rely on this particular setting.

Even though I have scaling-factor set to 2 I also have font scaling set to 0.80 in Gnome Tweak Tool.

This is how the output of xrdb looks for me:

~  xrdb -query
Xft.antialias:	1
Xft.autohint:	1
Xft.dpi:	153.599609375
Xft.hinting:	1
Xft.hintstyle:	hintfull
Xft.lcdfilter:	lcddefault
Xft.rgba:	rgb