You are not logged in.
Hello,
I tried MPD on a raspberry pi and a NFSv4 mount over vpn over internet.
Suffice to say, I was surprised when I saw mpd actually attempting to *read* one and every file in the huge 500GB repository. What the hell. Why does it need to "read" in the whole file??
Is there an alternative to mpd with similar capabilities, that doesnt suck? Or should I run mpd on the main server - but how do I then get the sound/mp3s to the raspberry pi?
Offline
did you properly set the music_directory and playlist_directory? it should only attempt to read the files within those, and only during a database update or while playing music
Offline
Yes, they are set correctly.
The problem is that mpd is reading all the files during the upate phase its doing. Why the hell would it need to read all files to make its database?
If it needs id3tags, cant it read only those bytes from the files, but what Im seeing is it reading _every_ byte of every file. Thats the same as playing the file, thats dumb design.
This is a problem when the music_directory is in fact an NFS share over the great internets and the music_directory is 500GB or so.
Anyway around this?
Does Linux even have any distributed musical players?
Last edited by tricksterr (2014-07-09 11:55:10)
Offline
Personally I'd run mpd on the server setting its output as an http stream, and then connect to this stream from your RPi.
Offline
Yes, they are set correctly.
The problem is that mpd is reading all the files during the upate phase its doing. Why the hell would it need to read all files to make its database?
If it needs id3tags, cant it read only those bytes from the files, but what Im seeing is it reading _every_ byte of every file. Thats the same as playing the file, thats dumb design.
This is a problem when the music_directory is in fact an NFS share over the great internets and the music_directory is 500GB or so.
Anyway around this?
Does Linux even have any distributed musical players?
normally this is only true for ogg files. for other formats mpd should only read the tags.
A workaround would be to scan the database locally on the other machine and copy it over. the database is relative to the music_directory, so this would work just fine.
Last edited by Rasi (2014-07-09 22:21:34)
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
Personally I'd run mpd on the server setting its output as an http stream, and then connect to this stream from your RPi.
I tried this.
Performance was worse than downloading images in 1989.
Then I pointed my Galaxy Note 3 to the http stream, and used mpd control to go next/previous/browse songs. There again was a 3-10 seconds lag.
Is this normal with mpd?
Offline
tricksterr wrote:Yes, they are set correctly.
The problem is that mpd is reading all the files during the upate phase its doing. Why the hell would it need to read all files to make its database?
If it needs id3tags, cant it read only those bytes from the files, but what Im seeing is it reading _every_ byte of every file. Thats the same as playing the file, thats dumb design.
This is a problem when the music_directory is in fact an NFS share over the great internets and the music_directory is 500GB or so.
Anyway around this?
Does Linux even have any distributed musical players?
normally this is only true for ogg files. for other formats mpd should only read the tags.
A workaround would be to scan the database locally on the other machine and copy it over. the database is relative to the music_directory, so this would work just fine.
Interesting, Ill try this hack.
Found Mopidy as well, gonna try it out.
Offline
you could do library updates from the NFS server and save the library info to the NFS share, then point your MPD server you use to listen on to those library files. then you don't have to struggle with network speeds on updates.
but this does make me curious why it is reading the entire songs. it could just be that you have a lot of songs so that it seems like it is? idk
Offline
you could do library updates from the NFS server and save the library info to the NFS share, then point your MPD server you use to listen on to those library files. then you don't have to struggle with network speeds on updates.
but this does make me curious why it is reading the entire songs. it could just be that you have a lot of songs so that it seems like it is? idk
I scp'ed over the database file from main server which had indexed/updated the db with about 80k songs.
Then mounted the nfs share to the rasperry pi to the same absolute paths as on the main server (why not).
This works fine, I see only the songs that I play are transferred quite fast, playing is almost instantenous, and they seem to be cached somewhere. Seeking within files is also fast, especially once already played.
Now as you say, the database file needs to be kept in sync between the NFS server and raspberry, one way would be to put it as well in some nfs share, or sshfs or whatever, or even cronjob it with rsync, since I wont be doing database updates/adding albums that often on the main server.
Would be good if something like this was documented somewhere. Like the wiki. And an option in mpd to ignore update commands to its database - thats now dangerous - it does read all the files, and even if it only tries to read headers - for some shares such as 1 or 2TB of songs, thats too much. Now the mpd on rasperry is more of a proxy.
So yes, this does work now, the slight downside is that the android client mpdroid is not that good - it doesnt respect volume keys when not in view'and such, but one can live with that.
Offline
mpd has the proxy database plugin. with this one mpd instance can share the database with another one.
you have to update the database on the master server though, since updates are not forwarded from the slave.
He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife.
Douglas Adams
Offline
MPDroid has other issues as well, such as adding songs to the current playlist or switching playlists results in incomplete adding. this can be worked around, of course, by just sshing into the machine and using something like ncmpcpp to do the job. as a basic streaming client it works just fine
Offline
For other readers of the future,
If you pass the fsc option when mounting nfs, it instructs the kernel apparantly to offer caching for any userspace daemons ready to do that, such as cachefilesd which is in aur, and can be built on armv6h, then you can get a cache of all things nfs reads - perfect for music, since you usually play the same songs/playlist over course of a week or so - saving bandwidth! Can be setup on raspberry to use that other 2G on a 4GB card for the cache, instead of usualy only having the VFS cache.
Offline
mpd has the proxy database plugin. with this one mpd instance can share the database with another one.
you have to update the database on the master server though, since updates are not forwarded from the slave.
Thanks, this seems good enough.
Offline