Spotify Sometimes crashes randomly? (Solved)

General discussion about RuneAudio. Do not post any support or feature requests here.

Spotify Sometimes crashes randomly? (Solved)

Postby irishwill2008 » 06 Dec 2016, 14:05

Since i bought premium i been using spotify a lot lately but i notice it some times has like seizures and spazzes out causing endless swirls of death (as i call them). In plain english, When i click the spotify tile the
Code: Select all
spinner-db
keeps spinning (not going into the hide class). Also causing the
Code: Select all
currentartist AND currentsong
to obtain:
Code: Select all
<i class="fa fa-spinner fa-spin"></i>
making them spin also!

Now i usually notice this some times when trying to click spotify to load the playlists but a few moments ago i was listening to some music and audio stopped playing! I decided to pop onto the player and noticed the artist and song with them swirls and also if you go into the queue area, there is nothing showing? Just black screen (with of course the header and footer showing) .. The play options on top and queue etc bar on bottom. But in the middle its just black! Not even the: Empty queue, click here. Or a showing of all my songs i had queued up etc.

Any idea?

Thanks!

Regards,
Will
Last edited by irishwill2008 on 14 Dec 2016, 15:41, edited 1 time in total.
irishwill2008
 
Posts: 157
Joined: 26 Jul 2016, 14:49
Location: Ireland

Re: Spotify Sometimes crashes randomly?

Postby irishwill2008 » 08 Dec 2016, 13:14

The fix i noticed is to restart the system (Reboot). And if your on spotify, switch back to MPD then back to spotify and it works again but i dont want to keep doing that everytime. Nor is it stable to play as it randomly crashes.. I might be listening to some songs and next thing, the player crashes causing these swirls and nothing working!

Hoping Frank can pop on and give me some help yet again! :D

Even if someone can tell me if its un-fixable at the moment and i have to wait, or its like a 2 lines of code fix or a simple switch or update :)

Thanks!
irishwill2008
 
Posts: 157
Joined: 26 Jul 2016, 14:49
Location: Ireland

Re: Spotify Sometimes crashes randomly?

Postby irishwill2008 » 09 Dec 2016, 17:37

When it crashed i decided to check the status of spopd so here it is:

Code: Select all
[root@touchradio ~]# systemctl status spopd.service
● spopd.service - Spop: a Spotify client daemon
   Loaded: loaded (/usr/lib/systemd/system/spopd.service; disabled; vendor preset: disabled)
   Active: failed (Result: signal) since Fri 2016-12-09 16:22:06 GMT; 14min ago
  Process: 6101 ExecStart=/usr/bin/spopd -f -c /etc/spop/spopd.conf (code=killed, signal=ABRT)
 Main PID: 6101 (code=killed, signal=ABRT)

Dec 09 16:21:56 touchradio spopd[6101]: 2016-12-09 16:21:56 [SPTF] 16:21:56.250 I [file_streamer_simple.cpp:769] Request for file 1c0240c20274f53effc0f8240d7
Dec 09 16:22:06 touchradio spopd[6101]: 2016-12-09 16:22:06 [SPTF] 16:22:06.544 I [file_streamer_simple.cpp:769] Request for file 1c0240c20274f53effc0f8240d7
Dec 09 16:22:06 touchradio spopd[6101]: ** (process:6101): ERROR (recursed) **: Can't flush log file: No space left on devicespop Copyright (C) 2010, 2011, 2
Dec 09 16:22:06 touchradio spopd[6101]: This program comes with ABSOLUTELY NO WARRANTY.
Dec 09 16:22:06 touchradio spopd[6101]: This is free software, and you are welcome to redistribute it under certain conditions.
Dec 09 16:22:06 touchradio spopd[6101]: See the COPYING file bundled with this program for details.
Dec 09 16:22:06 touchradio spopd[6101]: Powered by SPOTIFY(R) CORE
Dec 09 16:22:06 touchradio systemd[1]: spopd.service: Main process exited, code=killed, status=6/ABRT
Dec 09 16:22:06 touchradio systemd[1]: spopd.service: Unit entered failed state.
Dec 09 16:22:06 touchradio systemd[1]: spopd.service: Failed with result 'signal'.


I decided to check my disk as i seen it says no space? Here is the output:
Code: Select all
[root@touchradio ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.0G  1.9G  4.9G  29% /
devtmpfs        458M     0  458M   0% /dev
tmpfs           462M     0  462M   0% /dev/shm
tmpfs           462M   12M  450M   3% /run
tmpfs           462M     0  462M   0% /sys/fs/cgroup
tmpfs           462M   40M  422M   9% /tmp
logs            5.0M   28K  5.0M   1% /var/log
rune-logs       5.0M  5.0M     0 100% /var/log/runeaudio
/dev/mmcblk0p1  100M   18M   83M  18% /boot

Seems to be the logs folder has no more space ._.
irishwill2008
 
Posts: 157
Joined: 26 Jul 2016, 14:49
Location: Ireland

Re: Spotify Sometimes crashes randomly?

Postby irishwill2008 » 14 Dec 2016, 15:40

I fixed the issue by disabling spotify for logs. Turned out i was getting a lot of logs in runeui.log and was flooding the logs folder causing it to max out of space.

The fix was to disable spotify for logs, thanks to Franks help i was able to locate how to do so:

Logging can be disabled in the conf file (/etc/spop/spopd.conf)

# Path to the log file. If blank, messages will not be saved anywhere.
# Default is blank.
#log_file =


If you are in the same boat and had the same issue then this will fix!

P.s, i encountered another issue where when i had spotify set as active. If i rebooted the system, spotify would not load and crash for me cause of an address family issue (Network issue). But my network was grand? My guess which im still waiting on a confirmation from Frank was that my network device on the PI was booting after spotify tried to load? Causing it to die since spotify requires network ;)

My fix for this is as follows:

Added sleep for 1 second before trying to start the spopd service.
File: command/rune_SY_wrk
Code: Select all
// read activePlayer state
$activePlayer = $redis->get('activePlayer');
if ($activePlayer === 'MPD') {
    // check MPD process
    sysCmd('pgrep -x mpd || systemctl start mpd');
} elseif ($activePlayer === 'Spotify') {
    // check Spotify process
   sleep(1); //Wait another second to fix spotify at boot
    sysCmd('pgrep -x spopd || systemctl start spopd');
} else {
    // reset activePlayer state to MPD (default)
    $redis->set('activePlayer', 'MPD');
}


And:
Code: Select all
// start player backend
if ($activePlayer === 'MPD') {
    sysCmd('systemctl start mpd');
    usleep(500000);
    // set mpd start volume
    $mpd_volume = $redis->get('mpd_start_volume');
    if ($mpd_volume !== '-1') {
        sysCmd('mpc volume '.$mpd_volume);
    }
    // start upmpdcli
    if ($redis->hGet('dlna', 'enable') === '1') {
        runelog("service: UPMPDCLI start");
        sysCmd('systemctl start upmpdcli');
    }
    // start mpdscribble
    if ($redis->hGet('lastfm','enable') === '1') {
        runelog("service: MPDSCRIBBLE start");
        sysCmd('systemctl start mpdscribble');
    }
} elseif ($activePlayer === 'Spotify') {
   sleep(1); //Wait another second to fix spotify at boot
    sysCmd('systemctl start spopd');
}
irishwill2008
 
Posts: 157
Joined: 26 Jul 2016, 14:49
Location: Ireland

Re: Spotify Sometimes crashes randomly? (Solved)

Postby hondagx35 » 14 Dec 2016, 21:23

Hi

My guess which im still waiting on a confirmation from Frank was that my network device on the PI was booting after spotify tried to load? Causing it to die since spotify requires network ;)

This is absolutely correct, but there should be a better solution for this.
Spotify (spopd) and its implementation is the problem.
The systemd unit file for spopd uses already "After=network.target", but this seems be not enough.
I found a good description here.
Cut the crap! How do I make network.target work for me?

Well, that depends on your setup and the services you plan to run after it (see above). Many network management solutions provide a way to unconditionally pull in network-online.target, and thus upgrading the effect of network.target to the effect of network-online.target.

If you use NetworkManager you can do this by enabling NetworkManager-wait-online.service:

systemctl enable NetworkManager-wait-online.service

If you use systemd-networkd you can do this by enabling systemd-networkd-wait-online.service:

systemctl enable systemd-networkd-wait-online.service

This will ensure that all configured network devices are up and have an IP address assigned before boot continues. This service will time out after 90s. Enabling this service might considerably delay your boot even if the timeout is not reached. Both services are disabled by default.

Alternatively, you can change your service that needs the network to be up, to include After=network-online.target and Wants=network-online.target.

What does this mean for me, a Developer?

If you are a developer, instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration. That way you will make your users happy because things just start to work, and you will get fewer bug reports as your stuff is just rock solid. You also make the boot faster for your users, as they don't have to delay arbitrary services for the network anymore (which is particularly annoying for folks with slow address assignment replies from a DHCP server).


Frank
User avatar
hondagx35
 
Posts: 3042
Joined: 11 Sep 2014, 22:06
Location: Germany

support RuneAudio Donate with PayPal


Return to General discussion

Who is online

Users browsing this forum: No registered users and 2 guests