I guess transcoding is CPU-bound. So it's nice to know the RPi 2 is up
to the task. But what are the relevant benchmarks for other LMS
functionality such as library scans,

Mostly disk I/O bound. More RAM will considerably improve this, as the DB will be able to keep more information in memory instead of reading it from disk over and over again.

web gui access,  artwort resizing or

CPU - keep in mind that most of the artwork resizing is done either at scan time, or on an external image proxy (when dealing with external image files). And 7.9 does cache some of the slowest web pages, such as eg. browsing artists or albums. Only the first time after a server restart or scan will the page be rendered. On subsequent calls the content is read from the cache, which usually is much faster.

multiple concurrent player accesses? Is that CPU-bound as well? Or is

IMHO this is neglectable. Unless you add transcoding to the mix. I've been using 4-5 SBs on a 1GHz Via C3 system for several years. Never was streaming a problem.

the 100 Mbps ethernet (cheaply connected internally via USB 2.0) a
bottleneck?

That should be good enough if you don't access the music over the network.

Could the 1 GB RAM be too little? In answering these
questions, does the size of the library play a role?

Yes, the library size does play a role: we've figured out that the old memory usage pattern ("large memory" setting) was ok up to 30-50k tracks, but that performance suffered a lot when you crossed that line. 7.9 introduces a new setting which would grab as much memory as needed, which speeds up a lot of tasks considerably.

With <10k tracks 1GB should be plenty to keep most of the database in memory all the time. 20k tracks might still work very well. If this was a Linux box dedicated to LMS, no GUI etc. then 1GB could cover a lot.

If you're worried about memory usage, then you might want to disable the fulltext search plugin in 7.9. It's a nice feature, but it uses more memory than the traditional search.

--

Michael
_______________________________________________
unix mailing list
unix@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/unix

Reply via email to