[PROBLEM] Auto-shuffle not working on Raspberry Zero with music library >33.000 flac files

[JST1963]

Obsolete (double)

[JST1963]

Well, I did some tests and found out that also the Pi3 has its limits. Here the max lies around 42000 songs (mixture of MP3 and FLAC).
Later on I will do the same test with a 3B+
I'm wondering if its the amount of songs or a time limit... once the ashuffle process goes beyond 60 seconds or 42000 songs it stops working (or crashes ?!?)

Johan

[Tim Curtis]

You might want to post an issue in the ashuffle Git and see if the dev has some insight into what might be happening. He is still actively maintaining the code :-)
https://github.com/joshkunz/ashuffle

-Tim

[JST1963]

You might want to post an issue in the ashuffle Git and see if the dev has some insight into what might be happening. He is still actively maintaining the code :-)
https://github.com/joshkunz/ashuffle

-Tim

Answer from Josh Kunz:

As currently written, ashuffle store a list of all (just the path to each file relative to the MPD root) songs in memory. On severely memory constrained devices like the RPi, with large libraries, it’s possible that just storing this list consumes more memory than is available on the device. I think there are two separate issues at play here:

1. Poor error handling in low-memory conditions.
   
2. Optionally storing library listing on disk.
   

Starting with (1): ashuffle’s current handling of allocation errors is poor, and I should make it crash in a more expected way. It’s likely that what is happening is either that ashuffle is getting OOM’d by the kernel when it starts consuming too much memory, or some allocations are failing and ashuffle is crashing. Either way, you should be able to look at the MoOde logs to see why ashuffle is failing to run. I’m not affilicated with moOde, and I’ve never used it, so I don’t really know how to do this, sorry.

For (2): Storing ashuffle data on disk is a reasonable request, and since ashuffle is bundled in systems like moOde, it seems like ashuffle is often run on large libraries in memory-constrained environments. I’ve opened issue #16 to track this.

I’ll leave this issue open until the fixes to (1) are committed

[Tim Curtis]

Nice :-)