LBS(Sammlung) Squeeze

[wintermute]

Nabend zusammen,

da gaert mit dem 1.19 Update dankenswerterweise den Weg geschaffen hat, dass Bausteine recht einfach untereinander Informationen austauschen koennen - ohne irgendwelche (mitunter) komplexen Mechanismen wie memcache, Semaphores, APC oder was auch immer (im Regelfall erstmal nicht verfuegbar ist) benutzen zu muessen - hab ich nu mal wieder meinen bisherigen Stand des Squeeze Bausteins aus der Schublade geholt...

Das Ganze hat momentan eher POC Charakter (was ein Grund ist, wieso es noch keine vefuegbare Version davon gibt; der zweite Grund ist der, dass ich jetzt erstmal alles wieder auf "KO-Kommunikation" umschreiben muss), aber bevor ich da jetzt weiter dran arbeite wollte ich mal in die Runde fragen in welchem Funktionsumfang da eigentlich Bedarf bestehen wuerde. Also so, wie rdeckard in einem anderen Thread angefragt hat, moechte ich gern die Entwicklung hier teilen damit am Ende nicht etwas raus kommt, mit dem "nur ich" etwas anfangen kann
Da das Thema doch relativ umfangreich ist (besser: sein kann), hab ich mal einen Thread dazu eroeffnet und taete mich freuen, wenn der eine oder andere hier Wuensche aeussern wuerde.

Das bisherige Konzept basiert auf der bewaehrten Kommunikationsform, sprich:
-Es gibt einen zentralen Daemon welcher der Kommunikation mit dem LMS etabliert, aufrecht erhaelt und mit den einzelnen Client-LBS kommuniziert (wie schon am Satzanfang erwaehnt, handelt es sich dabei um einen LBS mit Daemon-Teil).
-Fuer jeden Player (oder jedes Anzeigegeraet, falls es selber nicht "playen" kann) wird ein einzelner LBS erforderlich (dieser LBS kommt ohne EXEC-Teil aus).
-Player werden (hier zumindest) anhand der MAC, nicht anhand des Namens identifiziert (was dann auch der einzige "Pflichteingang" am Client-LBS waere).
-Player- und Daemon-LBS kommunizieren ueber 2 zentrale interne KOs, eines fuer die Meldungen vom LMS zum Player, das andere fuer Befehle die zum Daemon geschickt werden.
-Die Entwicklung laeuft gegen einen LMS 7.9.0, ob das Ergebnis mit aelteren Versionen funktionieren wird, kann ich also nicht garantieren (ich wuerde aber ohnehin jedem das Update empfehlen, zumindest bei mir hat es sich gelohnt).

*Meine* bisherige Vorstellung der endgueltigen Implementierung umfasst das folgende:
-Jeder Player(LBS) erhält Informationen über den aktuellen Zustand des Players (Name, Signalstaerke, Modell, Lautstaerke, Power, Play/Pause/Stop, usw usf) die auf KOs gelegt werden koennen.
-Jeder Player(LBS) erhält Infos über den aktuellen Titel, Album, Interpret, Genre, Cover (als URL), Position, Dauer uswusf des momentan gespielten Titels.
-Es koennen auf Player-Basis "einfache" Kommandos abgegeben werden, also zB "Power", "Play", "Pause", "Stop", "Next", "Previous", "Playlist xyz", "Volume +", "Volume -", "Volume <absolut>".
-Es sollten auf individueller (also pro Player) bzw globaler Ebene Durchsagen ermoeglicht werden - das brauche ich zB fuer unsere Tuerklingel, ist also wichtig

Was evtl fuer den einen oder anderen interessant sein koennte, aber nicht in der aktuellen To-Do-List liegt, sind so Sachen wie:
-aktuelle Playlist inkl Position anzeigen
-verfuegbare Playlisten anzeigen
-detaillierte Infos ueber Alben oder Kuenstler anzeigen
-und natuerlich das ganze Zeuchs mit "spiel alles von diesem Kuenstler" oder "aus jenem Genre"
-Alarme verwalten

Jetzt war mein Plan natuerlich nicht, eine LMS GUI zu schreiben; da gibts bereits genug gute und frei verfuegbare, es geht dabei mehr um die sinnvolle Integration in eine Visu und die einfache bzw direkte Verfuegbarkeit von oft benutzten Funktionen. Auch hatte ich nicht vor, so Dinge wie "Playlisten in der Visu organisieren" oder "Playlist anzeigen und dann direkt einen Titel anspringen" zu implementieren.
Starten wuerde ich also erstmal mit der obigen, *Meine*-Liste.

Jetzt ist mir bei der bisherigen Implementierung bereits aufgefallen, dass die Ausgaenge des Client-LBS unuebersichtlich zahlreich werden, ich muss das irgendwie begrenzen :/
Was man natuerlich immer machen kann (und deswegen steht da oben auch "Sammlung") ist: einzelne Funktionen in andere LBS aufzusplitten. Also zB so Dinge wie "Kuenstler Informationen" in einen eigenen LBS auszugliedern - wenn das dann jemand braucht, kann er den LBS ankorken und mit den Daten tun und lassen was er moechte. Sowas erfordert aber natuerlich im Kern einige Wege die am liebsten jetzt und nicht erst in zwei Monaten gehen wuerde, daher die Rundfrage

Davon ab: ich bin die naechste Zeit etwas kurz angebunden, versuche aber das - soweit mir moeglich - in benutzbare Regionen zu pushen. Je weniger esoterische Wuensche gemeldet werden, desto schneller geht das - natuerlich
Die Frage richtet sich also vornehmlich - aber natuerlich nicht nur - an Leute die bereits die eine oder andere LMS Implementierung im Einsatz haben.

Ich hoffe auf Rueckmeldungen de(s/r) einen oder anderen

gruesse :: Michael

[saegefisch]

Aufteilung in mehrere LBS für die unterschiedlichen Aspekte (Steuerung, Playlist, Titelinfo) finde ich allgemein eine gute Lösung bei komplexen Anforderungen. Die LBS mit 10001 Ausgängen machen keinen "schlanken Fuß" im Logikeditor... Ich bin gespannt, wie das konzeptionell aussieht und freue mich daher auf eine derartige Lösung. Für anderes Fragestellungen kann ich das sicher auch gebrauchen.

Direkt brauche ich es nicht, da ich nach vielen glücklichen Jahren mit Squeezeboxen im ganzen Haus zum Jahreswechsel komplett auf Sonos wechselte. Es ist ein Jammer, dass Logitech das hat einschlafen lassen. Letztlich hatte es für mich keine Zukunft mehr, da in meiner Wahrnehmung die Spotify-Integration hakelig war. Und das kam kurz vorher in Haus. Sorry. Aber ich kann jeden verstehen, der an den "Squatschboxen" (O-Ton meiner Töchter) hängt. Tolles Produkt. Und sicher ein LBS wert.

[fisch3009]

Hi Michael,
erstmal sehr cool, dass du das machst.
Deine Grundfunktionen würden bei mir schon fast alles abdeckeln, allerdings wäre bei mir noch zusätzlich die Alarmverwaltung sehr wünschenswert.
Außerdem wäre die Synchronisation von Playern auf meiner Wunschliste, das ist aber eher nebensächlich und wäre ein nettes Addon.
Freue mich schon, auf das was kommt.

[rdeckard]

Meinen Segen hast du natürlich.
Nein, ich würde mich wirklich freuen, wenn da am Ende eine für viele LMS-Benutzer flexible Lösung herauskommen sollte. Auch wenn Sonos sicher in Mode ist, ist LMS mit passiven Lautsprechern u.U. immer noch eine sehr interessante Alternative. Und da der LMS ja von Logitech als OpenSource freigegeben wurde und auch aktiv weiterentwickelt wird, ist mir diese Variante irgendwie sympathisch.

Vieles auf deiner Featureliste klingt sehr verlockend, wobei ich jetzt eher sehr pragmatisch an die Sache rangehe. Zurzeit habe ich 2 Player (für 2 Zimmer), welche ich synchronisiert habe und auf welchen eigentlich nur Radio läuft. D.h. ich starte/stoppe den Player über Edomi (einfacher HTTP-Befehl) und kann noch die Lautstärke darüber steuern. Mehr nicht. (Kein Status auf der Visu, was gerade läuft oder obs überhaupt gestartet ist.)

Aber alleine schon das ist für uns eine tolle Sache, weil halt neu. (Andere werden wohl darüber lächeln)

Da wir weder Spotify, noch eine Riesen MP3-Sammlung haben, reicht das zurzeit.

Natürlich werde ich noch weitere Räume mit zusätzlichen Playern erschliessen und dann wird die Synchronisierung (bzw. Gruppierung) langsam ein wichtiger Punkt. Am liebsten wäre mir, dass ich verschiedene Gruppen vordefinieren könnte, welche man dann einfach aktivieren könnte (Gruppen sollten natürlich immer synchronisiert sein). Ob das möglich ist (generell vom LMS) weiss ich nicht.

Der andere wichtige Punkt hast du glücklicherweise auch auf der Liste: das direkte Ansteuern eines Players (oder einer Gruppe) für Ansagen etc.
Ich habe z.B. eine SIP Türstation, aber keine Klingel. Ziel ist es, dass ich über den SIP-Call meine Deckenlautsprecher als Klingel verwenden könnte. Somit über den LMS.
Wie schnell man aber über LMS/Player eine WAV oder MP3 Datei abspielen kann, habe ich noch nicht getestet. Nach dem Drücken der Klingeltaste sollte ja nicht grad 20 Sek. vergehen, bis der Ton dann erklingt.

Das sind im Moment so meine (bescheidenen...hüstel) Wünsche. Steuerung von MP3 würde mir ganz rudimentär reichen. (Wenn überhaupt)
Und wie schon im Thread erwähnt...die Visu soll sicher nicht zur Verwaltung von Playlisten etc. herhalten. Im besten Fall ruft man eine bestimmte Playliste auf und kann dann diese abspielen (mit den typischen Befehlen wie Pause/Stop/Nächster Song/shuffle). Wenn der Song/Interpret und die eingestellte Lautstärke auf der Visu ausgegeben wird, würde das schon völlig reichen. Cover etc. bräuchte ich im Moment eher nicht.

Vielleicht könnte man mal gemeinsam eine Featureliste (mit Prios) erstellen. Dann sieht man schnell mal, wohin die Reise führt. Aber ich bin auch dafür, dass man am Anfang lieber mit wenig beginnt, dafür aber schnell mal ein Erfolgserlebnis hat. Wichtig ist, dass die Programmierung aber berücksichtigt, dass weitere Funktionen kommen werden. Also sollte von Anfang sehr flexibel und modular gedacht werden.

Und auch wenn ich nicht der Hardcore PHP-Programmierer bin, so habe ich doch ein paar Skills. Deshalb fände ich es toll, wenn man das Projekt hier etwas begleiten könnte. Also auch von der technischen Sicht. Da könnte man sicher viel lernen, wie es ja auch der Thread vom ColiFlower gezeigt hat. (Für Nicht-Interessierte sicher langweilig, aber die müssen ja nicht mitlesen.)

Also ich freu mich...

P.S.: Psssst...sags niemanden weiter....ich wollte schon immer eine Idee umsetzen, über die andere wohl nur lachen würden. Wir wohnen in der Nähe einer Autobahn. Also hört man (auch Nachts) immer ein Grundrauschen. Wir haben schalldichte Fenster und Komfortlüftung (auch wenn ich trotzdem oft das Fenster beim Schlafen offen lasse).
Immer, wenn ich im Urlaub bin und das Glück habe, in einer ruhigen, ländlichen Region zu übernachten, freue ich mich, wenn draussen Grillenzirpen zu hören ist. Das beruhigt mich und ist für mich Sinnbegriff für eine laue Sommernacht.
Yep..und jetzt kommts...ich habe mir extra oberhalb unseres grossen Schlafzimmer-Fensters einen Einbau-Wandlautsprecher montiert, der ausschliesslich für solche Töne gedacht wäre. Also dass ich selbst bei geschlossenen Fenster über diesen Lautsprecher Grillenzirpen (oder was auch immer) hören könnte. Natürlich nicht immer...man könnte das ja gut über die Jahreszeit und die Aussentemperatur und mit bisschen Zufall verbinden, damits realistischer wäre.
Also das wäre bei mir auch auf meiner Liste drauf. (Geht aber vermutlich in die Kategorie Durchsagen etc.)

[Winni]

Auch wenn ich aktuell noch kaum mit Edomi experimentiere: Ich würde einen LBS der beim Wechsel der MAC Adresse alles sofort an den Aushängen richtig darstellt super finden. Mehrere Bausteine, also für jede Player einen, find ich persönlich immer sehr viel Kopieraufwand. Die Sleep-Funktion mit Restzeitanzeige wäre auch ein Wunsch von mir. Grundsätzlich bin ich aber über alles froh, was es mir ermöglicht die Squeezeplayer zu steuern

[MatthiasS]

Ich bin für getrennte Bausteine pro Player - Client.

Ich stelle üblicherweise parallel dar, was wo läuft. Die Lösung für den HS ist eigentlich nahezu perfekt (Server/Status/Befehls-Baustein), ich denke da könnte/sollte man Anleihe nehmen.


p.S: ich sehe inzwischen ein Revival des LMS-Universums. Es gibt zahlreiche Os und kommerzille Projekte, hochwertige Player auf PI-Basis bereitzustellen.

Siehe max2play, Hifiberry, picoreplayer usw. Dazu die ganzen Pi-DAC-Aufsätze. Das ist ein Zeichen, dass das System lebt.

[wintermute]

Erstmal danke fuer die (zahlreichen) Antworten.
Ich versuche mal auf alles einzugehen und hoffe, ich ueberseh nix

• Momentan ist es so gebaut, dass es fuer jeden Player einen eigenen LBS geben wird. Alle LBS bekommen parallel die (aufbereiteten) Ausgaben des Server-LBS mit, ignorieren die aber wenn ihre MAC nicht drinsteht. Es wird also vermutlich recht einfach umzusetzen sein, dass ein Client LBS auf jede playerID reagieren kann. Mir ist allerdings nicht ganz klar wie man das dann sinnvoll fuer die Visu aufbereiten kann, aber das ist auch erstmal egal - taete mich dennoch interessieren
• Synchronisation hab ich irgendwie voellig verdraengt, hat vermutlich einfach damit zu tun, dass ich das (bisher) selber noch garnicht benutze. Ja, ist defo wichtig.
• Alarme finde ich selber recht praktisch, auch wenn ich die Funktion nicht nutze Ich setze das mal hinten auf die Liste.
• Mit Durchsagen habe ich bisher nur ein wenig rumgespielt, hauptsaechlich um rauszufinden wie sich das mit aktuell abgespielten Playlisten verhaelt. Das war zwar wirklich nur Rumpspielen, aber ich kann schonmal sagen, dass die Ansagen recht zuegig kommen, also so innerhalb von 1-2s vielleicht.
• Von der sleep Funktionalitaet hab ich mal irgendwann gelesen, mehr nicht Kommt auch hinten auf die Liste.
• Ob ein Befehls-LBS gebraucht wird, weiss ich zZ noch nicht. Im Moment ist es so, dass man den Befehl (in "menschlicher" Form) in den Client-LBS drueckt, also zB sowas wie "volume +5" oder "power 0" oder sowas. Der Server-LBS hat aber sowohl Ein- als auch Ausgaenge fuer "Rohdaten", die braucht er, weil die Befehle vom Client-LBS fuer den Server aufbereitet werden. Es spricht also nix dagegen, diese Schnittstelle zu nutzen wenn man "Sonderbefehle" absetzen moechte.
• Ich versuche die Ausgaenge des Client-LBS auf das "sinnvollste" fuer die Visu zu beschraenken, fuer weiterreichende Infos plane ich dann einzelne LBS ein (sowas wie Kuenster-Informationen oder so), das kommt dann aber auch erst spaeter - zunaechst muss ja erstmal das Grundgeruest stehen
• Und ja, sobald der Code aufgeraeumt ist (so wie der jetzt aussieht kann man das keinem zeigen ), lade ich eine erste Version hoch. Mit der wird man dann auch schon rudimentaer arbeiten koennen. Da kann dann jeder gerne fragen wieso, weshalb, warum oder Anregungen einbringen.

dank & gruss :: Michael

[MatthiasS]

Du verstehst wahrscheinlich unter dem Client-Baustein, was ich mit Befehlsbaustein meine: Eben der Baustein, der eine Wert umsetzt in das passende Kommando wie Volume etc.




Und der Status- Baustein ist der, der aus dem Server-Baustein die Informationen über den betreffenden Player herausfischt:

[wintermute]

Ja, so aehnlich hab ich das jetzt auch gebaut... die ersten Versionen (vermutlich noch mit Fehlern ) sind im Portal zu finden, 19000200-19000202 (Squeeze Server, Squeeze Client, Squeeze Command).
An den Ein-/Ausgängen wird sich im Laufe der Zeit noch einiges tun, neuere Versionen sind dann vermutlich von er "Pinbelegung" her nicht mehr kompatibel, was bedeutet dass im Logikeditor mitunter nachgearbeitet werden muss. Das ist zwar suboptimal, aber ich kann nicht in die Zukunft gucken.. ausserdem ist das alles noch Beta

Zur Funktionsweise:
Zunaechst werden zwei interne KOs benoetigt, ueber die die Einzelkomponenten kommunizieren, ich nenne die mal SqueezeKommandoKO und SqueezeStatusKO.

Es wird eine Instanz des Server Bausteins 19000200 benoetigt, die wird wie folgt "verkabelt"LMSserver.png

(die Eingangsboxen sind jetz nur zur besseren "Lesbarkeit", die koennen natuerlich entfallen wenn die KOs direkt "aufgelegt werden - das Oder-Gatter ist nur fuer mich, damit ich leichter an die aktuellen Werte komme)
Im Prinzip braucht es also nur die IP bzw den Hostnamen des LMS (eventuell noch den CLI Port, wenn der irgendwie verbogen wurde) sowie Credentials (Achtung, das ist nicht getestet, ich habe kein LMS hier welches Authentifizierung benoetigt, wuerde mich also um Rueckmeldungen freuen).
An E10 des 19000200 wird das zentrale KommandoKO gelegt, an A1 (StatusKO) wird das zentrale StatusKO "angeschlossen".
Alles darueber hinaus gehende sollte in der Hilfe des Bausteins erklaert werden.

Fuer jeden Player wird nun ein Client Baustein 19000201 benoetigt, Verkabelung wie folgt:
LMSlocalmedia.png

Squeeze Command (19000202) sowie der Oszi sind optional, schreib ich gleich noch was zu, die Oder-Gatter sind wieder fuer mich und meine Live-Werte). Zwingend erforderlich sind hier:
-Internes StatusKO an E1
-MAC Adresse des betreffenden Players an E2
-A1 mit dem internen KommandoKO verbinden

Das sollte erstmal ausreichen um Status-Information ueber den betreffenden Player an den Ausgaengen vom 19000201 zu erhalten.
Moechte man den Player steuern, so geht das entweder ueber direkte LMS-Kommandos (ohne playerID am Anfang) an E3 des 19000201 (da dann zB einfach ein "power 1" hinschicken) oder ueber den 19000202 Baustein.
Der 19000202 muss (falls er verwendet wird) wie im obigen Bild angeschlossen werden. Es darf keine playerID im 19000202 definiert sein, durch entsprechende Werte an den Eingaengen (siehe Hilfe) kann dann der Player gesteuert werden.

Grundlegende Funktion sollte damit erstmal gegeben sein... ich bitte um zahlreiches Testen

Im uebrigen sind die Track-Eigenschaften (also die Ausgaenge des 19000201) mitunter anders strukturiert als erwartet, besonders wenn remote-Medien abgespielt werden. Im Bild oben wird ein lokales Medium abgespielt, in folgendem Bild ein Radiosender (man beachte Title, currentTitle & remoteTitle, ebenso Time, Duration & Position):
LMSremoteMedia.png

viel Erfolg

gruesse :: Michael

[fisch3009]

Moin Michael,
habe seit gestern deinen Baustein Einsatz und bis jetzt keine Probleme festgestellt.
Ich werde weiter testen, bin aber auf jeden Fall begeistert, dass du das so schnell umsetzen konntest :-)

[rdeckard]

So, hab vorhin auch mal einen ganz kurzen Test versucht. Anhand der obigen Screenshots hat es auf Anhieb geklappt. (Was soll man eigentlich in den Befehlen der beiden Ausgangsboxen eintragen? Habe im Moment einfach das StatusKO und das KommandoKO abgefüllt...obs Sinn macht, weiss ich nicht. Vorallem bei der 2. Ausgangsbox.)

Nur im Oder-Gatter habe ich im Gegensatz zum Beispiel gar keine Werte, obwohl ich sie ja verbunden habe. (Habe ein Radiosender drin)

squeeze1.png

Die status.html vom LMS sieht in diesem Moment so aus:

squeeze2.png

(Die Zeit-Angabe unterhalb der Lautstärke stimmt übrigens nicht und wird auch nicht aktualisiert.)

Interessant noch, dass ich im LBS ja nur die ID (MAC) EINES Players angebe, der LMS aber dann beide Räume (=2 Player) abspielt, da diese ja synchronisiert sind.
Die Frage ist halt, ob man remote die Synchronisierung setzen/trennen kann. Ich dachte aber, ich hätte mal im API entsprechende Befehle gesehen.

Aber immerhin schon ein Erfolgserlebnis! Gute Arbeit

[wintermute]

Aber immerhin schon ein Erfolgserlebnis! Gute Arbeit

Naja, scheinbar nicht wirklich

Also im Prinzip geht es darum, die Ein-/Ausgaenge des Server Bausteins mit den Aus-/Eingaengen des Clients zu verbinden. Ohne die Befehlsboxen wuerde das dann prinzipiell so aussehen:

koki.png

Was die Ausgaben angeht: evtl etwas abwarten oder mal den Track wechseln. Eigentlich sollte der Baustein aktuelle Infos liefern, aber vllt wird er tatsaechlich nur bei nem refresh wirklich getriggert.
Ist fuer mich etwas schwierig die ganzen Eventualitaeten zu testen, ich freue mich da also auf Mithilfe

Aber nochmal: der Oszi ist nur (und wirklich *nur*) dazu da, die aktuelle Abspielposition auszugeben. Wird die nicht benoetigt, kann man den auch einfach weglassen.

gruesse :: Michael

[rdeckard]

Frage: Im Squeeze Command kann man ja die Befehle für den Client definieren. Was passiert, wenn dort Play und Stop beide den Wert 1 haben?
Und könnte man evtl. Eingänge zusammenfassen, welche nie zusammen verwendet würden?
z.B. Play/Stop/Pause oder auch Previous/Next oder Vol+/Vol-
Man wird ja nicht gleichzeitig ein Previous UND Next schicken. Die Unterscheidung könnte man dann mit einer Zahl machen. E3=1 wäre Play, E3=2 für Stop und E3=3 für Pause.
Würde etwas Eingänge sparen und Fehler vermeiden. (Dafür zulasten der Übersichtlichkeit, man muss halt wissen was E3=2 bedeutet)

[wintermute]

Frage: Im Squeeze Command kann man ja die Befehle für den Client definieren. Was passiert, wenn dort Play und Stop beide den Wert 1 haben?

Wer zuerst kommt, mahlt zuerst
Der Command Baustein ist nur so auf die Schnelle zusammengeschustert, vor allem hat er das Problem, dass - wenn die Eingaenge mit KOs belegt sind - beim Edomi Start eine ganze Latte Befehle abfeuert. Ist mir gestern abend aufgefallen, falscher Vergleich von $E[value] (0 anstatt NULL).
Prinzipiell isses aber momentan so (und eigentlihc sollte das auch so bleiben), dass die Eingaenge sowohl als 0 als auch auf 1 reagieren, will sagen:
0 an Stop bedeutet "Play", 1 an Stop bedeutet "Stop"
Ich war mir naemlich nicht ganz sicher wie das gewuenscht ist - weil ja der eine zB Stop/Play/Pause als 0/1/2 verbaut, der naechste dann aber als getrennte 0/1 KOs.
Mir ist das prinzipiell wurscht, ich dachte so waere es am flexibelsten.

Aber wie gesagt: gleichzeitig geht nicht (spaetestens seit Einstein nicht mehr ). Die Befehle werden von Edomi in einer Queue sequentiell uebergeben, also wird in dem beschriebenen Fall alles hintereinander abgefruehstueckt.

Bekommst Du denn mittlerweile Werte vom Client rausgeworfen?

[rdeckard]

Wegen Client kann ich erst am Abend testen. (Wobei ich heute vermutlich nicht viel Zeit habe.)