Music not accessible after index and reboot - Solved

description: upgraded to 2.504, ran a music index on a large nfs mounted music share. the indexing took about 12 hours, but appeared to succeed and showed reasonable statistics in “My Music” (this is a large share, which may or may not be relevant - there are over 200,000 tracks.) Restarted system using the UI, and the music library is now empty. Also, “My Music” shows no content - does not summarize artist/album/track information. volumio.log has an info message that repeats every 4-5 seconds after attempting to access the library: info: CoreCommandRouter::executeOnPlugin: mpd , getMyCollectionStats It wasn’t clear to me whether this was a repeated attempt to read data, or sequential reads of data entries, but I left it overnight and nothing completed.

I believe the reboot kicked off an automatic scan (can someone confirm volumio works this way?). The scan is failing, perhaps due to permissions problems (see socket error below), so although the volumio database is healthy it can’t be accessed.

Note the nfs share is mounted properly, confirmed by df -k as well as “My Music”'s green check. Also, I can browse the share from a shell on the pi. As for the database, both the music and the tag cache appear fine in /var/lib/mpd/music and /var/lib/mpd/tag_cache and are browsable: the music library is there, I just can’t access it from the volumio UI.

related problems: I have seen this issue in previous upgrades (it only seems to happen intermittently), and there are also quite a few messages in this forum and elsewhere with closely related issues, some giving the same “executeOnPlugin” messages as shown above. In one case, the user states they solved their problem as a permissions problem for files - it appears mpd could not access files properly. fixed by changing permissions on the music files. Here are just examples of problems that appear related, from a cursory look: (this is volumio2, but seems to be very similar)

Regarding permissions, in my case, I see the following:
/var/lib/mpd/music: root:root, permissions 755
/var/lib/mpd/music/NAS: symbolic link to /mnt/NAS, root:root, 777
/mnt/NAS: root:root, 777
/mnt/NAS/music: 1001:1004, 777

I note that uid 1001 and gid 1004 are not present in /etc/passwd or /etc/group: they are my user and group ids on the debian fileserver, but the permissions are 777 in this case anyway.
do the user and group ownerships of nfs mounted music files need to match some <uid, gid> on volumio?

log messages: When I try to access music while running “tail -f /var/log/volumio.log”, I see 2 messages repeating every few seconds. The first is the info message listed in the description paragraph above. The second is an mpd error message: error: MPD error: Error: connect EAGIN /run/mpd/socket. I did not originally have the error message: it showed up when I attempted to browse by genre.

finally, to complete this, I will mention that I have 2 pi systems running volumio: the other system is a pi3 running 2.457, and has mounted the same NFS mounted filesystem, indexed, and plays successfully. the system with the problem is a pi 2 running 2.502. Neither system has any peripherals, though the problematic system has a justboom digi-hat configured to output digital to an external DAC.

got no replies to this post, though it identified an issue with indexing after a very vanilla install. We have determined this is an issue with mpd and music index size. I had mentioned the possibility that this was the case, and we confirmed it by removing part of the tag_cache. Several tests with removing different parts of the cache from 2 different volumio installs showed that with a smaller index, everything worked fine. We didn’t find the precise limit, but I can state with some certainty that mpd can handle 200K tracks, but cannot handle 230K. (mpd fails to start with the larger number). this is repeatable.

so, I’ve done a workaround, spreading the music across 2 volumio/raspberry pi systems connected to the same external DAC. With no other changes, I’ve had no further issues. Until the mpd team addresses this scaling limitation, volumio users with large repositories should be aware of this, and perhaps the limit could be more precisely quantified and addressed in the volumio FAQ to prevent others from spending a lot of time on this. Offhand, I note that 230K is approaching 256K, so one possibility is over-running a 16 bit pointer…