10-10-2013 02:14 PM - edited 21-05-2014 03:41 PM
Hi, fellow penguin fans!
Today we've pushed version 0.9.10.17 of the Linux desktop client to our public repo. Just update your system!
Linux specific changes:
- Now built on Ubuntu 12.04 (making it incompatible with some debian versions, see below)
- Track change notifications via libnotify
- OpenSSL is now version 1.0.x
- Local files playback works with libavcodec54
- A file called collectionCache.bnk is created in the home folder (it should be in .cache/spotify/Users/<spotify-username>-user/)
- It still doesn't work to drag from an HTML5 view to a legacy view (such as the sidebar).
- On first start, the HTML5 views may not appear (just empty black views), try restarting the app if it happens
- Some users have reported problems with the new track change notifications. If you experience problems, you can start the client with "spotify --ui.track_notifications_enabled=false", or you can edit the file called ~/.config/spotify/Users/<your-spotify-username>-us
- No 32-bit build is available
- This build is not compatible with debian squeeze or wheezy
If you don't already have the Linux client installed, install like this:
# 1. Add our repository. As root or with sudo, create # a file called /etc/apt/sources.list.d/spotify.list and add # "deb http://repository.spotify.com/stable non-free" to it. # Here's a one-liner: sudo sh -c 'echo "deb http://repository.spotify.com/stable non-free" > /etc/apt/sources.list.d/spotify.list' # 2. If you want to verify the downloaded packages, # you will need to add our public key sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 94558F59 # 3. Run apt-get update sudo apt-get update # 4. Install spotify! sudo apt-get install spotify-client You don't have a debian based system? Well, it's still possible to get things running. Either you convert the debian package to something else using alien, or you can just download and extract the stuff you need from the package. There is no need to install the client, it can be run from anywhere. # 1. Get the right filename SPOTIFY_DEB=http://repository.spotify.com/pool/non-free/s/spot
ify/spotify-client_0.9.10.17.g4129e1c.78-1_`uname -m | sed s/x86_64/amd64/ | sed s/i686/i386/`.deb # 2. Download the package wget repository.spotify.com/pool/non-free/s/spotify/$SP OTIFY_DEB # 3. Extract the required parts ar p $SPOTIFY_DEB data.tar.gz | tar -zx --strip-components=3 ./opt/spotify/spotify-client # 4. Go in to the extracted folder cd spotify-client # 5. Setup symlinks to libs (NOTE: this script assumes Fedora 17, edit to suit your needs) ./linklibs-fedora.sh # 6. Optionally register icons and menu item # Note: for the menu item to work, you need to ensure # spotify is in your $PATH, either by symlinking # it from /usr/bin or /usr/local/bin, or by adding # the spotify-client folder to your $PATH ./register.sh
Solved! Go to Solution.
26-11-2013 01:19 PM
Hey @AyTiRuppi :)
It is a known issue that having multiple locales breaks Spotify radio on Linux, full details and information on how to fix are over on this thread.
As for discover, if the above doesn't fix it too, if you could http://pastebin.com/ us the console output that might be handy. :)
If this post was helpful, please add kudos below!
21-05-2014 04:30 PM
10-10-2013 06:59 PM
I was hoping you would have upgraded to use libssl1.0.0 since libssl0.9.8 isn't in Debian stable, testing, unstable or experimental repositories anymore.
That has been discussed here on the community before, from what I remember they aren't binary compatible and there is a reason why they haven't yet moved over to 1.0.0.
Maybe one of the linux guys can let us know the details :)
Thanks for the realease as always guys!
If this post was helpful, please add kudos below!
10-10-2013 07:09 PM
15-10-2013 03:30 PM
I don't know if it's the latest version of Spotify or perhaps a change to pulseaudio but for the past couple of days I've seen a *lot* of crashes mid-playback with:
Assertion 's' failed at pulse/stream.c:2511, function pa_stream_get_timing_info(). Aborting. Aborted
Until recently the client seemed very stable.
16-10-2013 11:53 AM
Without your debug symbols it's hard to get any further than this but, in case it's useful, I ran spotify through gdb. Here's the backtrace after the error occurs.
Assertion 's' failed at pulse/stream.c:2511, function pa_stream_get_timing_info(). Aborting. Program received signal SIGABRT, Aborted. 0x00007fffee299037 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007fffee299037 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fffee29c698 in __GI_abort () at abort.c:90 #2 0x00007fffdd2bf1b4 in pa_stream_get_timing_info (s=0x0) at pulse/stream.c:2512 #3 0x000000000119db3e in ?? () #4 0x000000000119034b in ?? () #5 0x000000000118fd19 in ?? () #6 0x000000000118d1a0 in ?? () #7 0x0000000001080100 in ?? () #8 0x000000000120fb84 in ?? () #9 0x000000000120fcb2 in ?? () #10 0x0000000000ddc17a in ?? () #11 0x0000000000ddc835 in ?? () #12 0x0000000000dde80b in ?? () #13 0x0000000000ddbd60 in ?? () #14 0x0000000000dda974 in ?? () #15 0x0000000000ddaa7e in ?? () #16 0x000000000118e669 in ?? () #17 0x00000000014fb22f in ?? () #18 0x0000000000453daf in ?? () #19 0x000000000043d24e in ?? () #20 0x00007ffff61c25be in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #21 0x00007ffff66da314 in QApplication::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #22 0x00007ffff66d28ec in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #23 0x00007ffff66d525b in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 #24 0x00007ffff61a863e in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #25 0x00007ffff61ac171 in QCoreApplicationPrivate::sendPostedEvents(QObject*
, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #26 0x00007ffff61d6e83 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 #27 0x00007ffff73fef05 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #28 0x00007ffff73ff248 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #29 0x00007ffff73ff304 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #30 0x00007ffff13b01d0 in ?? () from /opt/spotify/spotify-client/Data/libcef.so #31 0x00007ffff13e3c32 in ?? () from /opt/spotify/spotify-client/Data/libcef.so #32 0x00007ffff13ffadd in ?? () from /opt/spotify/spotify-client/Data/libcef.so
If I'm reading that right, what's happening is that an event is firing which causes pulse to try to get the timing info of a stream but the stream either isn't assigned or it's been deleted by the time the call happens.
16-10-2013 04:14 PM
Looking at your release notes, I think I have an idea what the cause of the problem might be. You've switched from CEF1 to CEF3, so something that was once synchronous with the main thread is now asynchronous. Looking at the debug output, there's an event that seems to trigger the chain of events that occasionally causes a crash. I reckon you end up trying to use the same pulse stream from different threads, so one of them ends up with a null stream. With the old build, as CEF only had one thread to play with, it wasn't an issue. It's only a hunch, but this is erratic enough that it really feels like a threading issue, and along with the switch from a synchronous to a threaded library it all looks a bit suggestive.
Could be nonsense, of course.
|Hi folks. We're aware that ... . We're investigating!|
To stay updated please come in here.
Please bear in mind that the Community is not an official Spotify support service. It's a place where we all help each other, whether we work for Spotify or not. So please use your discretion when using the forum.