Max2Play Home › Forums › Max2Play as Squeezebox (Player / Server) › Squeezebox Server (LMS) Performance
- This topic has 7 replies, 5 voices, and was last updated 6 years, 10 months ago by std Moderator.
-
9. Oktober 2017 at 17:11 #31826
Hallo,
ich bin gestern zufällig im Zuge einer „Spotify mit Squeezebox Server/LMS“-Recherche über Max2Play gestolpert – hat zwar ein bisschen gedauert, bis ich das Konzept verstanden habe, aber ich denke, mir ist der Großteil klar!Ich habe seit längerer Zeit folgende Lösung:
* LMS 7.8 auf einem QNAP NAS
* Große Musiksammlung (rd. 85.000 Titel) auf dem NAS
* Etliche Logitech-Devices (inkl. remote Streaming über das Internet)An sich eine coole Lösung; was mich unzufrieden macht:
* Mühsames Update-Prozedere von LMS auf dem QNAP
* Keine weiteren Endgeräte, da Logitech den Support eingestellt hatWas mich an eurer Lösung reizt:
* Offenbar einfache Installation und Upgrade „out of the box“
* Größere Auswahl an möglichen Endgeräten
* Erweiterbarkeit für VideoWürde daher gerne auf Max2Play umsteigen, erst nur für die LMS-Server-Lösung auf einem Raspi, mittelfristig mit weiteren Playern für weitere Räume!
Habe noch folgende Fragen:
* Wenn ich „euer“ LMS auf einem Raspi laufen lasse – wie ist da die Performance beim Indizieren bzw. Re-Indizieren? 85.000 MP3s sind schließlich keine Kleinigkeit. Mir ist klar, dass die Lesegeschwindigkeit des NAS viel ausmacht, aber die Indizierung selbst samt Datenbank liegt ja dann am Raspi.
* Ich habe mehrfach gelesen, dass bei der obigen Konfiguration ein Maximum bei drei parallelen abgespielten Streams liegt. Wie kann ich skalieren, wenn ich mehr Streams parallel abspielen möchte?Vielen Dank im Voraus!
GebhardPS: Generell finde ich euren Ansatz super!!!
10. Oktober 2017 at 9:26 #31839Hallo Gebhard,
Erstmal danke für die netten Worte!
Leider können wir keine direkte Aussage treffen bezüglich der Höchstgrenze für den Server-Pi, da diese von vielen verschiedenen Faktoren abhängt in deinem System, auch abseits von Bibliothek und parallelen Streams. Der Konsens ist jedoch, dass der Raspberry Pi 3 die meisten Aufgaben des LMS sehr gut meistert. Dabei kommt dir das MP3-Format auch zu Gute. Ich würde dir empfehlen, einfach mal einen LMS auf dem Pi laufen zu lassen, um zu sehen wie gut es mit deiner Konfiguration klar kommt. 😉
10. Oktober 2017 at 15:41 #31853Hi,
danke für die Infos.
Nur der Vollständigkeit halber: Skalieren kann ich den LMS meines Wissens ja nicht, d. h. das Streaming auf mehrere Geräte verlagern o. ä.?
LG Gebhard10. Oktober 2017 at 21:07 #31857Hi
also ich hab von noch niemandem gehört der an die max Anzahl gleichzeitiger Streas bei einem Pi gestoßen wäre
Aber selbst der schlappe Server der Squeezebox Touch schaffte es 4 Player unabhängig zu versorgenDie Geschwindigkeit der Inizierung wird eher durch dein Netzwerk oder das NAS begrenzt werden als durch den Pi
Von der am Pi hängenden Platte liest er 8000 Titel samt Cover in 40 Sekunden10. Januar 2018 at 17:41 #33341Hi,
bei mir läuft m2p auf einem ODROID XU4 mit eMMC Speicherkarte und LMS 7.9. Meine Musiksammlung hat ca. 100.000 Titel, die auf einer Synology Diskstation 710+ liegen. XU4 und NAS sind direkt per Kabel am Router angeschlossen.
Der Aufbau der LMS-Datenbank beim ersten Scannen hat ca. 2h gedauert. Das Suchen nach Änderungen dauert immer ca. 15 Minuten.Viele Grüße
10. Januar 2018 at 22:17 #33342Ich habe einen Server auf zwei verschiedenen Server-Varianten getestet.
Ich habe dazu jeweils ein Internet-Radio-Stream abgespielt.
Die Mehrzahl meiner Abspielgeräte hängen übrigens am Gigabit-Lan.Mein Ergebnis:
1. QNAP NaS TS-419+ => 5 Streams
2. Raspi 2 / B+ => 3 Streams gehen gerade noch12. Januar 2018 at 17:31 #33380Hallo Matthias,
Wir werden dies nochmal prüfen, jedoch haben wir definitiv bereits mehr als 3 Streams gleichzeitig, sogar synchronisiert, ohne Probleme testen können.
13. Januar 2018 at 0:13 #33390bei Synchronisation ist die Serverlast ja geringer als bei unterschiedlichen Stzreams
Aber wie gesagt hat schafft selbst die Touch vier untersdchiedliche -
You must be logged in to reply to this topic.