Roughly a month ago, I reviewed Spotify here on OCS-Mag, testing the recently revived Ubuntu version. My experience was mixed. While the media player sported good looks and a sleek interface, the overall behavior was slightly erratic, culminating in crashes when trying to play local files.

Since, I have spent more time exploring Spotify, not necessarily because I was enamored by its features and abilities, mostly because I felt it would be a worthy exercise for all those seeking the thrills of popular media streaming on Linux. Furthermore, like my past endeavors with Steam, Sketchup and alike, it’s part of a possibly Don Quixotic attempt to bridge the application gap between Windows and Linux, and give the users of the latter system some more freedom and choice. But there’s a cost. Sometimes, things do not work right away, or they do not work at all. This article is the diary of my journey.

Enter Fedora

In the original review we mentioned earlier, I highlighted the fact the official download page only features Debian builds. But RPM-based Fedora builds are also available in some unofficial repositories. To wit, I powered my Fedora 24 instance and set about testing. With the right extra sources in place, I was able to install and launch the client without any problems. Progress!

The looks and the behavior are largely the same, compared to the Ubuntu version, and even my profile settings and playlists were correctly synced. The one thing that did not work was the Local Files. When I tried to play any which file, a blue bar/ribbon popped up at the top of the client interface informing me that: ‘This song is not available. If you have the file on your computer you can import it.’ Well, what now?

Enter debug & missing extensions

I decided to troubleshoot by launching Spotify from the command line and observing loadtime and then runtime errors, trying to figure out if any or some of these might be related. Moreover, I also started checking the official forums, searching for common ideas and threads regarding my problem. The first and most prominent problem was Spotify complaining about some extensions:

[1111/171435:ERROR:main_delegate.cc(752)] Could not load cef_extensions.pak

Reading through the forums revealed that an extension was missing, part of the Chromium Embedded Framework (CEF), which focuses on facilitating embedded browser use cases in third-party applications, which definitely seems to be the case here. I was not 100% sure which part of the functionality, if any, was affected by this, but I thought it would be a good idea to have an error-free Spotify instance before debugging further. Once I had downloaded the package, I copied the pak:

cp cef_extensions.pak /usr/lib64/spotify-client/

This created a slightly less noise command line output for the subsequent Spotify launch, but it did not resolve the Local Files issue just yet.

Crypto errors & warnings

The second worrying piece is that Spotify complains about certain versions of SSL not having the version information available.

spotify: /lib64/libssl.so.1.0.0: no version information available (required by spotify)
 spotify: /lib64/libcrypto.so.1.0.0: no version information available (required by spotify)
 spotify: /lib64/libcurl.so.4: no version information available (required by spotify)

Reading on the website that provides the Fedora package:

The provided client is binary only and compiled for Ubuntu, so the Fedora package de-assembles the original Ubuntu package and moves all files in the appropriate places. To overcome library conflicts, the package contains symlinks from Fedora system libraries to match the original Ubuntu names, adds native Ubuntu OpenSSL libraries and leaves RUNPATH enabled for finding libraries on its own.

Based on the errors, I realized that perhaps the symlinks were not working as well as they could, given the difference between the Fedora and Ubuntu code base, and that this potentially might create authentication or security issues if a secure connection is required. I have not spent too much time troubleshooting this, as it was a distraction from our original missing, but again, it was nothing something that inspired me with confidence regarding our build, and the future success of this work.

As a pure act of witchcraft, some of the forum threads suggest the following package, from RPM Fusion, as a possible workaround. In my case, this did not have any effect on the errors, or the Local Files behavior:

dnf install lpf-spotify-client package

WINE testing

At this point, I thought about a diversion. Why not try using the Windows version perhaps, and have it installed through the WINE framework. If only. Initially, Spotify protested it needed Windows 7 or higher. After I tweaked the default configuration, it informed me: ‘Please install Spotify using a normal account instead of an Administrator account.’ Disabling various overrides did nothing.

I even spent a good 30 minutes configuring a separate, WINE-only account, following the somewhat convoluted and partially erroneous and/or redundant but well-intentioned instructions on Bobulous Central. This was a very interesting exercise, as it involved user account creation, X Server tweaks, and a few other hacks. However, much like the initial attempt to install Spotify, it still complained about the administrator account.

In more detail, user creation:

sudo adduser --shell /bin/false wine
sudo usermod --append --groups audio wine

Sudoers change:

roger ALL=(wine) NOPASSWD: ALL

X Server tweaks:

xhost +SI:localuser:wine

Process table output:

root 27434 5714 0 18:35 pts/1 00:00:00 sudo -u wine wine /home/wine/SpotifySetup.exe
wine 27435 27434 1 18:35 pts/1 00:00:00 /home/wine/SpotifySetup.exe
wine 27438 2337 4 18:35 ? 00:00:00 /usr/bin/wineserver
wine 27444 2337 0 18:35 ? 00:00:00 C:\windows\system32\services.exe
wine 27446 2337 2 18:35 ? 00:00:00 C:\windows\system32\explorer.exe /desktop
wine 27450 2337 0 18:35 ? 00:00:00 C:\windows\system32\winedevice.exe
wine 27459 2337 0 18:35 ? 00:00:00 C:\windows\system32\plugplay.exe
root 27471 27381 0 18:35 pts/3 00:00:00 grep --color=auto wine

Back to pure Linux

At this point, with some more reading underway and a lot of time spent poring through the strace output file, the only error that was making sense was that a file was missing from the cache. Deleting the cache folder did not yield any success or progress.

27866 stat("/home/roger/.cache/spotify/Browser/Local Storage/http_c.betrad.com_0
 .localstorage", 0x7fddd6bc5580) = -1 ENOENT (No such file or directory)

Compile your own libraries

This turned out to be the most significant and time-consuming piece of my work. I knew that Spotify was using hardcoded versions of libavformat and libavcodec, and that perhaps the Fedora versions were just not suitable. So I decided to compile my own, and then also use online search to find the needed libraries, extract them, and then copy the shared objects into the Spotify directory. I wanted to try both methods to make sure my work was complete. I decided to try an older release of Libav – 0.8.10.

To be able to compile this, you will need to satisfy a whole bunch of dependencies, header files and development packages. For me, the full list included – apart from the obvious, build-essential gcc, make, kernel sources and kernel headers, always a must; plus all the other dependencies related to media software installed over several months of extensive use.

dnf install yasm faac-devel lame-devel libpulse-simple pulseaudio-libs-devel x264-devel

I then configured the sources with:

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

The make command file on an undefined symbol:

/usr/bin/ld: libavutil/intfloat_readwrite.o: relocation R_X86_64_PC32 against undefined symbol `ldexp@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
 /usr/bin/ld: final link failed: Bad value
 collect2: error: ld returned 1 exit status
 library.mak:91: recipe for target 'libavutil/libavutil.so.51' failed
 make: *** [libavutil/libavutil.so.51] Error 1

I resolved this by adding the fPIC compilation flag. If you’re not using a Makefile, then you can export the variable in the shell:

export CXXFLAGS="$CXXFLAGS -fPIC"

Eventually the sources compiled, I had the shared objects.

But they did not work. Then, I also tried by downloading precompiled packages from the Web, namely:

https://rpmfind.net/linux/rpm2html/search.php?query=libavutil.so.51()(64bit)
https://rpmfind.net/linux/rpm2html/search.php?query=libavcodec.so.53()(64bit)

Alas, this also did not resolve the problem as I hoped. And at this point, I thought it would be a good idea to give the Spotify client some rest, both from me and Linux. My Ubuntu experiment had ended up in a crash. My Fedora experiment was less prone to total self-destruction, but I was nowhere closer to enjoying my own music than before. The Local Files error is quite difficult to troubleshoot, and there are no visible errors in the system trace. This is an internal error, and therefore it is not really visible without the use of gdb, which might not even be legal as it could be considered reverse engineering. Then, the forum threads, as varied and cryptic as they might be, almost agree that this is a regression affecting newer Spotify builds, and something that did not occur in the past. Given the low frequency of releases for Linux, and the official use of a single target platform, it does seem unlikely this will be resolved any time soon, or that there will be a suitable Fedora fix to match the Ubuntu one, if ever.

Conclusion

I like to brag on my troubleshooting and problem solving skills, and I like to think my intuition is right, and that I am fairly patient, methodical and attentive to details. I also like to see problems responding to my taunts and tweaks and change accordingly. Living Linux systems cry when in pain and get wet when in the rain. But in this particular case, the Spotify client remain quiet indifferent to all my pokes and changes, and apart from a small number of errors being fixed early on in my testing, I did not make much progress beyond that.

Another somewhat alarming thing is the almost random, erratic variance in the provided fixes and solutions in the forums, some of which feel like luck or coincidence, others which do not seem correlated to the issue at hand at all, which makes me question and doubt their longer-term efficiency. This is not something that any particular entity can solve, but good products are reliable and predictible, and that also means their errors and woes. I would like to see a small number of issues that can cause the Local Files issue. At the moment, it would seem there could be dozens, all sporadic, all unrelated, and without a common theme, there is not really much to do in how to fix or troubleshoot the problem.

Lastly, Spotify is definitely not a Linux program. As much as we’d like it to be, the development focus is elsewhere, and it clearly shows. Spotify is a well-baked, robust product, and its Linux version(s) are so much different from what you get on the other operating systems. I was hoping to delight you, to show you a diehard hack that would make you really happy, just because we can. Alas, it is not meant to be, and the way this little investigation unfolded makes me feel there is not likely going to be any Spotify for Linux working elegantly and without bugs any time soon. But it’s a worthy lesson nonetheless. See you around.

[sharedaddy]