Pi Zero W unresponsive

Looks like I get the same results with the library on a local USB drive. Left the Pi with no library for a couple of days and it was fine. Connected the disk with the library and it started indexing. Don’t know how far it got this time as the screen wasn’t showing the status when it went unresponsive.
Oh well - looks like my idea for a very small music streamer is now a potentially bigger, more expensive Pi !!

Source location of your file is not expected to change anything in that regard (just eventual impact on indexing speed).
Really seems like typical memory leak in indexing: some structures might not be released/purged/written to disk regularly in the process.

If by chance you have ssh access while Pi is crawling to death, you could check memory usage with top or free command.

I have a pi zero w, with I think around 1000 albums on a USB (mp3s). It does freeze up after updating music on the USB. It takes about 10 minutes for the initial indexing, but without freezing. Where it freezes is when I click on Artists (or I assume Albums) the first time. It’s frozen right now and I can’t even SSH in.

Last time this happened I think I just waited a few days and it was fine. Since this is happening on clicking Artists, I’m guessing the little pi is overwhelmed trying to add album covers.

Next time I’ll try adding files without disconnecting the USB - hopefully it only has to reindex the added files.

Would be nice to ssh-in before causing the freeze, and launch top command, and then observe report evolution after causing the freeze (which process takes-up CPU & memory, etc).

Just a hunch - it it possible to turn of the album art scanning of Volumio to check if the memory isueis from there? Or if its just mpd's database building that is choking the device?

I’m not sure it’s just album covers doing it. This time it froze for 4 days (since my last post) and I gave up and rebooted. I tried clicking on Artists and Albums, and it was slow to load covers but not that slow. I ran “top” on SSL, and CPU didn’t get past 50%, with a minimum 25M free in memory.

I then went to Settings and reset my album covers, Save, then clicked on Artist. CPU went as high as 91% briefly, but then back down. It’s (alphabetically) filling in all of the album covers without freezing. It only took a few minutes to load all of the album covers. I then clicked Album and had similar results (noticed 70% CPU max, 29M memory free min). Also only took a few minutes. Then I’m down to 1-2% CPU, still 29M memory free (475M total).

The next step is to replicate what makes it fail - maybe taking the USB out, adding some music, plugging it back in, rescanning, waiting for it to finish, then clicking Album. I’ll post back here when I find time to do that.

Here’s a clip of after I clicked to reload album covers then clicked Artists:

Interesting datapoint, even if not just at failure point.
We see Node is taking a significant chunk of memory already… Would be nice to see how this evolves during indexing and before/at failure.
Now, it seems strange swap is reported as 0, as default memory setup for PiZero is supposed to have swap (though this could be debatable since swap on SD has some big issues): have you tweaked configuration in some way?

I don’t think I’ve tweaked the configuration at all. The only plugins I have installed are NanoSound (which I haven’t been able to get to work - it reads my CD but doesn’t play) and Radio Paradise.

Here’s a random snapshot. It’s just been sitting, not playing music for a while. In case it’s helpful.

can you check output of one of the following?
dmesg | grep swap
swapon -s
cat /proc/swaps

Looks like I don’t have swapon?

So we have 2 issues here:
Original hang/crash may come from out of memory situation, which may be a fundamental memory leak issue that’d need investigation as a whole (Node process memory usage is a smoking gun that’d needs screening); it would be beneficial for any device. Let’s call it Issue 1 to investigate.

For some reason swap is not enabled on your device (Volumio is supposed to enable it by default on PiZero): Issue 2.
By fixing Issue 2 we may hide fundamental Issue 1, while inheriting a performance penalty hit, and increased SD corruption risks.

So, let’s look at Issue 2 for now, what gives:
sudo /bin/dynswap.sh
and then check cat /proc/swaps and free

@MattG also please cat /etc/os-release :slight_smile:

EDIT: This might be the cause for swap issues?

512 MB or less RAM Detected, need to enable swap
Enabling Swap
swapon: /data/swapfile: swapon failed: Invalid argument
Setting swappiness to 40
vm.swappiness = 40

-bash: /proc/swaps: Permission denied

         total       used       free     shared    buffers     cached

Mem: 475268 432292 42976 4868 49076 155916
-/+ buffers/cache: 227300 247968
Swap: 0 0 0

PRETTY_NAME=“Raspbian GNU/Linux 8 (jessie)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“8”
VERSION=“8 (jessie)”
ID=raspbian
ID_LIKE=debian
HOME_URL=“http://www.raspbian.org/
SUPPORT_URL=“http://www.raspbian.org/RaspbianForums
BUG_REPORT_URL=“http://www.raspbian.org/RaspbianBugs
VOLUMIO_BUILD_VERSION=“74e4cc9de715c64d553d35948d017f973a622b6d”
VOLUMIO_FE_VERSION=“2be6c28eb9de74ec1f9662ca333f7bd51a232c33”
VOLUMIO_BE_VERSION=“259a7f2894e1376413ffac331be84e0e9a6173dd”
VOLUMIO_ARCH=“arm”
VOLUMIO_VARIANT=“volumio”
VOLUMIO_TEST=“FALSE”
VOLUMIO_BUILD_DATE=“Thu Sep 24 22:42:43 CEST 2020”

VOLUMIO_VERSION=“2.834”
VOLUMIO_HARDWARE=“pi”
VOLUMIO_HASH=“e41ef0f29aa50c1af109d3064a380c69”

good catch @ashthespy!
Will try to look into it

In the name of science I started with a clean install of Volumio with no plugins. First of all the 2.834 version didn’t work at all, so I installed 2.729 and then upgraded within the software (worked).

Same behavior - no swap file and “swapon failed” when I ran the sudo /bin/dynswap.sh

@MattG Issue is being investigated (see Github link @ashthespy provided) , and it’s still unclear since which version, swap setup started to fail, nor when a definitive fix is available in later versions.

So far, I’ve a (simple) workaround (change /data/ into /imgpart/ within /bin/dynswap.sh), but it may compromise future updates…
You may track that Github issue to monitor when definitive change is eventually implemented.

@MattG swap fix is implemented: it should show-up in next release post 2.852

Will be interesting to know if it alleviates big database indexing problems.

2 Likes

Put me in my place if you feel like I am hijacking but:
I found this topic trying to explore the reasons for my suddenly incredibly slow Volumio (RPi2). I have loads of other things installed on top of Volumio (shame on me, I know), because I test that particular RPi as 433 sniffer as well. Everything worked fine (for days when all this was installed) up to a point today when I found out that mpd failed. I got same error like mentioned here: mpd broken in Volumio 2.5.26 so I went on with building libbcm_host.so as suggested. While tinkering with that, I realised that RPi is getting really sluggish. Wanted to check RAM but could not get to RPimonitor anymore. Several reboots later I found out that I have no swap enabled. First I tried to edit dynswap.sh, replace /data/ with /imgpart/. Reboot, no change. Then I updated to the latest volumio version (2.852), nada. I Checked github and manually edited dynswap.sh (which looked exactly the same as before update) to mirror the last version (/data/ replaced with /swap/ and so on). Another reboot, no luck.
I tried manually run sudo dynswap.sh but it seems not to do anything at all.
Any thoughts?

@Aaron, sorry but totally different issue : focus here is on PiZero; please open a different thread.
BTW, RPi2 will not activate swap anyway, as it has more than 512K RAM.

Yes Sir!
Anyway, probably have my answer already, thanks!