Spotify daemon stops playing after a while

[dennisfrijlink]

Describe the bug
The spotify deamon setup works fine but for somehow after a while it just stops playing and not just pause, the song is also not selected anymore.

HiFiBerryOS version
20240523

HiFiBerry sound card
DAC+ Pro

To Reproduce
Steps to reproduce the behavior:

1. play song with spotify daemon
2. wait for a while, and the bug appears (could not find a period of time)

Expected behavior
Just keep playing.

Additional context
Beside that when I check the logs of the spotify deamon it returns nothing

# journalctl -b -u spotify.service
# ~
# ~
# ~
# ~
# ~
# ~

And when checking the running services nothing spotify related is showing:

  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  audiocontrol2.service        loaded active running Audiocontrol2
  avahi-daemon.service         loaded active running Avahi mDNS/DNS-SD Stack
  avahi-dnsconfd.service       loaded active running Avahi DNS Configuration Daemon
  beocreate2.service           loaded active running Beocreate 2 Server
  bluealsa-aplay.service       loaded active running BlueALSA aplay
  bluealsa.service             loaded active running BlueALSA
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  audiocontrol2.service        loaded active running Audiocontrol2
  avahi-daemon.service         loaded active running Avahi mDNS/DNS-SD Stack
  avahi-dnsconfd.service       loaded active running Avahi DNS Configuration Daemon
  beocreate2.service           loaded active running Beocreate 2 Server
  bluealsa-aplay.service       loaded active running BlueALSA aplay
  bluealsa.service             loaded active running BlueALSA
  bluetooth.service            loaded active running Bluetooth service
  btagent.service              loaded active running Bluetooth Auth Agent
  containerd.service           loaded active running containerd container runtime
  datacollector.service        loaded active running Usage data collector
  dbus.service                 loaded active running D-Bus System Message Bus
  docker.service               loaded active running Docker Application Container Engine
  [email protected]           loaded active running Getty on tty1
  mpd-update-notifier.service  loaded active running mpd update notifier
  mpd.service                  loaded active running mpd
  ntpd.service                 loaded active running Network Time Service
  rngd.service                 loaded active running Hardware RNG Entropy Gatherer Daemon
  seatd.service                loaded active running Seat management daemon
  sigmatcp.service             loaded active running SigmaTCP Server for HiFiBerry DSP
  sshd.service                 loaded active running OpenSSH server daemon
  systemd-journald.service     loaded active running Journal Service
  systemd-networkd.service     loaded active running Network Configuration
  systemd-resolved.service     loaded active running Network Name Resolution
  systemd-timesyncd.service    loaded active running Network Time Synchronization
  systemd-udevd.service        loaded active running Rule-based Manager for Device Events and Files
  weston.service               loaded active running Weston, a Wayland compositor, as a system service
  wpa_supplicant.service       loaded active running WPA supplicant
  [email protected] loaded active running WPA supplicant for wlan0

[josefmuhr]

Same for me with Spotify Connect as source, so using vollibrespot.

Could be the same problem as stated in #576 .

I did remove the Spotify IP from the /etc/hosts file but this only gets the connection working, not ensuring that it stays stable.

So there is a good chance that the error is on Spotifys side.

Quick update:
The web interface is still working after playback stopped.
In the sources section of the web interface I'm seeing that bluetooth is the active source, without me connecting to the pi via bluetooth.
For now I disabled bluetooth as a source (I don't use it anyway).
I will test and report back if the error persists.

Update 2 : For now this seems to work for me. Had disconnects every ~10 minutes. Been playing without disconnecting for 20ish minutes.

[dennisfrijlink]

Hi @josefmuhr did disabling bluetooth fixed the issue permanent? And how did you disbaled the bluetooth, via the web UI or via SSH?

Thanks in advancd

[josefmuhr]

Hi @josefmuhr did disabling bluetooth fixed the issue permanent? And how did you disbaled the bluetooth, via the web UI or via SSH?

Thanks in advancd

I have not had a single disconnect since disabling.
I did disable it via the web UI.

[dennisfrijlink]

Hi @josefmuhr,

Maybe the time before the spotify daemon intterups playing has increased, but it still stops after a while.
Is yours working for a long time (like 20 ~ 30 mins)?

[josefmuhr]

@dennisfrijlink it does work for me.
Since my reply I updated the boot sd card (16gb to 128gb), which did cause some problems during setup but once I got it to work there have been no disconnects since.
Longest continuous playback time I tested was around 2h.

[dennisfrijlink]

Hi @josefmuhr,

Still having issues with Spotify stops playing music after a while (e.g. 20 minutes).

Here the spotifyd config (see below). Maybe someone is stuck in there. I'm using the Hfibiberry Amp4 Pro, but I don't think he's the cause of the issue.

Thanks in advance

[global]
# Your Spotify account name.
#username = ""

# Your Spotify account password.
#password = ""

# If set to true, `spotifyd` tries to bind to dbus (default is the session bus)
# and expose MPRIS controls. When running headless, without the session bus,
# you should set this to false, to avoid errors. If you still want to use MPRIS,
# have a look at the `dbus_type` option.
use_mpris = true

# The bus to bind to with the MPRIS interface.
# Possible values: "session", "system"
# The system bus can be used if no graphical session is available
# (e.g. on headless systems) but you still want to be able to use MPRIS.
# NOTE: You might need to add appropriate policies to allow spotifyd to
# own the name.
dbus_type = "system"

# The audio backend used to play music. To get
# a list of possible backends, run `spotifyd --help`.
backend = "alsa" # use portaudio for BSD and macOS [homebrew]

# The alsa audio device to stream audio. To get a
# list of valid devices, run `aplay -L`,
device = "hw:0"  # omit for macOS

# The PCM sample format to use. Possible values
# are F32, S32, S24, S24_3, S16.
# Change this value if you encounter errors like
# "Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_format' failed with error 'EINVAL: Invalid argument'"
audio_format = "S16"

# The alsa control device. By default this is the same
# name as the `device` field.
#control = "hw:0"  # omit for macOS

# The alsa mixer used by `spotifyd`.
mixer = "Digital"  # omit for macOS

# The volume controller. Each one behaves different to
# volume increases. For possible values, run
# `spotifyd --help`.
volume_controller = "none"  # use softvol for BSD and macOS

# A command that gets executed in your shell after each song changes.
#on_song_change_hook = ""

# The name that gets displayed under the connect tab on
# official clients.
device_name = "HiFiBerry"

# The audio bitrate. 96, 160 or 320 kbit/s
bitrate = 320

# The directory used to cache audio data. This setting can save
# a lot of bandwidth when activated, as it will avoid re-downloading
# audio files when replaying them.
#
# Note: The file path does not get expanded. Environment variables and
# shell placeholders like $HOME or ~ don't work!
cache_path = "/cache"

# The maximal size of the cache directory in bytes
# The example value corresponds to ~ 1GB
max_cache_size = 100000000

# If set to true, audio data does NOT get cached.
no_audio_cache = true

# Volume on startup between 0 and 100
# NOTE: This variable's type will change in v0.4, to a number (instead of string)
initial_volume = "0"

# If set to true, enables volume normalisation between songs.
volume_normalisation = false

# The normalisation pregain that is applied for each song.
normalisation_pregain = -10

# After the music playback has ended, start playing similar songs based on the previous tracks.
autoplay = true

# The port at which `spotifyd` is going to offer its service over the network (TCP).
# If not set, a random port > 1024 is used. For the service to be discoverable on the
# local network via mDNS, both the mDNS port (5353 UDP) and the random or fixed
# zeroconf port need to be allowed through any active firewall.
zeroconf_port = 1234

# The displayed device type in Spotify clients.
# Can be unknown, computer, tablet, smartphone, speaker, t_v,
# a_v_r (Audio/Video Receiver), s_t_b (Set-Top Box), and audio_dongle.
device_type = "audio_dongle"

[baldrianbandit]

I've had the issue as well with latest beta of HBOS. For me, it helped to stop the spotify app on my android phone. Thus, I suspect the app to be the source of this.

[dennisfrijlink]

@baldrianbandit I also use an Android Phone. But that means with the current release of HBOS the user cannot (easily) use spotify connect to play music?

[baldrianbandit]

Well, in my case the issue started at some point and stopped... recently. My HBOS device wasn't altered nor restarted for two months, though. Spotifyd would sometimes even stop after each track. Now it's running fine all day long. I have the feeling this has to do with a regression bug in the spotify app that maybe got fixed by now. Currently I use build 8.9.96.476.

[Eirikr70]

Hello, I have the same problem of spotify disconnecting. I suspect it might be related to issue #1340 of librespot, which has been fixed in a recent release. So I would ask for releasing a version of HBOS with the latest librespot version. Thanks

[hifiberry]

@Eirikr70 As wer'e not using librespot directly, we can only use what's implemented by the developers of a project - volllibrespot in this case.
If somebody can create a patch for it, test and maintain it, we're happy to integrate it.

[Eirikr70]

@Eirikr70 As wer'e not using librespot directly, we can only use what's implemented by the developers of a project - volllibrespot in this case. If somebody can create a patch for it, test and maintain it, we're happy to integrate it.

Hi @hifiberry , this answer seems hardly acceptable to me. I have bought a product from hifiberry and it depends on your OS to work. Vollibrespot has been discontinued two years ago. You cannot hide behind the default of a third party to avoid fulfilling your obligations. You need to find a workaround for Vollibrespot's lack of maintenance.

EDIT : apologies, I didn't know of the 64bit alternative.

[hifiberry]

@Eirikr70 It seems, there are some misunderstandings. None of our products depends on HiFiBerryOS, HiFiBerryOS is a software we give away for free. Nobody ever "bought" it. We also never claimed that any of the products we sell would support Spotify.

If you don't want to use HiFiBerryOS, you don't have to. Just install Raspberry Pi OS, configure the drivers and install whatever you like.

[Profoktor]

@hifiberry It seems that both vollibrespot and spotifyd are kind of outdated (esp. regarding the librespot-dependency).
I looked a bit around, maybe there are some alternatives that are more up to date

• https://github.com/aome510/spotify-player
  • MPRIS support
  • can run as a daemon
  • latest release a week ago / Dec 24, using the latest librespot version
• https://github.com/devgianlu/go-librespot
  • used now in volumio
  • apparently no MPRIS support
  • rewrite in GO, not based on librespot
  • latest release this week / Dec 24

edit taking https://github.com/hifiberry/extension_spotifyd (master / Debian image) as a starting point, I got spotify-player to build quite easily. I think I'll give it a try (if I am correct, the extension system only relies on such a repo/container? I'm a bit confused as there are several spotifyd-artefacts in the hifiberry-os repo)

[Profoktor]

So, I did some digging into spotify-player. It does not expose the zeroconf-option, which means you have to provide credentials to get it running. At least for me, it is now out-of-scope.

On the other hand, spotifyd is still pretty active, though there have been no releases over a longer time. I guess it's best to wait for an update there (librespot-update is "in the works")