Hi
Is there a limit to the number or size of music library a Pi Zero W will cope with ?
I have set up my device numerous times with different SD cards, different brands, different Volumio builds.
I can do the initial setup fine and if I leave it with no library set up it seems to work away fine. If I add my music library it starts running through the scan OK but at a certain point it becomes unresponsive- both web interface and ping. This takes a LONG time so I don’t know if it stops at the same point each time.
The library is about 1TB in size (mainly FLAC) and over 50,000 files.
The last time the device hung I could see the screen had frozen at 67318 tracks.
Music is stored on a Synology NAS but I have also tried copying the library to a Windows PC and sharing this. Same results.
I also tried a Pi4 connected to the same library and it seemed to be fine so I’m assuming the PiZero just can’t cope ?
Sorry if the message is long winded but thought it best to try to give as much info as possible.
Thanks
PiZero is very limited, I definetely suggest to upgrade to PI4 
While PiZero have limited capabilities, there’s plenty of CPU power just to do simple things like indexing and audio playback in theory (live-transcoding can eventually be debatable).
Pi4 is probably totally overkill for Volumio audio usecases.
Of course throwing-out more cores, more MHz, more RAM, more Watts improve things, but it would rather be interesting to clearly understand where the actual bottlenecks are, and how they can be possibly handled better.
(i.e I remember times of unzipping implemented through a Node lib: that was highly non-optimal in terms of performances/RAM consumption, and killed devices on plugin installs; things greatly improved after using native code for that).
I’m unsure where indexing issues may be (database management, RAM usage (& swap), albumart download/access/storage, etc), and the seemingly 68K boundary you mention is a bit suspect…
For instance, do you have same issue if you do not pull-in albumarts?
The main bottleneck is not enough ram, which then results in swapping to sd card which is super slow.
With later pi models available we focused our efforts on improving multicore sharing of cpu load, hence a single core cpu is particularly slower on some operations, typically albumart fetching.
Thanks for initial feedback.
Which processes are taking so much RAM for indexing then?
It seems very curious such simple indexing thing eats-up so much RAM: maybe room for optimizations?
(I disabled swap on my PiZeros, and they run Volumio fine. I do not have a big db to index though, as I mostly use internet streams)
It would be quite interesting to see some profiling of the Volumio backend - I wonder if anyone has done anything so far? I do believe there are quite a few low hanging fruit that we could pick to make the system leaner…
Yes, most probably.
Fortunately, Node v8 has some built-in profiling tools, plus there are 3rd party such as Clinic & al.
Using limited devices like PiZero to undertake such diagnostic might prove being a good way to catch most critical things. Initial indexing might be a good usecase to start with (find potential memory leaks, etc).
Wish I had good-enough Node expertise to play with that… 
Hi
Thanks for all the replies.
I was just hoping that someone else might have been using a Pi Zero and might know the limitations when using Volumio.
Yes, using the Pi4 seems to work but, as macmpi says, it’s a bit of overkill and I was going to use it for something else.
How do I prevent album art from being indexed ?
I’m going to try copying the library to a USB disk and try plugging this in locally and see what happens. But it’s not something I would want as a long term solution. I wanted the PiZero to work due to the small size etc - don’t really want a disk (and power supply) hanging off the side of it 
Thanks
I have a Pi 0 on a secondary system. Also have a Pi 4 and previously had a Pi 3.
My only problem with Pi 0 is that it’s harder to get connection to my wi-fi (granted, in a not optimal position…). When it connects, it’s a bit slower than the Pi 4, but I can live with that.
Regarding sound quality, it’s good enough to use on a valve heaphone amp with some vintage high impedance Beyerdynamic and Sennheiser HD650 (the Massdrop version).
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
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