i am currently looking for an MP3 player to play music from a raspberry pi.
After testing mopidy, which was fine but had trouble managing large
libraries (50k titles) i am about to test the sql library addon.
Before going into the wrong direction i'd like to ask the community if
there are any suggestions for my demands:
- can handle large mp3 libraries
- controlable via web interface by smartphone/tablet
- local libary on disk
Thanks - Udo
Why limit yourself to MP3? FLAC files give much better quality.
Several friends use the Logitech Media Server (LMS) on an RPi as theit
music indexing server, but I don't know what they use to play the tracks.
Get LMS here:
I also use LMS to search, and catalog my music collection, but that on a
desktop PC running Fedora Linux and I use a Squeezebox Touch to play my
music and streamed Internet Radio through my Quad-based stereo system.
To me keeping the library server and player functions separate makes morre
sense: this way you can have a decent librarian sitting over the music
collection and streaming it to the player(s) which can, in turn
concentrate in doing a good job of playing music.
Of course, ymmv
LMS does all this. You can control it directly from a web browser or from
the controls on your player(s). You can select and play tracks using
either interface but only the web browser can run maintenance tasks such
as cataloguing recently loaded albums.
The canonical free software answer is mpd (and your client of choice) to
control indexing and playback, and some lightweight stream player such
as mpv or even omxplayer to do the actual generation of audio. (I run
mpd on the server where the music is stored, and stream it to a Pi.)
I wandered over to its website, but was less than impressed with the
documentation, in particular:
- it mentioned recoding music files but didn't give a list of file
formats that it was prepared to recode
- there was no description on how it catalogues music files, i.e.
does it only use exif tags (and if so, how) and what, if any
information it gets from the file structure holding the music files
and/or playlists. No info about what playlist formats it can use either.
- a few screen shots of its web pages would be nice too.
This is not meant to sound like an attack on mpd because I have exactly
the same issues with LMP and its very similar lack of information about
these same points.
It all makes me wonder if their developers ever talk to users: In the
case of LMP its because the developers run the forum and treat it as
strictly a way for users to talk to them (and only them) and as a
replacement for any system and user documentation: IOW the way to
configure LMP is to install and start it and then use its help pages to
find out how to configure and customise it. Anything you don't understand
can only be sorted out via the forum: not an entirely satisfactory manual
They only provide mpc as an interface. There *are* web interfaces but those
are 3rd party. I made one for myself, which uses mpc under the hood for
actually sending signals to mpd. Very easy once you figure out how to deal
thanks for the hint, works great with my collection.
The next (hopefully last) problem is the steady access to the disk drive.
I am using an SSD drive which is permenently written to. (journalling?)
The collection stays most of the time unchanged so there is no need to
write anything to disk as long as the library stays the same.
Am 27.11.2018 um 19:41 schrieb Mart>
Good to hear that.
I have a single drive in my server (Dual Athlon, 4GB RAM, running Fedora
28 x64) with a single 500 GB HDD installed. This works well despite the
PC being a bit long on the tooth. I've had it 10 years and according the
smartd its original disk had 9,000 hours when I bought the PC. That disk,
IIRC a Hitachi 3.5" 250GB unit, died at 47,000 hours at the beginning of
last year. Its replacement is currently at 15,000 hours and is a WD Blue
3.5" 500GB drive, i.e. consumer grade with a MTBF of around 50,000 hours.
I slipped up there: since I run the server 24x7 I should have bought a WD
Red 3.5". The spec for this has an MTBF of 1,000,000 hours, twice the
number of start/stop cycles of the Blue (600,000 vs 300,000) and a 3yr
The fact that the server is up 24x7 is not so significant as the disk
being hammered 24x7 with multiple reads writes and seeks.
A friend used to blow disks doing continuous access in under a year -
I get about 40,000 hours our of my server disks.
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.
So have I - since I switched to WD disks. Hitachi look pretty good too,
seeing that the one in my server made it to 47,000 hours before dieing.
The point I was making is that the WD Blue series disks are optimised for
good performance in desktop PCs while the WD Red are optimised for server
and NAS with much longer estimated[*] MTBF and twice the number of start/
stop cycles than Blue disks. Since WD Red are a lot less than double the
price of the same capacity WD Blue it also makes financial sense to use
[*] 1,000,000 hours MTBF has to be pure sales-inspired hype since no disk
drive has ever been test run for anything like that: hard disks were only
invented 65 years ago while a million hours is a little over 114 years!
That depends on definitions.
E.g. Aircraft structures are subjected to many short 'test flights' in
the lab to pressurise and depressusrise tham way faster than they are in
service so that they *can* give lifetimes in years *of normal use* by
subjecting then to months *of abnormal use*.
I suspoect it is the same here. They will hacve looked at wer rates
coimpared with standrad disks and extrapoloated...uing real disk failure
rates as the initial value
No Apple devices were knowingly used in the preparation of this post.
They are generally calculated from populations, accelerated testing
It is a mean figure usually with a normal distribution and so it can
fail at 10 hours with a massively low probability and the disk could
still have an MTBF of 1M hrs.
It may be sales hype but that does not mean that it is untrue.
It also does not mean that it is true.
The bathtub curve for failures is largely discredited. 89% of failures
show no age relation although 72% do show early life failure and so
burn-in is important to drive the equipment past the ELF period.
Where did you get the 100h from, it seems like an arbitrary number?
Part A of the bathtube curve (infant mortality) decribes the time period
wherein th MTBF is decreasing.
This is not a fixed period since it depends on the causes for this
mortality (quality of processes etc.)
It could be shortened by identifying these causes and improving the
It is nicely desribed in this document: