[Linux] Spotify 0.8.8 for GNU/Linux

[parbo]

Update: Spotify for Linux v0.9.4 is now available. See here.

Hi everybody!

Today we pushed the latest and greatest Spotify client to our repository. This time you're getting the good stuff first, this version has only been rolled out to a small percentage of Windows/Mac users. It contains some of the features that were presented on our recent press event, such as being able to follow artists and tastemakers. Have a look at the brand new Follow page, where you can find interesting artists and other people to follow. You'll get updates on their activity, such as newly released albums etc.

As for Linux-specific fixes, there are some minor bug fixes. The biggest change is the packaging. The client now is installed to /opt and it uses XDG mechanisms to register icons and menus. The executable is now also built without hardcoded paths to libraries. This means that the folder can be put anywhere and just run from there. Unfortunately, this release still depends on libssl0.9.8. We'll try to get rid of that in upcoming releases!

The new client is just a "sudo apt-get update && sudo apt-get upgrade" away!

What, you don't already have Spotify installed? Lookie here: http://www.spotify.com/download/previews/

Don't use Debian? Check out these zip packages:

http://download.spotify.com/preview/spotify-client-linux-0.8.8.323.gd143501e-i686.zip

http://download.spotify.com/preview/spotify-client-linux-0.8.8.323.gd143501e-amd64.zip

Edit: updated to include the zip packages.

[leamas]

This s great news. I will try to update  the Fedora spec ASAP, but will probably need some days for that. Stay tuned!

It's especially nice that the Linux version now seems as fast as other supported platforms!

And, of course, servicing  fedora users would be so much simpler if there was other license conditions. But lawyers being what they are I guess this is far away, if at all under way. We do the best we can with this nice client!.

EDIT: I have published a first shot for a Fedora 0.8.8 spec.

[parbo]

You mean the license to redistribute? I can take a look and see how far that has gotten. When the new zip packages are up, I think you should be able to make a fedora package that just downloads that and runs some scripts included to install it..

[leamas]

Yes, I mean the redistribute + repackage rights, still without touching the binaries.

A user downloader/installer  is certainly possible. But then you miss all the advantages of using rpm (or dpkg) such as keeping track of files, dependencies, safe removals, updates etc. I would prefer not going that path.  

Someone else will probably create  such a script anyway. With a bit of care it doesn't even need to be distro-specific, I guess.

[aspiers]

@parbo, thanks for the great work!  If you are able to solve the licensing aspects of redistribution then the various distribution communities would be able to take care of much of the packaging work for you.

In the mean time, there is a half-way house, which is to provide a script which creates the package and then uninstalls it.  This is exactly what I have been maintaining here: https://github.com/aspiers/opensuse-spotify-installer

Are you likely to be able to provide the .zip files soon?  If so, I will hang fire on updating my installer to 0.8.8. 

[SteveBrammer]

Thanks for this!

All the problems with crashing apps like "Blue Note" and "Classify" on 64bit linux seems to have been fixed as well.

[leamas]

Given that I can't redistribute the stuff, it becomes a problem that the old links are removed. Is there any chance you could restore the old links to 0.8.4 until I have had time to fix the specfile? As of now, it's not working any more and I need some time to adapt to new package layout.

I can use other links (e. g., a subdir) without problems.

[Specialed08]

Problems with 0.8.8.  After an upgrade this morning, when spotify is started there is some type of privacy agreement that I can't get rid of.  It will not allow my music to play, the box looks like it is missing the edges. 

I am running Linux Mint 14 /64bit & 32bit

They both show the same issue.

Any ideas?

[leamas · Accepted solution]

I had similar issues. Removing ~/.cache/spotify and removing the LD_LIBRARY_PATH I used for 0.8.4 fixed it.

The load path seems odd. I get warnings while packaging for extremely odd RPATHs. They dont exit on my syste, so I avoid patching them. Perhaps I should, though.

[ost2life]

It's great, and it all looks pretty, but if it's only importing a small fraction of my aparently compliant MP3 (Read: NOT M4A, WAV, FLAC, OGG or WMA - proper, honest-to-dog MP3) then it's pretty pointless to me, which is a shame, because I really really want to love it. I really do. I'm still paying, I'm not threatening to leave - I just want it to work properly. Please?

[Specialed08]

Here is the error I noticed when loading from the cli

(spotify:2440): Gtk-CRITICAL **: gtk_box_pack: assertion `GTK_IS_BOX (box)' failed

I cleared the .cache/spotify out and reinstalled.  Never modified the LD_LIBRARY.

[leamas]

Hm... let's see if I get some feedback on my specfile for 0.8.8. I can just confirm that I got rid of it using the methods I mentioned.

Note that I have several similar console messages, but spotify runs fine anyway.

[parbo]

The gtk warnings shouldn't be a problem (I get those too), but I'll take a look at why they appear.

About the missing local files, that's not new in this release, right? Do you see any pattern in what Spotify doesn't pick up? Is there a deep folder hierarchy? Are there symlinks involved? Could send me a private message with the output of "tree -l -h"?

[leamas]

Although this perhaps isn't is the issue here, this post seems related i. e. that spotify uses Windows-style filename matching instead of he magic(5) stuff used by file(1) and libmagic(3)? . If this hasn't been changed in 0.8.8, that is.

[parbo]

Yes, we just do matching on the extension. We have no plans to change that in the near future.

[leamas]

Here is a bad rpath. Packaging says:

WARNING 0002: file '/usr/lib/spotify-client/spotify' contains an invalid rpath '/build/spotify-0ZhdF_/spotify-0.8.8.323.gd143501.250/binaries/cef/linux-32/Release' in [/build/spotify-0ZhdF_/spotify-0.8.8.323.gd143501.250/binaries/cef/linux-32/Release:$ORIGIN]

 i. e., there is a rpath to some internal build directory in /build/spotify-0zhdf_... It's perhaps not a practical problem, but combining a rpath like this with non-modifiable terms gives a strange impression 🙂

EDIT: and there is  a risk that something working when tested internally with this rpath breaks for users installing it in other locations...

[ost2life]

No, they're not new in this release. There are a couple of threads recently on the topic. I can't speak for everyone but in my experience there doesn't seem to be any pattern as if you clear the library and start again it'll scan a different set of files into the library instead. The structure is that the whole collection is in one folder sub foldered by artist then by album and they are absolutely all mp3 🙂 I'll sent the tree output in a minute. Thanks

EDIT: Just tried the local library again today, it seems to have settled on about 9k songs it likes - but thats still less than half. Output of tree on its way.

[parbo]

Yeah, that RPATH is there for debugging purposes. It shouldn't be like that in the release. I'll fix that. There's no need to do anything with that RPATH. We used to have another hardcoded path, which you may have had to change, but now we use $ORIGIN instead to look relative to the executable.

[Rizzer]

Thanks for the new version, my update has just found it.  It's running fine (on Debian unstable).

As in previous versions, the client continues to miss the majority of local files, which in my case are ogg vorbis (*.ogg).  The client only finds the mp3 files in my music collection.  I presume it's the file type (.ogg not .mp3) that triggers the bug, rather than any problem with the directory structure.

[parbo]

Sadly, we don't support ogg as local files (even though we use ogg for streaming). This is due to us relying on some extra ogg metadata to enable better seeking performance. I could look into that, but I won't make any promises about it.