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.

[perlsite]

Yes, the Xft is for the font settings and makes sense to use only the scaling-factor for Gnome, but for Unity I don't have any other suggestions different that Xft.dpi
For me, the best solution is an additional setting for the scale factor/zoom which is more user friendly than using command line option.

[corsseir]

When we get access to public beta version?

[darilbananapeal]

Howdy Linux folk,

I see you're getting regular replies from a moderator here. They don't seem to want to answer windows problems, so I thought I'd chime in here and see if this Nick fellow has any advice for the crippled masses currently using 1.x on their desktops.

Nik, you wrote this yesterday: 

"we understand that some users might not want to update to the 1.x client right away."

After perusing the release notes comments for desktop version 1.x, would you agree that those of us on windows also don't appreciate being your beta guinea pigs? Why do the Linux folks get a heads up about the upcomming beta, while the windows folks get auto-downloaded several times in the last month? .... 1.01 was first now we're on 1.04. Horendous de-featuring aside,  i still hear stories of broken html on your "desktop" app (clearly bug territory, that goes unanswered...no nikreiman to reply in the windows release notes)

So what do you think? Will the Linux customers be tortured like this with destroyed functionality and forced updates or will you be more thoughtful towards their needs? Why isn't there a friendly Nikreiman answering the 100s of pages of comments in the windows sections??

Hope to hear from you. Noone else seeems to care about users.. Nice  to see some back and forth in this thread. Hope it continues.

thanks for your time

[nikreiman]

---

@corsseir wrote:

When we get access to public beta version?

---

Soon. 🙂 I don't have an exact date, but I'd say it's fair to assume that we'll have it out by the end of the month. We still have some apt-related distribution problems to solve.

[nikreiman]

---

@darilbananapeal wrote:

Howdy Linux folk,

I see you're getting regular replies from a moderator here. They don't seem to want to answer windows problems, so I thought I'd chime in here and see if this Nick fellow has any advice for the crippled masses currently using 1.x on their desktops.

Nik, you wrote this yesterday: 

"we understand that some users might not want to update to the 1.x client right away."

After perusing the release notes comments for desktop version 1.x, would you agree that those of us on windows also don't appreciate being your beta guinea pigs? Why do the Linux folks get a heads up about the upcomming beta, while the windows folks get auto-downloaded several times in the last month? .... 1.01 was first now we're on 1.04. Horendous de-featuring aside,  i still hear stories of broken html on your "desktop" app (clearly bug territory, that goes unanswered...no nikreiman to reply in the windows release notes)

So what do you think? Will the Linux customers be tortured like this with destroyed functionality and forced updates or will you be more thoughtful towards their needs? Why isn't there a friendly Nikreiman answering the 100s of pages of comments in the windows sections??

Hope to hear from you. Noone else seeems to care about users.. Nice  to see some back and forth in this thread. Hope it continues.

thanks for your time

---

I'm sorry that you feel that the moderators are not answering Windows-related questions. I've been active in this and similar threads since I'm a Linux-based developer at the company. But you're right; the Windows/Mac users deserve answers to their questions and concerns, and I will raise this point in the proper channels internally at Spotify.

[perlsite]

---

@nikreiman wrote:

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.

---

I was wandering about xrandr and respective libxrandr. You'll have some dependencies from the X11 (see libxrandr-dev and libxrandr2 ).
Technically, everything you need, can be obtained from the xrandr! I was playing around with the xrandr binary and I was surpised to see the following result:

$ xrandr 
Screen 0: minimum 8 x 8, current 5760 x 2160, maximum 32767 x 32767
eDP1 connected 1920x1080+3840+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080     60.10*+
   1400x1050     59.98  
   1280x1024     60.02  
   1280x960      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
DP1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   3840x2160     60.00*+
   2560x1440     59.95  
   2048x1280     59.99  
   1920x1200     59.88  
   1920x1080     60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1600x900      59.98  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

connected primary means this is the primary screen (my 4k monitor connected to the DisplayPort). The *+ is obviously the current screen resolution. Even better, 527mm x 296mm is the physical size of the screen. From here I was able easy to calculate (3840 / 527 * 25.4) current DPI (185) for my monitor.

When I open the laptop's lid and temporary turn the external monitor off I see the following output:

$ xrandr 
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm
   1920x1080     60.10*+
   1400x1050     59.98  
   1280x1024     60.02  
   1280x960      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

I get around 142 dpi for my full hd laptop's panel which is also correct.

I think we can safely use those numbers to properly calculate the required zoom level to match the functionality available for Mac.

What do you think, is it feasible?

[perlsite]

On Wayland (with Gnome), we have a bit mixed results, when I run the xrandr:
For external, 4k display:

$ xrandr 
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
XWAYLAND0 connected 3840x2160+0+0 530mm x 300mm
   3840x2160@0.1Hz   0.05*+

For the internal full hd laptop's panel (external monitor was turned off):

$ xrandr 
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 8192 x 8192
XWAYLAND0 connected 3840x2160+0+0 530mm x 300mm
   3840x2160@0.1Hz   0.05*+
XWAYLAND1 connected 1920x1080+0+0 340mm x 190mm
   1920x1080@0.1Hz   0.00*+

Looks promising even on Wayland, although it will require some guessing.

[novembernebel]

Hello,

I just reinstalled my computer with Kubuntu 14.04 LTS 32 bit up to date, and I tryed to get my favourite music player with the usual procedure (add spotify repo, update, apt-get install spotify-client) and I always get this error :

sudo apt-get install spotify-client
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet spotify-client

("E: Unable to find package spotify-client")

When I try, with another computer, to just download the .deb, I get this :

sudo apt-get download spotify-client
E: Impossible de trouver une source de téléchargement de la version « 1:0.9.4.183.g644e24e.428-1 » de « spotify-client:i386 »

("E: Impossible to find a download source of version "1:0.9.4.183.g644e24e.428-1" of "spotify-client:i386"

So I tryed withe version 0.9.17, same thing :

sudo apt-get download spotify-client
E: Impossible de trouver une source de téléchargement de la version « 1:0.9.4.183.g644e24e.428-1 » de « spotify-client:i386 »

 Any idea what's going on, and if I should wait for a solution?

[sleeksorrow]

I'd like to use this place to report another bug in the unofficial 1.0.1 beta on linux, to consider that if it's unknown yet.

The search function cannot find songs in my local files.

I have songs in my local files that are not available on Spotify. I can see them in the Local Files" tab and I can play them just fine. But I cannot find them when using the search tab on the top left. This returns with "No results found". This is annoying, because my local files list is quite heavy and often I don't know by heart what I have and what not.

[user-removed]

This new Spotify version seems to be a little bit slowly to play music. I have a 10 mb/s connection and when I click on something it doesn’t play instantaneous like in the previously version and sometimes I have to wait several seconds to load or keeps stoping. Maybe is because the peer to peer system is being shut down and the servers seems to be in Europe (I'm in Brazil). But there's a way to make it work faster?

I look at Youtube and Torrent, they work correctly and use the full connection. I not sure what might cause this.

Spotify 1.0.1.1062.gaa7a606c

[falkevinz]

@ nikereiman

Hi,

I would like to notice a "small bug" to you concerning spotify linux version 0.9.17.1 on Debian 8 stable "Jessie"

The paquet will not install because it claims an non existing file "libgcrypt.so.11" on 64 bits version an 32 bit too I think

spotify: error while loading shared libraries: libgcrypt.so.11: cannot open shared object file: No such file or directory

the issue can be solved installing the libgcrypt11 paquet from somewhereelse * and reinstalling BUT that's a bad solution.

from here

ftp://ftp.debian.org/debian/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-5+deb7u3_amd64.deb

Could you make a correcting paquet or let notice it to a developper ? I would be nice from you

[renebarbosa]

What about non-Debian users? I am migrating to Fedora and the installing of Spotify in such distribution is really painfull. I don't want to install unverified 3rdParty repos (such as negativo17.org thing) to get it working.

[jukkis]

One vote for 32-bit version, even the old version back to the repository. Currently can't install Spotify on a newly installed 32-bit Lubuntu.

[novembernebel]

---

@jukkis wrote:

One vote for 32-bit version, even the old version back to the repository. Currently can't install Spotify on a newly installed 32-bit Lubuntu.

---

Same for me with Kubuntu 14.10 32-bit...

[nikreiman]

---

@novembernebel wrote:

---

@jukkis wrote:

One vote for 32-bit version, even the old version back to the repository. Currently can't install Spotify on a newly installed 32-bit Lubuntu.

---

Same for me with Kubuntu 14.10 32-bit...

---

We're aware of the fact that the 32-bit package for 0.9.17 has disappeared, and are working to restore it. Thanks for the report!

[Tiempo]

Why don't you write in the download/installation page that currently Linux version is not available? This will spare x persons' time trying to understand the problem. Give me my wasted hour back. 😛

[Nico751]

---

@renebarbosa wrote:

What about non-Debian users? I am migrating to Fedora and the installing of Spotify in such distribution is really painfull. I don't want to install unverified 3rdParty repos (such as negativo17.org thing) to get it working.

---

Maybe following this will help you: Installing Spotify on Fedora Linux

BUT do NOT enter the first command to install the repo, use these instead:

su -lc 'yum install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm'
su -lc 'yum install --nogpgcheck http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'

Please tell us if it works so people can also follow this guide. (I can't tell, I don't use Fedora)

Also keep in mind that since the 32-bit deb package has (temporarily?) disappeared from the Spotify repository, it may not work on a 32-bit Fedora. You'll probably have to wait for it to come back. 😕

NB: RPM Fusion is an almost official (highly recommanded) repo.

Good luck!

[dankcushions]

---

@Tiempo wrote:

Why don't you write in the download/installation page that currently Linux version is not available? This will spare x persons' time trying to understand the problem. Give me my wasted hour back. 😛

---

this! took a load of googling to find this thread and find out that there's just no 32-bit version. a lot of folk are running linux on older machines, so would appreciate the 32-bit older version coming back, or at least a message on the download page until that time! 🙂

[olejon]

---

@renebarbosa wrote:

What about non-Debian users? I am migrating to Fedora and the installing of Spotify in such distribution is really painfull. I don't want to install unverified 3rdParty repos (such as negativo17.org thing) to get it working.

---

@renebarbosa I managed to get Spotify up and running on Fedora 22 (not yet released). Had to add this repo:

http://negativo17.org/spotify-client/

But due to the change from yum to dnf I had to use another way. Also when trying to install Spotify it will not work because of missing libraries. But I managed to find working ones from RPM Fusion, from the Fedora 21 repo (without actually installing the repo, because it didn't work for me, but I hunted down the RPMs manually from the free and non-free browsing feature in RPM Fusion and install them in the right order, or you'll get errors due to other missing libraries.

So it's possible, yes. If you run Fedora 21 it should be pretty easy as you can easily install the two RPM Fusion repos, and the dependencies will resolve themselves. But Fedora 22 is right around the corner and GNOME 3.16 is desirable. At least for me. I just tested in a VM though.