I notice high load and stuttering at the beginning of a song after the pi is online for a few hours.
freshly booted, there is no problem at all, and the system load is pretty much at a low level. But after playing a few songs and playlists for a few hours, the system load is high and at the beginning of a new song there’s much of stuttering before the song plays well until the end.
here’s what “top” says about it:
top - 12:18:50 up 2 days, 6:07, 2 users, load average: 2.06, 1.74, 1.27
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 88.9 us, 8.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 2.6 si, 0.0 st
KiB Mem: 496764 total, 421732 used, 75032 free, 22808 buffers
KiB Swap: 0 total, 0 used, 0 free, 233704 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2640 mopidy 20 0 453m 107m 10m S 95.4 22.1 198:20.30 mopidy
30 root 1 -19 0 0 0 S 1.0 0.0 4:06.74 VCHIQ-0
1893 root 20 0 197m 44m 17m S 1.0 9.1 6:10.03 gmediarender
2738 root 0 -20 0 0 0 S 0.7 0.0 4:08.03 kworker/0:1H
8968 root 20 0 3144 1348 916 R 0.7 0.3 0:00.28 top
3 root 20 0 0 0 0 S 0.3 0.0 0:27.17 ksoftirqd/0
1 root 20 0 2148 728 624 S 0.0 0.1 0:07.53 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0.0 0.0 0:43.69 rcu_preempt
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_sched
10 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
12 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 netns
13 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
14 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kblockd
16 root 20 0 0 0 0 S 0.0 0.0 0:00.22 khubd
17 root 20 0 0 0 0 S 0.0 0.0 0:03.11 kworker/0:1
18 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 rpciod
19 root 20 0 0 0 0 S 0.0 0.0 0:00.13 khungtaskd
20 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 fsnotify_mark
22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 nfsiod
23 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto
29 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kthrotld
31 root 1 -19 0 0 0 S 0.0 0.0 0:21.99 VCHIQr-0
32 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 VCHIQs-0
33 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 iscsi_eh
34 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 dwc_otg
35 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 DWC Notificatio
37 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 deferwq
39 root 20 0 0 0 0 S 0.0 0.0 30:27.04 mmcqd/0
40 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 ext4-rsv-conver
Is this specifically when playing back Spotify songs and are these songs ones you have not played on the system before (i.e. they are not in the cache) or is this across all backends?
Also, just for clarity, are we talking hours or days here? Your topic title says days but the description says hours.
I use Pi Musicbox for Spotify only. Is there a cache mechanism for Spotify songs? Then I must check, as I don’t know, whether the songs were played before.
and for clarity: the load comes usually within hours and I let the Pi running for two days. sorry for the misleading headline.
Some background information:
- Pi is online with LAN, not WIFI
- Pi is 0.5 version of pi musicbox
- only thing I changed in the ini: SSH activated and Mono-Output (output = capsfilter caps=“audio/x-raw-int,channels=1” ! autoaudiosink)
Spotify has a cache for all data, the location of which is specified in the config options. I don’t think it’s possible to tell what’s actually in there but if you delete the file and then play a couple of songs, you should be able to see if playing the same one twice has the same problem.
Can you try not mixing to mono? Sounds to me like that will consume cpu.
ok. just added a completely new Spotify-playlist and now trying to reproduce.
For the test also deactivated mono-mixing. We’ll see! 
The odd thing is, after restarting the mopidy-daemon the load (of mopidy) still is high. only a reboot brings the load down.
ok. disabling mono seems to do the trick… After intensive use of spotify, there isn’t stuttering or high load. which is disappointing, because I use the pi musicbox with only one roof-loudspeaker in each room (therefore stereo isn’t perfect! 
)
Is this due to the pi’s perfomance? I think, it’s due to some kind of memory-leak or something?
Thx,
Thomas.
If it was a memory leak I think the system would lock up at some point. You could always just monitor the system memory over a long period to verify this.
I think it’s more likely to be the pi’s cpu that’s letting you down. It’s
not that powerful. But if it is this then you’d have expected
overclocking to have helped. Is it worse when underclocking? If you try playing some local tracks with the mono caps reapplied then you can hopefully rule out a gstreamer issue in the Spotify playback pipeline.
Perhaps you could tinker with the Spotify quality settings? Perhaps there
are gstreamer buffer settings that’ll help? Does it make a difference if you
change your alsa config to mono, possibly pushing the mixing into alsa
code? Any ideas @adamcik?
[quote=“kingosticks, post:7, topic:186, full:true”]If it was a memory leak I think the system would lock up at some point. (…) I think it’s more likely to be the pi’s cpu that’s letting you down. It’s
not that powerful. [/quote]
hmm… My thoughts were just, because there isn’t a problem until some longer use of spotify…
[quote=“kingosticks, post:7, topic:186, full:true”]But if it is this then you’d have expected
overclocking to have helped. Is it worse when underclocking? If you try playing some local tracks with the mono caps reapplied then you can hopefully rule out a gstreamer issue in the Spotify playback pipeline.
Perhaps you could tinker with the Spotify quality settings? Perhaps there
are gstreamer buffer settings that’ll help? Does it make a difference if you
change your alsa config to mono, possibly pushing the mixing into alsa
code? Any ideas @adamcik?
[/quote]
I’ll have a try with those suggestions over the weekend, and let you know!
Thanks for your help so far!
Thomas.
After some weeks of tweaking all kind of stuff, I came back to just add my spotify-credentials to the config, leaving the rest “as is” from the musicbox 0.5 image.
now even with stereo i get this on “top”:
top - 08:50:20 up 5 days, 17:08, 1 user, load average: 1.97, 1.69, 1.48
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 85.6 us, 12.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 1.6 si, 0.0 st
KiB Mem: 496764 total, 344056 used, 152708 free, 12788 buffers
KiB Swap: 0 total, 0 used, 0 free, 176452 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2571 mopidy 20 0 595m 107m 13m S 90.4 22.1 714:29.17 mopidy
39 root 20 0 0 0 0 S 5.9 0.0 73:47.33 mmcqd/0
2671 root 0 -20 0 0 0 S 1.3 0.0 4:18.58 kworker/0:1H
30 root 1 -19 0 0 0 S 1.0 0.0 3:37.93 VCHIQ-0
12845 root 20 0 3140 1252 932 R 0.7 0.3 0:01.48 top
3 root 20 0 0 0 0 S 0.3 0.0 0:35.19 ksoftirqd/0
7 root 20 0 0 0 0 S 0.3 0.0 1:43.07 rcu_preempt
1 root 20 0 2148 728 624 S 0.0 0.1 0:16.33 init
some ideas?
greets,
Thomas.
When using musicbox you will get stuttering at the start of songs if you are playing one of the later songs in a large queue (or large collection of search results). This is a known issue and there is a fix but I’m not sure it’s in the latest release since it apparently doesn’t work for gmusic.
You should also try disabling the Spotify cache by setting cache_dir = in the settings. Take a look at https://github.com/mopidy/mopidy-spotify/issues/26 for some more info on this. My guess is that once the cache gets more full it requires more processing to identify cache hits and/or do replacements.
But in both cases I’ve never seen it stay this high for more than a few seconds at the start of songs.
And just to clarify, stuttering at the start due to long queue is a musicbox Webclient issue, other clients (I.e moped) don’t have this problem.
I hope this is fixed in the new RC 0.5.1 now. I included fixes for Webclient and the cache.