mpc and mpd package went trhough just fine for me. I’ll be running rescans to see how it goes with them.
However, the liburing1 seems to be missing something. Could you give me an advice on that?
volumio@volumiio:~/mpd_new$ sudo dpkg -i liburing1_0.7-3~bpo10+1_armhf.deb
(Reading database ... 147470 files and directories currently installed.)
Preparing to unpack liburing1_0.7-3~bpo10+1_armhf.deb ...
Unpacking liburing1:armhf (0.7-3~bpo10+1) over (0.7-3~bpo10+1) ...
Setting up liburing1:armhf (0.7-3~bpo10+1) ...
Processing triggers for libc-bin (2.28-10+rpt2+rpi1+deb10u2) ...
ldconfig: /lib/arm-linux-gnueabihf/libnss_mdns6.so.2 is not a symbolic link
ldconfig: /lib/arm-linux-gnueabihf/libnss_mdns4_minimal.so.2 is not a symbolic link
ldconfig: /lib/arm-linux-gnueabihf/libnss_mdns4.so.2 is not a symbolic link
I think that you have downloaded HEAD of github static assets and they all are the exact same size. Can you confirm?
The debs should be downloaded as “raw” source where the resulting url for wget will change like this:
…/volumio3-mpc/blob/main/packages/static/mpc_0.34-2_armhf.deb
…/volumio3-mpc/raw/main/packages/static/mpc_0.34-2_armhf.deb
I don’t think you will need mpd_0.23.14-3_armhf.deb, only mpd_0.23.15-1_armhf.deb.
This usually indicates that there is another library in the ldconfig cache either with the same name and different version or some additional paths are in use.
Based on the size of your database (Reading database ... 147470 files and directories currently installed.) this is quite (for a player) large.
Let’s try something:
Duplicate paths and references: cat /etc/ld.so.conf.d/*
Duplicate libraries with the same name: sudo ldconfig -v | grep libnss
Yes, it grew substantially since I installed everything required to complie the MPD earlier.
Thank you for the further assistance here.
I ran the suggested checks on 2 Volumios: one I touched and one on the original firmware, untouched.
The outputs look identical to me.
And I feel it exposes an issue, yet, I’m not entirely sure how to address it.
I guess it has something to do with the directories used on the previous versions of Raspberry vs the current release?
volumio@volumiio:~$ sudo ldconfig -v | grep libnss
ldconfig: Path `/lib/arm-linux-gnueabihf' given more than once
ldconfig: Path `/usr/lib/arm-linux-gnueabihf' given more than once
ldconfig: /lib/arm-linux-gnueabihf/libnss_mdns6.so.2 is not a symbolic link
libnss_nisplus.so.2 -> libnss_nisplus-2.28.so
libnss_nis.so.2 -> libnss_nis-2.28.so
libnss_mdns_minimal.so.2 -> libnss_mdns_minimal.so.2
ldconfig: libnss_mdns6.so.2 -> libnss_mdns6_minimal.so.2
/lib/arm-linux-gnueabihf/libnss_mdns4_minimal.so.2 is not a symbolic link
ldconfig: /lib/arm-linux-gnueabihf/libnss_mdns4.so.2 is not a symbolic link
libnss_mdns4_minimal.so.2 -> libnss_mdns6.so.2
ldconfig: /lib/arm-linux-gnueabihf/ld-2.28.so is the dynamic linker, ignoring
libnss_mdns4.so.2 -> libnss_mdns4_minimal.so.2
libnss_mdns.so.2 -> libnss_mdns.so.2
libnss_hesiod.so.2 -> libnss_hesiod-2.28.so
libnss_files.so.2 -> libnss_files-2.28.so
libnss_dns.so.2 -> libnss_dns-2.28.so
libnss_compat.so.2 -> libnss_compat-2.28.so
libnssutil3.so -> libnssutil3.so
libnss3.so -> libnss3.so
I went ahead and removed libnss_mdns6.so.2 and libnss_mdns4.so.2.
Then ran liburing again, no warnings this time:
sudo dpkg -i liburing1_0.7-3~bpo10+1_armhf.deb
(Reading database ... 147470 files and directories currently installed.)
Preparing to unpack liburing1_0.7-3~bpo10+1_armhf.deb ...
Unpacking liburing1:armhf (0.7-3~bpo10+1) over (0.7-3~bpo10+1) ...
Setting up liburing1:armhf (0.7-3~bpo10+1) ...
Processing triggers for libc-bin (2.28-10+rpt2+rpi1+deb10u2) ...
What left me with this output:
volumio@volumiio:~/mpd_new$ sudo ldconfig -v | grep libnss
ldconfig: Path `/lib/arm-linux-gnueabihf' given more than once
ldconfig: Path `/usr/lib/arm-linux-gnueabihf' given more than once
libnss_nisplus.so.2 -> libnss_nisplus-2.28.so
libnss_nis.so.2 -> libnss_nis-2.28.so
libnss_mdns_minimal.so.2 -> libnss_mdns_minimal.so.2
libnss_mdns6.so.2 -> libnss_mdns6_minimal.so.2
libnss_mdns4.so.2 -> libnss_mdns4_minimal.so.2
libnss_mdns.so.2 -> libnss_mdns.so.2
libnss_hesiod.so.2 -> libnss_hesiod-2.28.so
libnss_files.so.2 -> libnss_files-2.28.so
libnss_dns.so.2 -> libnss_dns-2.28.so
libnss_compat.so.2 -> libnss_compat-2.28.so
ldconfig: /lib/arm-linux-gnueabihf/ld-2.28.so is the dynamic linker, ignoring
libnssutil3.so -> libnssutil3.so
libnss3.so -> libnss3.so
I’m wondering, is it acceptable or I’ve still got something to fix further?
In one of the location references inside of the /etc/ld.so.conf.d/
This is suspicious and I wonder where it came from. Is it still present?
The package: libnss-mdns is a plugin for the Name Service Switch (NSS) providing host name via multicast DNS resolution for programs in the ad-hoc mDNS domain .local. If you can find your Volumio device using .local you probably will be fine.
Newest MPD with dependencies are heading towards future Volumio releases and an upgrade will bring it in anyway.
But I assume that the conclusion for now is that the newest version of MPR should in theory solve the issue with the library rescan for all users affected and reported in this thread?
I think it would be nice if someone else gave it a try.
Overall, highly appreciate your involvement and proactive support.
Thanks much!
I have had the same issue. After new installation of volumio on pi 5, scanning music library from NAS, mpd was crashing when reaching around 5000 tracks.
No such issue on pi 4b been on the same network.
After installing 3.629 alpha release today, which uses more recent release of mpd, scanning was completed with 43k tracks….
