[PROBLEM] Spotify connect keeps dropping

[Tim Curtis]

You can also try running librespot in debug mode from SSH :-)

1. Turn Spotify OFF in Audio config

2. Get your default audio device name. Example below.

Code:

pi@rp3:~ $ aplay -L | grep -v ALSA | grep -w default
default:CARD=Katana

3. Run librespot with verbose (-v) logging where you substitute your Spotify name and audio device for my "RP3 Spotify" and "default:CARD=Katana" 

Code:

pi@rp3:~ $ sudo librespot -v --name "RP3 Spotify" --bitrate 320 --initial-volume 0 --cache /var/local/www/spotify_cache --disable-audio-cache --backend alsa --device "default:CARD=Katana" --onevent /var/local/www/commandw/spotevent.sh

[PhotonHerder]

Post more information about your issue for example:

- has librespot crashed?
- did your network connection drop?
- any errors in syslog?
- how much free disk space is left?
- etc

Hi Tim, my network is stable.  I don't know how to check the other things.  I'm an engineer but not a software guy.  You're welcome to log into my pi.  PM me at rick.yarussi@gmail.com and I'll give you it's IP address.

[Tim Curtis]

moOde is a great way to learn some Linux SSH :-)

Open System config and turn on the SSH term server. Then OPEN it and enter userid = pi and password = moodeaudio.

Then follow my instructions in post #11

[PhotonHerder]

moOde is a great way to learn some Linux SSH :-)

Open System config and turn on the SSH term server. Then OPEN it and enter userid = pi and password = moodeaudio.

Then follow my instructions in post #11

Sorry but I really don't have time to learn linux to troubleshoot this. I'm super busy, and I thought getting this running was going to be easy. It wasn't.  The instructions were wrong, and were poor in general.  It took me two hours of trial and error to figure it out on my own.  And now it doesn't work reliably, and I've spent another two hours fighting with it. 

The instructions in post 11 may be clear to you, but they are not to me.  What "Spotify name"?  My Spotify user name?  Anyway, this appears to turn on librespot (whatever that is) with more logging.  Then how do I get the logs?  

I'll go one more iteration and then I'm giving up.  I just don't have time to spend on this.  I offered to let you log into my pi.

[ksone]

moOde is a great way to learn some Linux SSH :-)

Open System config and turn on the SSH term server. Then OPEN it and enter userid = pi and password = moodeaudio.

Then follow my instructions in post #11

Very funny Tim!

Yes, moOde indeed forces one to learn Linux... 

My issue is that librespot dont reconnect. It's not a local network issue, as it happens on different locations. And its quite random, restarting librespot fixes the issue instantly - but quite annoying to do so.

Have you seen this thread on librespot repo? 
https://github.com/librespot-org/librespot/issues/134
The random stop working issue is a known issue, and they(devs) have a hard time getting it solved.

A user came up with a "fix" .. Its not really a fix; just a bandaid.

https://github.com/librespot-org/libresp...-441499150

Is there any way to mitigate this problem?
Is it possible to somehow detect that it disconnected and restart it manually (using some shell script)?

This doesn't address the cause but aids with the symptoms:
https://gist.github.com/JeremieRapin/bc3...503270df16
Script to be run as a cronjob every minute which checks the status and restarts the service if an error is spotted.

Code:

#!/bin/sh



# Add the following line in /etc/crontab

# * * * * * root /home/pi/watchdog.sh

#



status=$(sudo systemctl status raspotify | grep -E "(WARN|ERROR|101)")



if [ ! -z "$status" ]; then

    sudo systemctl restart raspotify

fi

systemctl dont show the status of librespot, as its run as part of rc-local.service in moOde. 
"systemctl status librespot" shows = "Unit librespot.service could not be found."

I dont have the faintest idea of how to get systemctl to show the status of librespot  

systemctl status rc-local:

Code:

pi@radio:~ $ sudo systemctl status rc-local                                                                                                                                                                                
● rc-local.service - /etc/rc.local Compatibility
  Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)                                                                                                                                  
 Drop-In: /lib/systemd/system/rc-local.service.d                                                                                                                                                                          
          └─debian.conf                                                                                                                                                                                                  
       /etc/systemd/system/rc-local.service.d                                                                                                                                                                            
          └─ttyoutput.conf                                                                                                                                                                                                
  Active: active (running) since Wed 2018-11-28 09:14:49 CET; 21min ago
 Process: 466 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)                                                                                                                                              
  CGroup: /system.slice/rc-local.service                                                                                                                                                                                  
          ├─ 479 /usr/bin/udisks-glue                                                                                                                                                                                    
          ├─ 514 /usr/bin/php /var/www/command/worker.php                                                                                                                                                                
          ├─ 812 sudo /usr/local/bin/shairport-sync -a Moode Airplay -S soxr -w -B /var/local/www/commandw/spspre.sh -E /var/local/www/commandw/spspost.sh -- -d hw:0                                                    
          ├─ 821 /usr/local/bin/shairport-sync -a Moode Airplay -S soxr -w -B /var/local/www/commandw/spspre.sh -E /var/local/www/commandw/spspost.sh -- -d hw:0                                                          
          ├─ 831 sudo librespot --name Moode Spotify --bitrate 320 --initial-volume 92 --cache /var/local/www/spotify_cache --backend alsa --device default:CARD=sndallodigione --onevent /var/local/www/commandw/spoteven
          ├─ 839 librespot --name Moode Spotify --bitrate 320 --initial-volume 92 --cache /var/local/www/spotify_cache --backend alsa --device default:CARD=sndallodigione --onevent /var/local/www/commandw/spotevent.sh
          ├─1014 /bin/bash /var/www/command/watchdog.sh                                                                                                                                                                  
          └─5370 sleep 6                                          

and pgrep:

Code:

pi@radio:~ $ pgrep -l librespot
839 librespot

I cant recall what it shows with its not working
( I will update when it occurs again)

So this fix doesnt work out of the box when using moOde

Any help?

[TheOldPresbyope]

@ksone

I haven't experienced this random drop out (yet, he says with his fingers crossed!).

*If* the symptom is that the librespot process disappears and if this is a randomly occurring event which isn't due to something like an out-of-memory problem, then it would seem a watchdog could be created to implement something like "if airplay renderer is enabled in moOde and if librespot process is missing, then restart librespot [not raspotify]". The restart must include all the parameters which Tim outlined in his port.

This is a horrible way to deal with the underlying problem. With the Spotify app on my iPad, I'd still have to reconnect to moOde once librespot restarted, but desperate times and all that. I for one am not going to try to debug a problem the librespot developers apparently haven't solved in 11 months. That's way beyond my pay grade.

Regards,
Kent

[TheOldPresbyope]

@PhotonHerder

It isn't clear what the underlying problem is.

In the meantime, you have the option of running the Spotify app on your iPhone and streaming the output to moOde via either Airplay or Bluetooth.

Regards,
Kent

[PhotonHerder]

@PhotonHerder

It isn't clear what the underlying problem is.

In the meantime, you have the option of running the Spotify app on your iPhone and streaming the output to moOde via either Airplay or Bluetooth.

Regards,
Kent

Airplay and BT are low quality. Spotify is already compressed, and I don't want to make it worse. I will hear it on my system. 

Moode shouldn't be this difficult. There's nothing unusual about my setup - Pi3B, Allo DigiOne, Windows 10.  It should just work. 

I cant work on this anymore so I'm going to switch to Volumio.  I may try moode again when a new version comes out, but if Volumio works then I'll probably have no reason to switch back.

[Tim Curtis]

I really don't see the point to your thread or even your forum membership if you are not willing to spend any of your own time working with the moOde dev's to help troubleshoot your particular issues.

The Open Source community is based on people contributing their time and effort to solve problems, develop code and improve the projects.

-Tim

[ksone]

@ksone

I haven't experienced this random drop out (yet, he says with his fingers crossed!).

*If* the symptom is that the librespot process disappears and if this is a randomly occurring event which isn't due to something like an out-of-memory problem, then it would seem a watchdog could be created to implement something like "if airplay renderer is enabled in moOde and if librespot process is missing, then restart librespot [not raspotify]". The restart must include all the parameters which Tim outlined in his port.

This is a horrible way to deal with the underlying problem. With the Spotify app on my iPad, I'd still have to reconnect to moOde once librespot restarted, but desperate times and all that. I for one am not going to try to debug a problem the librespot developers apparently haven't solved in 11 months. That's way beyond my pay grade.

Regards,
Kent

After a few days Librespot decided yet again on one of my pi's to stop working.
It was expected.. librespot just vanish.

I promised to give an update with what I could find.

"pgrep -l librespot" shows nothing and "systemctl status rc-local" shows that librespot disappears:

Code:

pi@radio:~ $ sudo systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)
  Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
        /etc/systemd/system/rc-local.service.d
           └─ttyoutput.conf
   Active: active (running) since Fri 2018-11-30 16:13:08 CET; 5 days ago
   CGroup: /system.slice/rc-local.service
           ├─  463 /usr/bin/udisks-glue
           ├─  505 /usr/bin/php /var/www/command/worker.php
           ├─  819 sudo /usr/local/bin/shairport-sync -a Radio (Airplay) -S soxr -w -B /var/local/www/commandw/spspre.sh -E /var/local/www/commandw/spspost.sh -- -d hw:0
           ├─  828 /usr/local/bin/shairport-sync -a Radio (Airplay) -S soxr -w -B /var/local/www/commandw/spspre.sh -E /var/local/www/commandw/spspost.sh -- -d hw:0
           ├─ 1029 /bin/bash /var/www/command/watchdog.sh
           └─17488 sleep 6

Dec 05 22:15:11 radio sudo[17433]: pam_unix(sudo:session): session closed for user root
Dec 05 22:15:14 radio sudo[17442]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/pgrep -l bluealsa-aplay
Dec 05 22:15:14 radio sudo[17442]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 05 22:15:14 radio sudo[17442]: pam_unix(sudo:session): session closed for user root
Dec 05 22:15:17 radio sudo[17462]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/pgrep -l bluealsa-aplay
Dec 05 22:15:17 radio sudo[17462]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 05 22:15:17 radio sudo[17462]: pam_unix(sudo:session): session closed for user root
Dec 05 22:15:20 radio sudo[17478]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/pgrep -l bluealsa-aplay
Dec 05 22:15:20 radio sudo[17478]: pam_unix(sudo:session): session opened for user root by (uid=0)
Dec 05 22:15:20 radio sudo[17478]: pam_unix(sudo:session): session closed for user root

plenty of mem and root left
ROOT avail = 3.9G
MEM free = 206 MB

"h t t p://xx.xx.xx.xx/snd-config.php#spotify-restart" instantly fixes it.


Strange thing is that other Pi is still running without issues...(on another network) - its so bloody strange

Regards