[Solved] [Linux] Spotify 0.9.4, no Local Files reproduction after system update

Solved!
Reply

[Solved] [Linux] Spotify 0.9.4, no Local Files reproduction after system update

sdlion
Music Fan

I'm using Sabayon Linux (Gentoo Overlay)

 

From what I've read so far I think the problem is that libavcodec got updated to libavcodec.so.54 but it doesn't show with ldd

 

/usr/bin/spotify: /opt/spotify/spotify-client/libcrypto.so.0.9.8: no version information available (required by /usr/bin/spotify)
/usr/bin/spotify: /opt/spotify/spotify-client/libssl.so.0.9.8: no version information available (required by /usr/bin/spotify)
	linux-gate.so.1 (0xb77dc000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb778d000)
	librt.so.1 => /lib/librt.so.1 (0xb7784000)
	libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libstdc++.so.6 (0xb7683000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7550000)
	libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb754c000)
	libQtGui.so.4 => /usr/lib/qt4/libQtGui.so.4 (0xb6a73000)
	libQtCore.so.4 => /usr/lib/qt4/libQtCore.so.4 (0xb6786000)
	libQtDBus.so.4 => /usr/lib/qt4/libQtDBus.so.4 (0xb6705000)
	libQtNetwork.so.4 => /usr/lib/qt4/libQtNetwork.so.4 (0xb65c8000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb650d000)
	libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb60a8000)
	libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb5ff7000)
	libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb5ec9000)
	libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb5e7c000)
	libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb5e57000)
	libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb5ce8000)
	libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb5cc5000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb5c72000)
	libcef.so => /opt/spotify/spotify-client/Data/libcef.so (0xb2118000)
	libm.so.6 => /lib/libm.so.6 (0xb20d4000)
	libasound.so.2 => /usr/lib/libasound.so.2 (0xb1feb000)
	libXss.so.1 => /usr/lib/libXss.so.1 (0xb1fe7000)
	libdl.so.2 => /lib/libdl.so.2 (0xb1fe2000)
	libssl.so.0.9.8 => /opt/spotify/spotify-client/libssl.so.0.9.8 (0xb1f8b000)
	libcrypto.so.0.9.8 => /opt/spotify/spotify-client/libcrypto.so.0.9.8 (0xb1e0f000)
	libresolv.so.2 => /lib/libresolv.so.2 (0xb1df8000)
	libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0xb1dda000)
	libc.so.6 => /lib/libc.so.6 (0xb1c28000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb1af0000)
	/lib/ld-linux.so.2 (0xb77dd000)
	libpng16.so.16 => /usr/lib/libpng16.so.16 (0xb1ab6000)
	libz.so.1 => /lib/libz.so.1 (0xb1a9e000)
	libSM.so.6 => /usr/lib/libSM.so.6 (0xb1a95000)
	libICE.so.6 => /usr/lib/libICE.so.6 (0xb1a7b000)
	libXi.so.6 => /usr/lib/libXi.so.6 (0xb1a6a000)
	libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb1a5f000)
	libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb1a54000)
	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb1a4d000)
	libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb1a41000)
	libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb1a3d000)
	libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb1a01000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0xb19ee000)
	libQtXml.so.4 => /usr/lib/qt4/libQtXml.so.4 (0xb19a9000)
	libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb195e000)
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0xb18f5000)
	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0xb1744000)
	libbz2.so.1 => /lib/libbz2.so.1 (0xb1733000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb172d000)
	libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb171f000)
	libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb170a000)
	libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb1706000)
	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb1702000)
	libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb1689000)
	libEGL.so.1 => /usr/lib/libEGL.so.1 (0xb1669000)
	libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0 (0xb1665000)
	libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb165a000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb1635000)
	libGL.so.1 => /usr/lib/libGL.so.1 (0xb15b9000)
	libffi.so.6 => /usr/lib/libffi.so.6 (0xb15b1000)
	libnss3.so.1d => /opt/spotify/spotify-client/libnss3.so.1d (0xb146b000)
	libnssutil3.so.1d => /opt/spotify/spotify-client/libnssutil3.so.1d (0xb1445000)
	libsmime3.so.1d => /opt/spotify/spotify-client/libsmime3.so.1d (0xb1418000)
	libplc4.so.0d => /opt/spotify/spotify-client/libplc4.so.0d (0xb1412000)
	libnspr4.so.0d => /opt/spotify/spotify-client/libnspr4.so.0d (0xb13d2000)
	libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb13a1000)
	libcups.so.2 => /usr/lib/libcups.so.2 (0xb1331000)
	libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb12ab000)
	libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb1282000)
	libudev.so.0 => /opt/spotify/spotify-client/Data/libudev.so.0 (0xb126d000)
	libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb119f000)
	libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb116a000)
	libuuid.so.1 => /lib/libuuid.so.1 (0xb1164000)
	libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0xb1104000)
	libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0xb1101000)
	libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0xb10fb000)
	libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0 (0xb10f3000)
	libgbm.so.1 => /usr/lib/libgbm.so.1 (0xb10ec000)
	libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb10dd000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb10d9000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb10d2000)
	libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb1090000)
	libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0xb1076000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xb106f000)
	libplds4.so => /usr/lib/libplds4.so (0xb106a000)
	libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0xb1042000)
	libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb0ff9000)
	libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0xb0f2c000)
	libavahi-common.so.3 => /usr/lib/libavahi-common.so.3 (0xb0f1d000)
	libavahi-client.so.3 => /usr/lib/libavahi-client.so.3 (0xb0f0b000)
	libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb0f05000)
	libcom_err.so.2 => /lib/libcom_err.so.2 (0xb0f00000)
	libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb0ef3000)
	libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb0eed000)
	libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0xb0ecc000)
	libnettle.so.4 => /usr/lib/libnettle.so.4 (0xb0e97000)
	libgmp.so.10 => /usr/lib/libgmp.so.10 (0xb0e25000)
	libhogweed.so.2 => /usr/lib/libhogweed.so.2 (0xb0df5000)
	libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb0de3000)
# ldconfig -p | grep libavcodec
	libavcodec.so.54 (libc6) => /usr/lib/libavcodec.so.54
	libavcodec.so (libc6) => /usr/lib/libavcodec.so

 The first time I checked libavcodec it was like this 

# ldconfig -p | grep libavcodec
	libavcodec.so.54 (libc6) => /usr/lib/libavcodec.so.54
	libavcodec.so.53 (libc6) => /usr/lib/libavcodec.so.53
	libavcodec.so (libc6) => /usr/lib/libavcodec.so

 So I checked /usr/lib/, but:

# ls -l /usr/lib | grep libavcodec
lrwxrwxrwx  1 root root       21 feb 17 19:35 libavcodec.so -> libavcodec.so.54.35.0
lrwxrwxrwx  1 root root       21 feb 17 19:35 libavcodec.so.54 -> libavcodec.so.54.35.0
-rwxr-xr-x  1 root root  8688392 feb  5 10:42 libavcodec.so.54.35.0

 So it was clear yesterday the 54 version got in place with the update. Since then I haven't been able to play any local file.
Updating with ldconfig didn't make a difference but erased the libavcodec.so.53 entry.

 

This library belongs to media-video/libav-9.10-r1

# equo query belongs /usr/lib/libavcodec.so.54
╠  @@ Belong Search
╠      @@ Package: media-video/libav-9.10-r1 branch: 5, [__system__] 
╠          Installed:     version: 9.10-r1 ~ tag: NoTag ~ revision: 0
╠          Slot:          0
╠          Homepage:      http://libav.org/ 
╠          Description:   Complete solution to record, convert 
╠                         and stream audio and video. 
╠          License:       GPL-3 LGPL-2.1
╠   Keyword:  /usr/lib/libavcodec.so.54
╠   Found:    1 entry

 

 

There's no error in the console output

http://pastebin.com/i5MiCmem

 

Should I downgrade? Or Spotify really doesn't even use libavcodec.so.53 anymore? Since ldd didn't show any dependency to that library.

 

################# EDIT 2014/02/19 ##################

 

1. Compiled libav-0.8.10 and added the shared libraries to the database with ldconfig -n /path/to/library and didn't make any change.

 

2. Symlinked libavcodec.so.53 directly into /usr/bin, didn't work.

 

3. Replaced the libavcodec.so pointing to .so.54 with another one pointing to my own .so.53 and also didn't work.

 

4. Replaced /usr/bin/avplay with the 0.8.10 version through a symlink (with all these last symlinks in place), didn't work.

 

As ldd suggest, Spotify don't call the library directly, but also it didn't seem to use avplay whatsoever.

 

Any ideas?

 

Running it through gdb didn't shown any error message neither.

 

 

################# EDIT 2014/02/27 ##################

Running it with strace (and grepping "open(" ) shows that besides libavcodec.so.53 it also needs libavutil.so.51
I'm not sure if libavutil is called by libavcodec or if it's being called by spotify itself but copying or symlinking these files to the spotify-client directory will do the work.

 

You can download libav-0.8.10 sources from here http://libav.org/download.html

 

* Read the flags available with 

./configure --help

 

* And install the external libraries that you want to enable for libav

 

* Use the --enable-shared flag alongside with the other external libraries you want to use and then 'make'

 

The .so files for libavcodec and libavutil will be on their respectives folders on the directory where you compiled your brand new and old libav. Copy or symlink them to the spotify-client folder.

 

Thanks to leamas for the guidance and to this question How to check what shared library is loaded at run time?

1 ACCEPTED SOLUTION

Accepted Solutions
Solution! 2 people liked this

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

sdlion
Music Fan

Solved!!


It seems what it's missing is libavutil.so.51
The libraries that appeared missing from the test with ffmpeg-compat libraries seem that were dependencies from that libavutil, but it worked just fine with the shared libraries that libav 0.8.10 builds when it's compiled from source with the --enable-shared flag (./configure --help will give you all the options to enable different codecs).

 

Copied libavcodec.so.53 and strace showed that it was still calling to libavutil.so.51. Copied that too and that did the trick.

 

The names seems that are hardcoded so I didn't need to create symlinks without the soname version.

 

This could mean that if you compile your libav-0.8.10 without installing it (preferred method) one could just add the paths to these libraries in a file in /etc/ld.so.conf.d/ to make them available without copying the whole files to spotify's directory. But maybe it's not a good idea since some other program might want to use them and conflict with libav-0.9.

 

Libav-0.8.10 sources http://libav.org/releases/libav-0.8.10.tar.gz 

 

First configure and be sure to install first the external libraries (with your package manager) that you will enable

 

(this were my flags, you can use the ones that suits you better)

./configure --enable-shared --enable-nonfree --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libpulse --enable-libx264

and make

 

files to symlink or copy to the spotify-client directoy:
libavcodec/libavcodec.so.53

libavutil/libavutil.so.51

16 Replies
2 people liked this

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

leamas
Community Legend

Looking into the control file from the debian package I see :

Depends: libasound2 (>= 1.0.14), libc6 (>= 2.6), libqt4-dbus (>= 4.5.0), libqtcore4 (>= 4.5.0), libqtgui4 (>= 4.5.0), libqt4-network (>= 4.5.0), libstdc++6 (>= 4.0.0), libxss1 (>= 1:1.2.0), usbutils, libssl0.9.8, libnspr4-0d, libgconf2-4, libgtk2.0-0, libnss3-1d, libglib2.0-0, xdg-utils (>= 1.0.2), dbus-x11, libudev0 | libudev1
Recommends: libavcodec53 | libavcodec52 | libavcodec-extra-53 | libavcodec-extra-52, libavformat53 | libavformat52 | libavformat-extra-53 | libavformat-extra-52

 We recently discovered a bug in the fedora packaging which made local playback unusable. Adding the ffmpeg-compat package (which provides libavcodec/libavformat 0.52 on Fedora) solved the issue there.

 

So, yes, you should probably install libavcodec/libavformat with "correct" so-version (as seen from spotify) to make this work. It looks like the application is clever enough to load the libraries in runtime, coping with the situation when they don't exist -> they are not visible in in the static dependencies displayed by ldd.

 

As for your symlinking, the best is to put symlinks in the same directory as the spotify binary. This way you won't affect other applications, which might destibilize the overall system.

 

Furthermore, if spotify uses dlopen() and friends (which I suspect) symlinking can't resolve this - dlopen uses the so-version compiled into the ELF format to match, not just the filename.

 

HTH

 

--alec

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

sdlion
Music Fan

I'll study the ffmpeg-compat package and see what can I do to emulate what pretends. As from what I've investigated there's no similar package either in Gentoo or Sabayon Overlay.

 

What do you mean with this?

 


leamas wrote:

 

Furthermore, if spotify uses dlopen() and friends (which I suspect) symlinking can't resolve this - dlopen uses the so-version compiled into the ELF format to match, not just the filename.


I compiled the whole library and used symlinks just to place the libraries in /usr/lib (and /opt/spotify/spotify-client/{Data/})
So when it grabs the symlink it should go with the right binaries with the right version inside the compiled code. Even I tried to replace the /usr/bin/avplay binary with the one I got compiled.

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

leamas
Community Legend

sdlion wrote:

I'll study the ffmpeg-compat package and see what can I do to emulate what pretends. As from what I've investigated there's no similar package either in Gentoo or Sabayon Overlay.

 

What do you mean with this?

 


leamas wrote:

 

Furthermore, if spotify uses dlopen() and friends (which I suspect) symlinking can't resolve this - dlopen uses the so-version compiled into the ELF format to match, not just the filename.


I compiled the whole library and used symlinks just to place the libraries in /usr/lib (and /opt/spotify/spotify-client/{Data/})
So when it grabs the symlink it should go with the right binaries with the right version inside the compiled code. Even I tried to replace the /usr/bin/avplay binary with the one I got compiled.


Ah, sorry, too much writing, too littlle thinking. I was the referring to trying to solve the problems by symlinking "wrong" version to the right version. Using symlinks pointing to properly built libraries with correct so-version is of course no problem - . e. g., thats how all linux distros handle foo-1.1.1.so (last built version), foo-1.1.so, foo-1.so (symlinks).

 

--alec

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

sdlion
Music Fan

Then I'm mistified about how Spotify load this library.

 

Besides ldconfig I remember there was a some application to register new libraries to the current session manager or something like that.

I guess Spotify calls to the current something to get the default player or library, then from that information gets its version and test it's conditions before even trying to use the library. I guess this is the case since I can't see any message output from command line and not even gdb.

 

It seems my setup heavely depends on libav/ffmpeg-virtual and its current version so currently I don't intend to break my system downgrading them.

 

There's an official place to request features like a libavcodec.so.54 compatibility? 

 

I still haven't taken a look onto ffmpeg-compat, but I hope that brings me some answers.

 

 

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

leamas
Community Legend

I have really no more insight than you in the Spotify sources. That said, my first *guess* would be that spotify uses dlopen(3), the standard way to load "plugins", i. e., librraries  that might or might not be available in runtime.

 

There isn't any more official place than this list to get a reply. It's sad, but that's how it is. Still, I think the debian package (which *is* "supported", sort of) is pretty clear: it wants version 52 or 53, not 54.

 

--alec.

 

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

LinuxNerd
Casual Listener

For the record i'm having the same problem, same distro.  I guess it's no spotify for me till it catches up to libavcodec.so.54

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

sdlion
Music Fan

Yes, that seems the case.

 

I hope this thread meets the eye of one of the developer team and the issue gets addressed before the next version, since it has been a while from the last update.

 

I guess there's no easy solution to this problem since in many systems libav is quite a dependency of many tools and programs.

 

 

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

leamas
Community Legend

Part of this is the situation with libavcodec vs ffmpeg. libavcodec is a fork of ffmpeg. ffmpeg is "libavcodec compatible" whereas libavcodec is not "ffmpeg compatible". E. g., Fedora/rpmfusion is using ffmpeg whereas  debian is using libavcodec. For debian, there is a strong push to go back to using ffmpeg, though.

 

I don't see this as a spotify problem., IMHO it's more of  a Gentoo/Sabayon problem that the compatiblity package is missing. Spotify certainly isn't the only app out there depending on libavcodec >=0.52 <= 0.53. Given their official position to support debian only I don't think this will be fixed until Debian moves.

 

DISCLAIMER: I'm not affiliated with spotify in any way and don't speak for them.

 

--alec

Re: [Linux] Spotify 0.9.4, no Local Files reproduction after system update

sdlion
Music Fan

Gentoo/Sabayon has a ffmpeg-virtual package that I suppose pretends to cover the symlinks and other things needed for applications that call ffmpeg tools.

 

I also had before compiled and installed ffmpeg since I needed the most recent version (1.1) for serviio (DLNA server). I also thought that maybe spotify had some dependency with ffmpeg but after some tests there's was no response. After rebuilding ffmpeg sources with the "--enable-shared" flag I saw that uses libavcodec.so.54 too.

 

I think this is more a issue of spotify depending on a version <= 0.8.9 for libav or <= 0.10 for ffmpeg rather than the dispute ffmpeg vs. libav. Through eix (a portage package tree set of tools for search) I can see that ffmpeg 0.10 series is still available (along with 1.0 series that I guess are equivalent to libav 0.9 series) but I don't dare to install alongside libav and ffmpeg specially being two different incompatible versions and mixing up Sabayon's Entropy Package Manager and the Gentoo Portage Package tree it's very well known to be problematic if it's not done with care.

 

I only hope some Spotify developer help us giving us an insight about how Spotify loads it's libraries. That way we could find a workaround, create a hacked up sandbox or whatever. When you use Spotify outside a not debian system you can notice they though on behalf of those that don't use it since it's very easy to get it running through their comments on its installation scripts.

SUGGESTED POSTS