High load on pi after two days

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! :wink:

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! :blush:)
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? :wink:

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.