Issue with versions 3.6.16 and 3.6.31 on Raspberry Pi 4
When I try command “volumio vrestart” and to access the Source menu, which contains 14551 albums (161433 tracks), there is a 15-20 second delay in loading. Upon checking the CPU load using htop, it shows a load of 120%.
Every time I turn on the device, it takes longer to display the user interface.
My tag_cache: 5MB
Here are the logs for reference:
http://logs.volumio.org/volumio/dP7YOkv.html
could you please enable test-mode and try with v3.632?
3.632 logs:
http://logs.volumio.org/volumio/qpVPPkx.html
I had the same issue.
@Darmur, I can share the ‘tag_cache’ with you if you need it for testing.
It is impossible to have a CPU occupancy rate greater than 100%, you seem to be highlighting a small bug in htop…
Moreover, when we look at the details of the processes running and add them up, we arrive at 32.7% CPU usage which is already a lot in itself (9.2+8.5+7.8+6.5+0.7) .
Regards.
@Phil I am unable to play music. Every time I turn on the device and access ‘My Music,’ it appears empty. Accessing ‘Music Library’ takes a considerable amount of time, sometimes 3 to 5 minutes. It requires multiple attempts before the music folders are displayed.
For what it’s worth, I am having the very same issue as the op with a similarly large library on a hard drive connected via USB. I have only (mostly) solved it by reducing the size of my library–an obviously unhappy situation.
@Lam_Nguyen the first log showed a device “kiki” on /dev/sdb1, the second log does not mention /dev/sdb1 at all. Was it connected?
Updated today to 3.6.31 and having the same issue and symptoms. USB device seems to be mounted, in fact after a very long lag I can see the artist/albums/tracks counted in Sources. I my case, if I just unplug the usb drive Volumio is still lagged, like frozen a couple of minutes for every operation. Sometimes, from nowhere, it displays the ‘configuration saved’ message and auto reboot. I wanna beat myself for press the damn update button 
Some people have reported having issues with music libraries that are too large and with the latest version of Volumio. They stated that they resolved their issue by enabling “Test Mode” updates in http://volumio.your.adress.ip/dev (http://192.168.x.x/dev) and then updating update via Volumio’s system preferences.
I can’t tell you more…
@Liam_Nguyen
From the logs - boot takes 1 min and 45 sec, which is an average on SD cards. Else volumio app processes with a bit glitch on Highresaudio conf. Nothing stands out.
As @gkkpch pointed out already - there was /dev/sdb1 in one log and is gone in the second; as such test is incoherent since test parameters have changed. Yet again - nothing stands out.
Would be possible for you to share additional information?
Output from mpd version
Furthermore - two tests:
From the cold boot (IMPORTANT!) and from reboot (IMPORTANT!) once the UI loads and responds and you can use Volumio again:
Compressed /var/log/mpd.log file
Output from scripts and commands:
for src in arm core h264 isp v3d uart pwm emmc pixel vec hdmi dpi ; do \
echo -e "$src:\t$(vcgencmd measure_clock $src)" ; \
done
for id in core sdram_c sdram_i sdram_p ; do \
echo -e "$id:\t$(vcgencmd measure_volts $id)" ; \
done
for codec in H264 MPG2 WVC1 MPG4 MJPG WMV9 ; do \
echo -e "$codec:\t$(vcgencmd codec_enabled $codec)" ; \
done
vcgencmd get_config int
vcgencmd get_mem arm && vcgencmd get_mem gpu
About the “kiki” device on /dev/sdb1, I don’t store music there; it’s a USB disk with only a few tracks for testing purposes. My music is stored elsewhere.
Every time after rebooting, clicking on the Music Library takes a long time to load, or clicking on Sources results in an empty screen.
I tried code comment: //self.listAlbums(); and //self.getMyCollectionStats(); in ControllerMpd.prototype.mpdEstablish, and it seems to solve the problem temporarily, eliminating the delay. I understand that this is not a good solution.
Currently, I am using the LMS plugin to scan the entire music library, which may take quite a while to complete. Only then can I proceed to review the “Output from scripts and commands:” and MPD logs.
The whole point of collecting mpd data is to understand what happens after system boot stage and before UI is ready. There were frequent {EPIPE: Error} shown in in the past as evidence of a source connection persistence being dropped prematurely or protocol timing factors as well as mpd database ballooned padding. These events are only seen in the /var/log/mpd.log file. Also, we observed oversensitivity to various non-media directly related files within media sources folder/file hierarchy. The mpd post boot stage performs additional actions compared to mpd at user-space stage use.
Scripts and commands are to check your device health (silicone lottery) and dig further if something stands out.
Enabling “Test Mode” and updating did not solve the problem for me.
Personally I changed the OS for my RPi5 audio server, I made my own 100% free installation, for several reasons:
Volumio is partly paid, which goes against ethics under Linux. On top of that, it’s rather expensive for what it is. Asking €5.85 per month for an RPi is not very moral in my opinion. This forces Tidal users to pay 50% more for their basic subscription ;-(
Volumio is based on Debian 10 Buster which is obsolete and no longer patched, except for its kernel.
[Moderated by Wheaten]
I have removed your last line We still following GDPR and don’t share private communication on a public available platform.
Regards.