MP3 Player for large libraries

Hi there,
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
Reply to
Newdo
Loading thread data ...
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:
formatting link
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.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
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.)
Reply to
Roger Bell_West
I combine that in one Pi, where mpd itself plays the audio to hdmi (Pi hooked up to an av-receiver which in this case acts as just a stereo audio amp).
Reply to
A. Dumas
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 replacement.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
It's fairly shit in that regard, yes, but I like its simplicity. "man mpc" has all the info. (mpc is the commandline controller)
Reply to
A. Dumas
If it had any. It doesn't. It listens on a TCP port. Anything webby is the job of client software.
(Your other objections are entirely reasonable.)
R
Reply to
Roger Bell_West
OK, I misunderstood the documentation it does have then, which (I thought) implied that it provided a web interface for controlling its housekeeping activities.
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
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 with permissions.
Reply to
A. Dumas
squeezelite can be used as client on raspbian or any other linux distribution
Greatings Tycho
Reply to
tycho
Martin,
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.
Suggestions welcome...
- Udo
Am 27.11.2018 um 19:41 schrieb Mart>
Reply to
Newdo
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
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
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 - 8000 hours
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. 
 Click to see the full signature
Reply to
The Natural Philosopher
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 them.
[*] 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!
--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie
I think they calculate it as: test 1000 drives and 1 fails at t = 1000 h.
Reply to
A. Dumas
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.
Reply to
The Natural Philosopher
They are generally calculated from populations, accelerated testing and/or predictions. 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.
Andy
Reply to
AndyW
Bathtub curve. It only becomes low after about 100 h.
--




/ \  Mail | -- No unannounced, large, binary attachments, please! --
Reply to
Axel Berger
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?
Andy
Reply to
AndyW
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 production process.
It is nicely desribed in this document:
formatting link

- Udo
Reply to
Newdo

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.