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.

[sleeksorrow]

---

@olejon wrote:
Sad we do not seem to get 32-bit support. With the new cross platform technologies under the hood I assumed it would be easier for you devs. I even thought ARM would be a possibility. That would be really cool for Raspberry Pi owners!

---

Well, since even this 1.0.1 version now was never released officially, I guess it's too early to give up hopes 😉 I'd love to run that on my Raspberry Pi or on the CuBox i4Pro that I have on my wishlist.

[nikreiman]

---

@olejon wrote:
Sad we do not seem to get 32-bit support. With the new cross platform technologies under the hood I assumed it would be easier for you devs. I even thought ARM would be a possibility. That would be really cool for Raspberry Pi owners!

---

The difficulty we have in supporting 32-bit machines is making a build for them. Internally, we only have 64-bit build machines, and so we would need to use a cross-compile toolchain to make a 32-bit build. Some of the tools that are involved in the build toolchain don't work in such an environment... I can't really go into greater detail, but it's at least worth mentioning that it was awhile since we tried making the 32-bit toolchain, and we will try it again now with newer versions of these tools and hopefully have a bit more luck. So as I said, a 32-bit client is not totally out of the question, but it might take us a bit of time to get it sorted out.

However, an ARM Linux client is going to be much harder for us to do. CEF (the framework that our app is built around) does not officially support ARM Linux (see http://cefbuilds.com), but apparently it is not impossible to build it on that architecture. However it seems that there are a lot of problems on this architecture (see https://code.google.com/p/chromium/wiki/LinuxChromiumArm), so until CEF is more stable there, I'd prefer to spend the time improving the 32/64-bit x86 builds. 🙂

[nikreiman · Accepted solution]

---

@Zer0CT wrote:

I have problem with libudev.

I'm using elementaryOS Luna (64bit) which is based on Ubuntu 12.04 LTS. This OS supports libudev.so.0 and there are no entry for libudev.so.1 in the repository.

The program don't start from the launcher and give error from terminal.

~$ spotify
spotify: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory

 I've found a workaround on some forum. 
That solution makes a link from libudev.so.0 to libudev.so.1
This seems to work everybody. However, I read that this solution is a dangerous and bad practise (I didn't find out why.)
This is the code for the linking:

# ln -s /lib/$(arch)-linux-gnu/libudev.so.0 ./libudev.so.1

 My questions:
Can you update the program to support libudev0? (elementaryOS Luna still have 2 years lifetime; eOS Freya supports libudev1, but it is considered unstable beta yet)
Why this linking considered to be dangerous? Will it need any special care if I do it?
Are there any other (safe, elegant) mode to solving this?

Anyway, thanks for the Linux support! I love that it get more and more attention from everywhere.
Note that I have only chosen Spotify in the first place a year ago because it has native Linux app. (You can copy-paste this sentence to your sales manager. 😄 😉 )

---

The libudev thing sucks, I know. However, the symlinking hack is only dangerous if you are using applications which depend on an incompatible ABI in the v1 of that library. For Spotify (which doesn't actually use any such APIs within libudev), it is safe.

In the near future, we will update the CEF version used in the Linux client, and the issue should be fixed there. So we will still require libudev as a package dependency, however we will be able to depend on libudev instead of libudev1 and just use whatever version the system has installed.

[nikreiman]

Also, regarding Spotify Connect functionality not working on the 0.9.17 client, we have identified the issue and will deploy a fix later this week for it. It's a server-side thing, so it won't require another cilent update for this to work. You should start to see Spotify Connect working on the 0.9.17 client (note -- only as a player, not a controller) within a few days.

[f_b]

It's really good to see that the Linux client is getting some attention. Great to hear that from v1.x new versions will be release along side with other platforms.

Any idea when v1.x becomes officially available? (beta for Linux, I assume?) From what I understand it's supposed to be easier to port across platforms, and since v1.x is out for Windows and Mac, can we expect it for Linux soon?

(As always, thanks to the devs for maintaining a Linux version.)

[Orphis]

May I ask what is your use-case for using a 32bit distribution and not 64bit one?

Intel 32bit Linux is slowly being phased out and with the current hardware, it makes much more sense to use 64bit in general.

As Nik said, there's a few issues we have to deal with in our build pipeline in order to produce a 32bit build. It's not impossible, but just currently much harder to do and our hands are already full with a lot of other things. Don't hold your breath, and please use the latest 32bit build meanwhile.

[muammar]

This does not work for me, because if I try to install their ffmpeg version then APT tries to remove many programs that depend on ffmpeg. I will download those libraries (or built them in my system with pbuilder), extract the *.so files and I will let you know.

Update: I downloaded the libraries, I placed the *.so files in the respective /opt/spotify/spotify-client and it does not work....

21:44:30.448 D [spirc_manager.cpp:710 ] GAIA: SpircManager::stpLoad, track=spotify:local:Porcupine+Tree:4+Chords+That+Made+a+Million:4+Chords+That+Made+a+Million:221, index=7377, position=0, paused=0
21:44:30.448 D [spirc_manager.cpp:1883 ] GAIA: SpircManager::becomeActiveDevice
21:44:30.453 I [sliding_window_prefetch_strategy.cpp:329] Prefetch: looks like new context - resetting window size to 1

[user-removed]

@nikreiman write us when 😉

[nikreiman]

---

@Erkan_Yılmaz wrote:

- 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.

I.
I guess then spotify (and my forum activity) won't be an option anymore 😞

- I can not use the web player, since it doesn't scrobble to last.fm (1).
- I will use my current 32-bit spotify (2) as long as possible and until the apps cease to exist (3).

II.

Is there anything we, as community, could do to help you guys keeping the 32bit version?

(1) https://community.spotify.com/t5/Help-Web-Player/web-player-not-scrobbling-to-last-fm/m-p/919767#M77...
(2) version 0.9.4.183.g644e24e0
(3) https://community.spotify.com/t5/Closed-Ideas/Keep-the-old-app-API-in-the-desktop-software-for-exist...

---

Well, sadly the Spotify apps definitely aren't coming back (but the most popular app, MusiXmatch, is now a full feature in the 1.x client), and a 32-bit Linux version is also not likely to be shipped soon. However, you will at least be pleased to hear that last.fm support is coming to the web player soon. 🙂

[Fred]

A web player with a full feature set is high in the wishlist for all of us diy:ers who like to build small mediacenters from our raspberries... but obvioiusly also for all of us with older hardware laying around running lightweight 32 bit linux distro's. Is MusiXmatch a feature in the web-player as well? (last time I used the webplayer it was brand new - would guess things have changed since)  😉 

[sbkg0002]

PLEASE, PLEASE, let there be a headless option! Spotify Premium, Connect, and a headless deamon on a Linux machine would be super!

[EXiDO]

As a linux user i feel very proud today  that the first thing i spent my march money on was on a Spotify Premium.

Keep up the good work on the liinux version of the spotify client! 🙂

[nikreiman]

Quick update regarding Spotify Connect on 0.9.17 client -- the backend team has decided to postpone the deployment that contains the fix for Linux users (because we had a big launch this week with Sony, and now it's Easter so they don't want to roll it out in case it breaks something). Should be fixed early next week then. Happy Easter!

*Edit*: Nevermind, actually they rolled out the fix now, it will take some hours to propagate out to everybody. You might need to restart/re-login in your client to see Connect working.

[ryanpcmcquen]

I try to avoid symlinking libraries in /usr/lib64, so my workaround was to replace /usr/bin/spotify with this script:

#!/bin/sh
## fix libudev issue
LD_LIBRARY_PATH=/opt/spotify/spotify-client/Data/ /opt/spotify/spotify-client/spotify

 This is of course after symlinking my libudev.so to the spotify Data/ directory:

ln -sf /usr/lib${LIBDIRSUFFIX}/libudev.so $PKG/opt/$SRCNAM/$SRCNAM-client/Data/libudev.so.1

More details here in the Slackware build:

http://slackbuilds.org/cgit/slackbuilds/commit/?id=6d3442997

EDIT: That symlinking code will not work if copied and pasted since it relies on variables defined in the build script. This would be the version with variables expanded (and both possible lib directories):

ln -sf /usr/lib64/libudev.so /opt/spotify/spotify-client/Data/libudev.so.1
ln -sf /usr/lib/libudev.so /opt/spotify/spotify-client/Data/libudev.so.1

[olejon]

---

@Orphis wrote:

May I ask what is your use-case for using a 32bit distribution and not 64bit one?

Intel 32bit Linux is slowly being phased out and with the current hardware, it makes much more sense to use 64bit in general.

As Nik said, there's a few issues we have to deal with in our build pipeline in order to produce a 32bit build. It's not impossible, but just currently much harder to do and our hands are already full with a lot of other things. Don't hold your breath, and please use the latest 32bit build meanwhile.

---

@Orphis - I have an old HTPC (Acer Revo) that runs Kodi/XBMC like a charm, with HW-accelerated playback through a powerful NVIDIA card (although the rest of the HW is slow). This HTPC is 32-bit, so I'm stuck with the very old client.

Also, I have noticed Spotify expanding more and more, also many developing countries, and my SpotCommander logs show a lot of users from those countries, and I think there are many there using old hardware (32-bit) as they cannot afford new. But I guess you have better statistics than I do, regarding the amount of 32-bit users.

Anyway I was hoping the new cross-platform tech would make it pretty easy for you to support 32-bit. Chromium Embedded, which I'm pretty sure you use, supports 32-bit...

[sbkg0002]

Installed the new beta client and it seems to work nicely! Great!

Although not the most beatifull solution, but I run it in xvfb and Connect works!

[renebarbosa]

Linux version is not working here. Constantly showing "Connection lost. Reconnecting... (error Code: 114).".

I've tested the Windows client using Windows on the same machine and the same network and it's working. =/

[am4c130d · Accepted solution]

@muammar

I had the same problem on Jessie.  I think the dependencies are wrong in the .deb, as installing other packages addressed the problem for me.  libavcodec53 and libavformat53 are only recommended - not required.

Try checking if the following are installed.

libavutil.so.51 - which is part of libavutil51
libavformat.so.53 - which is part of libavformat53 (I think this was the one that was not installed in my system)
libavcodec.so.53 - which is part of libavcodec53

Hope that helps.

[muammar]

---

@am4c130d wrote:

@muammar

I had the same problem on Jessie.  I think the dependencies are wrong in the .deb, as installing other packages addressed the problem for me.  libavcodec53 and libavformat53 are only recommended - not required.

Try checking if the following are installed.

libavutil.so.51 - which is part of libavutil51
libavformat.so.53 - which is part of libavformat53 (I think this was the one that was not installed in my system)
libavcodec.so.53 - which is part of libavcodec53

Hope that helps.

---

@am4c130d did you install those libraries from non-official packages? If yes, which ones and from where?

In my case, I am using the debian-multimedia repo, and I think all those libraries are pulled from there (I use debian unstable). I mostly play songs that are available in Spotify, but it is a pain to open another media player just to listen to few bands that are not available for streaming. 

[nikreiman]

---

@am4c130d wrote:

@muammar

I had the same problem on Jessie.  I think the dependencies are wrong in the .deb, as installing other packages addressed the problem for me.  libavcodec53 and libavformat53 are only recommended - not required.

Try checking if the following are installed.

libavutil.so.51 - which is part of libavutil51
libavformat.so.53 - which is part of libavformat53 (I think this was the one that was not installed in my system)
libavcodec.so.53 - which is part of libavcodec53

Hope that helps.

---

Hmm, I just noticed that our deb builder script for the 1.x beta doesn't include these packages at all. So I will add `libavcodec54` and `libavformat54` to the recommended packages. How does that sound?

BTW, the reason those don't install is because it seems that apt-get does not show any error message when a recommended package doesn't exist. See also http://askubuntu.com/a/117797/4860