raspotify: Some songs cant be played

Ok, this is going to be a lot to post. It’s not as bad as it looks. : )

---

Run these commands as your normal, logged in user. Use sudo when a privileged command is needed.

Install some prerequisites: sudo apt-get install build-essential libasound2-dev

I needed a newer version of rust than my pi installed from apt. Per the instructions at https://www.rust-lang.org/tools/install: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

When prompted, proceed with the default by selecting 1

When the install finishes, we need to update our paths for our currently logged in session: source ~/.cargo/env

Compile and install librespot (This step will take quite a while, 41 minutes for me) If you need the alsa backend (Raspotify’s default), mk-360 found the correct way to install for that: cargo install librespot --no-default-features --features "alsa-backend"

Alternatively, this will install with librespot using the new rodio backend. Do not run this command if you ran the above command for the alsa-backend, or you won’t be able to use the alsa-backend. cargo install librespot

If it completes successfully, you should see something similar to: Finished release [optimized] target(s) in 41m 46s Installing /home/pi/.cargo/bin/librespot Installed package librespot v0.1.3 (executable librespot)

If we ask the OS where librespot is installed, we should see two installs: whereis librespot

Example output: librespot: /usr/bin/librespot /home/pi/.cargo/bin/librespot

The new copy is in your home directory. Before we make changes, lets shutdown Raspotify: sudo systemctl stop raspotify

Move old librespot and symlink to the new one. I’m getting /usr/bin from my whereis output. My install had dtcooper’s install in /usr/bin: cd /usr/bin/ sudo mv librespot librespot.old sudo ln -sf ~/.cargo/bin/librespot /usr/bin/librespot

The new librespot has changed some of it’s option flags. We will need to edit our /etc/default/raspotify. But first we’ll copy and symlink. cd /etc/default sudo cp raspotify raspotify.old sudo mv raspotify raspotify.new

Edit raspotify.new with your preferred editor. You will need to sudo to edit this file. Raspotify by default uses --linear-volume. This option changed in the new version of librespot. Uncomment the following line by removing the # at the start of the line: #VOLUME_ARGS="--enable-volume-normalisation --linear-volume --initial-volume=100"

Edit the line so that --linear-volume is now --mixer-linear-volume: VOLUME_ARGS="--enable-volume-normalisation --mixer-linear-volume --initial-volume=100"

If you installed with the new rodio backend, you will need to change from the default backend. At the bottom of the file should be the following line. Remove the # to uncomment it: #BACKEND_ARGS="--backend alsa"

Make it look like the following (only if you installed with the default that uses rodio) BACKEND_ARGS="--backend rodio"

Finally symlink to our new config: sudo ln -sf raspotify.new raspotify

Now start raspotify and test it. sudo systemctl start raspotify

To check the logs: journalctl -u raspotify

---

To change everything back to the dtcooper’s config and binary: sudo systemctl stop raspotify sudo ln -sf /usr/bin/librespot.old /usr/bin/librespot sudo ln -sf /etc/default/raspotify.old /etc/default/raspotify sudo systemctl start raspotify

---

In the future… To update our build environment and get available librespot updates: (Probably should stop the raspotify service before updating)

Install prerequisite package: sudo apt install libssl-dev

Install an update package for cargo: (This step will take a while, 21 minutes for me) cargo install cargo-update

Now we can update rust: rustup update

And our installed/compiled packages: cargo install-update -a

---

Other thoughts…

There is more than one way to do this. Instead of symlinking the librespot binary, we can create a systemd override file for the raspotify.service file and point it directly to the new librespot we compiled. This would prevent an update from overwriting our changes and from changing the librespot binary we are using. As it stands with this method, if dtcooper updates his repo it will install a new librespot over top of our symlink and we’ll start using that version of the file. I figured if that happened, why not try and see if it works. If it doesn’t, follow the steps to move it to librespot.old and symlink back to the version we made.

Just some additional food for thought…

I believe it has something to do with the librespot that is included with raspotify. I went to that project’s site and followed their install/compile directions, then symlinked it where raspotify installed it’s build of it. It’s been over a day since I’ve seen the issue now. Previously, I was seeing it every time I listened.

edit: Just remembered, some of the option flags have changed in the newer version of librespot. You will have to tweak /etc/default/raspotify