MP3 Player for large libraries

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.

--
Martin    | martin at 
Gregorie  | gregorie dot org

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 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).

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

It's fairly shit in that regard, yes, but I like its simplicity. "man mpc" has all the info. (mpc is the commandline controller)

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

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

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.

squeezelite can be used as client on raspbian or any other linux distribution

Greatings 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>

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

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. 

(Seneca the Younger, 65 AD)

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

I think they calculate it as: test 1000 drives and 1 fails at t = 1000 h.

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 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

Bathtub curve. It only becomes low after about 100 h.

--




/ \  Mail | -- No unannounced, large, binary attachments, please! --

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

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:

- Udo