LBS(Sammlung) Squeeze

[wintermute]

Man kann im LMS bei den Playereinstellungen definieren, was alles synchronisiert werden soll. z.B. kann man die Lautstärke auf Wunsch jeweils unabhängig ändern oder auch Stop/Pause etc.

Ist das echt so? Ich dachte man kann nur On/Off und die Laustaerke vom Sync ausnehmen, alle anderen Kommandos (also zB Play/Pause) wuerden dann generell an alle Player in der Gruppe weitergegeben...

fisch3009 das mit "entsyncen" hatte ich mir auch schon ueberlegt, vielleicht ist das wirklich das sinnvollste o\

[rdeckard]

Hmm...ich dachte, es wären nicht nur On/Off und Lautstärke...kann es aber erst am Abend prüfen.

[fisch3009]

Ich kann bei mir nur Lautstärke und Ein-Ausschalten nicht synchronisieren/synchronisieren (siehe Bild). Play/Pause, Titel usw. wird also immer synchronisiert. Und für mich gibt es da auch keinen "Master" in dem Sinne, oder?
Das einzige, was quasi Master ist, ist wenn ich sage ich möchte mein Schlafzimmer mit meiner Küche synchronisieren, dann bekommt das Schlafzimmer die Playlist der Küche, von da an sind beide aber gleich berechtigt.
Von daher würde der Ansatz doch z.B. so aussehen. Durchsage ist für Arbeitszimmer und Küche aktiviert.
Zustand vor dem Klingeln:
- Arbeiten: aus
- Küche + Schlafzimmer: Synchronisiert:

Durchsage kommt
- für Arbeiten ja alles normal
- Küche und Schlafzimmer werden getrennt
- Schlafzimmer spielt weiter
- Küche spielt Durchsage
nach der Durchsage:
- Arbeiten: geht wieder aus
- Küche wird wieder auf Schlafzimmer synchronisiert (erhält also von da den Stand und die Playlist).
So könnte ich mir das Vorstellen.

[rdeckard]

müssen nicht vor der Durchsage das Arbeitszimmer und die Küche synchronisiert werden und dann die Durchsage an den Master dieser Gruppe geschickt werden?
Das ist ja vermutlich der Knackpunkt, dass diese Synchronisieren nur für die Durchsage viel Zeit beansprucht. Und gerade Durchsagen werden vermutlich eher an viele als an wenige Player geschickt.
Vorallem können bei einer solchen Durchsage einige Player laufen, evtl. auf stopped oder gar OFF sein. Ob dann bei einer kurzen Durchsage alle Player schon bereit sind oder ob da manche die Durchsage halb verschlucken, wird man auch erst sehen, wenns funktioniert.

Meine bisherigen Erfahrungen sind, dass der LMS ja bisschen Zeit braucht, um sich auf die Audioquelle einzustellen (Synchronisierungsprozess).
Das ist halt keine Matrix, wo einfach nur die Kanäle ein/ausgeschaltet werden.

[wintermute]

Meine bisherigen Erfahrungen sind, dass der LMS ja bisschen Zeit braucht, um sich auf die Audioquelle einzustellen (Synchronisierungsprozess).

Ja, befuerchte ich auch... wenn das "Aufbrechen" der Verbubbelung schnell geht, dann waere "Aufbrechen, Durchsagen an einzelne Player schicken, Sync wieder Herstellen" vielleicht eine Loesung. Aber erst "Aufbrechen, dann neu Syncen, dann an einen Player schicken, dann wieder umsyncen" ist IMHO keine gute Loesung. Auch nicht aus Sicht der Logik in Edomi... Vielleicht ist das ja auch garnicht so wild wenn man an mehrere Mitglieder einer Sync-Gruppe einfach dieselbe Playlist schickt, koennte man auch mal ausprobieren.
Aber das mit dem Syncen stelle ich weiter hintenan, ich will erst eine Loesung die ohne Sync vernuenftig funktioniert und die ich dann wieder kaputt machen kann

BTW: technisch gibt es tatsaechlich einen "Master" in der Sync-Gruppe (ich vermute das ist der Initiator des ersten Syncs, bin mir aber auch nicht wirklich sicher), aus Nutzersicht hat das allerdings keinerlei besondere Bedeutung. Ist also eigentlich Unfug dass ich das hier staendig verwende, im LBS ist es aber so umgesetzt (Sync-Master und Sync-Member sind Eigenschaften des Clients), daher tu ich das wohl permanent.

[rdeckard]

Ja, bei der Durchsage würde ich auch den Fokus auf den Start legen. Wie bringt man die Durchsage-Datei so schnell als möglich an die Player. (Dass das nicht synchron ist, wäre nicht so tragisch. Ist ja eine Durchsage und kein Musik hören.)
Und wenn das anschliessende "Aufräumen" (Resync) der Player dann wieder Zeit benötigt, ist das nicht so tragisch. Das wäre sicher zu akzeptieren. Also aus meiner Sicht zumindest.

[jonofe]

Michael, ich habe nochmal eine andere Frage zum Squeeze Client LBS: Ist es möglich am Ausgang des Clients die aktuelle Playlist bereitzustellen? Ich bräuchte diese für eine Logik, in der ich auswerten möchte, ob die Default-Playlist geändert wurde.

Hintergrund: Im Bad startet bei Einschalten des Lichts eine Standard-Playlist. Der Squeeze Client wird ausgeschaltet sobald das Licht ausgeschaltet wird. Wenn aber inzwischen eine andere Playlist gestartet wurde, dann soll bei Ausschalten des Lichts die Playlist weiterlaufen.

Dazu müsste ich beim Ausschalten des Lichts überprüfen ob die aktuelle Playlist = Standard-Playlist ist. Derzeit kann ich die aktuelle Playlist aber nicht vom SqueezeClient bekommen.

[wintermute]

Hi André,

meinst Du den Namen oder den Inhalt der Playlist?

EDIT: die Doku erwaehnt das hier

Timestamp of the current playlist, in secods. Changes to the playlist (insertion/removal/shuffling) result in an increase of this value. This can be used to detect the entire playlist has to be reacquired.

Ich habs nicht probiert, aber ich vermute der timestamp aendert sich auch wenn die Playlist komplett geaendert wird. Vorteil ist, dass das auch bei nicht-gespeicherten Playlists funktionieren muesste. Die Eigenschaft muesste auch schon vom LMS gesendet werden, liegt nur noch nicht auf nem Ausgang...

[jonofe]

Hi André,

meinst Du den Namen oder den Inhalt der Playlist?

Hi Michael,

Ich meine den namen der Playlist, d.h. in meinem konkreten Fall ist es der 1live Radiostream: http://opml.radiotime.com/Tune.ashx?id=s100198

EDIT: die Doku erwaehnt das hier

Timestamp of the current playlist, in secods. Changes to the playlist (insertion/removal/shuffling) result in an increase of this value. This can be used to detect the entire playlist has to be reacquired.

Ich habs nicht probiert, aber ich vermute der timestamp aendert sich auch wenn die Playlist komplett geaendert wird. Vorteil ist, dass das auch bei nicht-gespeicherten Playlists funktionieren muesste. Die Eigenschaft muesste auch schon vom LMS gesendet werden, liegt nur noch nicht auf nem Ausgang...

Bedeutet das, dass der timestamp die Anzahl Sekunden angibt, die die aktuelle Playlist schon läuft? Ich müsste mir dann die Zeit des Startens der Playlist merken (Einschaltzeitpunkt des Lichts) und dann beim Ausschalten des Lichts prüfen, ob die Zeitdifferenz (aktueller timestamp minus gespeicherter timestamp) zur Einschaltdauer des Lichts passt? Hab ich das richtig verstanden?

[wintermute]

Ich meine den namen der Playlist, d.h. in meinem konkreten Fall ist es der 1live Radiostream: http://opml.radiotime.com/Tune.ashx?id=s100198

Das Problem dabei ist, dass nur abgespeicherte Playlisten Namen haben, die anderen haben nur Tracks... in der Nomenklatur waere die URL von oben also ein Track innerhalb der Playlist...

Bedeutet das, dass der timestamp die Anzahl Sekunden angibt, die die aktuelle Playlist schon läuft? Ich müsste mir dann die Zeit des Startens der Playlist merken (Einschaltzeitpunkt des Lichts) und dann beim Ausschalten des Lichts prüfen, ob die Zeitdifferenz (aktueller timestamp minus gespeicherter timestamp) zur Einschaltdauer des Lichts passt? Hab ich das richtig verstanden?

Nein, einfacher.... so wie es aussieht (hab grad mal probiert) steht da der Zeitpunkt der letzten "Aenderung" der Playlist als Epochalzeit drin.
Du kannst Dir das selber mal ansehen wenn Du im Client-LBS folgende Zeile reinkommentierst:

LB_LBSID_debug($id,'APC dump: '.print_r($player,true),$playerID); 

Dann siehst du jedes Update im Trace.log, halte da mal Ausschau nach playlist_timestamp...

EDIT: in kurz - aendert sich der playlist_timestamp kannst Du Dir sicher sein, dass sich die Playlist irgendwie geaendert hat...

[jonofe]

EDIT: in kurz - aendert sich der playlist_timestamp kannst Du Dir sicher sein, dass sich die Playlist irgendwie geaendert hat...

Ah, okay, das klingt einfach. Aber wenn ich es richtig verstanden habe, gibt es den Timestamp noch nicht auf den Ausgängen, oder?
Aber ich sehe auch noch 3 "unused" Ausgänge ...

[wintermute]

Richtig
Die unused-Ausgaenge sind in (meiner) aktuellen Version schon belegt, aber das kann ja auch noch wachsen... ich kann das im naechsten Release mit reinbauen (oder rausschicken). Du kannst das aber auch selber in Deine Version reinbauen - zum rumprobieren...
Suche folgende Zeile:

# other properties 

Und schreib darunter:

setLogicLinkAusgang($id,17,$player['playlist_timestamp']); 

(oder nen anderen Ausgang)
Ist halt nur nicht fuer die Ewigkeit

[rdeckard]

Ich habe am Wochenende 2 weitere Squeeze-Player (Raspi mit PiCorePlayer) eingebunden. D.h. zurzeit hätte ich 4 Player (ein fünfter folgt vermutlich diese Woche).
Somit kann ich nun nicht nur zwischen nur 2 Playern synchronisieren, sondern mehreren.

Dabei hatte ich schon meine ersten Probleme. Ich habs nämlich noch nicht geschafft, alle 4 Player zusammen als eine Gruppe zu synchronisieren (im LMS GUI). Max. 3 Player bringe ich ihn.
Und sehe ich das richtig, dass man mehrere Synchronisierungs-Gruppen definieren könnte? Also z.B. Player 1+2 sind jeweils miteinander synchronisiert und Player 3+4 ebenfalls. Damit könnte ich z.B. alle Player im OG separat von den Playern im EG steuern? (War mir bis jetzt nicht so bewusst)

Die Problematik, dass man für die Durchsage EINE Gesamt-Gruppe erstellen müsste, bleibt natürlich immer noch.

Vielleicht hat da jemand noch paar LMS-Tipps parat (hat jetzt nur indirekt mit dem LBS zu tun).

[rdeckard]

Michael, ich habe im Moment meine 4 Player auf 2 x 2 Gruppen aufgeteilt (Synchronisiert). 2 Player wären fürs OG und 2 fürs EG, sodass ich zumindest pro Stockwerk getrennt Musik hören kann. (Ich habe das Büro im OG und höre dann gerne Musik, während meine Frau im EG vielleicht TV schaut und dann natürlich keine Musik hören möchte.)
Es sollte ja reichen, wenn ich jeweils einen Player aus der Gruppe ansteuere, da ja der LMS den Rest macht.

Wie muss ich dazu die Logik ändern, damit ich zumindest diese beiden Gruppen getrennt steuern kann? Hier ein Bild, wie es im Moment aussieht:

squeeze18.png

Habe einfach mal den Command und Client LBS dupliziert und die PlayerID entsprechend angepasst. Jetzt muss ich vermutlich noch eine Menge neuer KOs für den 2. Player erstellen. Etwas unklar ist mir aber das KO für den Client. Muss ich die StatusKO (E1) und KommandoKO (A1) auch neu anlegen oder können die für mehrere Clients gleich bleiben?

gaert
Gerade für diese Logik musste ich sehr viele interne KOs anlegen. Jetzt muss ich diese noch ein zweites Mal erstellen, was mit Duplizieren (pro KO) natürlich möglich ist.
Aber um die Übersicht bei dieser dann sehr langen Liste zu erhöhen, habe ich mich jetzt für zwei Ordner entschieden.
Nur, wie bekomme ich die bereits bestehenden KOs in den Ordner rein?
squeeze19.png

Ich denke, es geht nicht und ist vermutlich schon lange auf deiner sehr langen Wunschliste drauf. Aber das würde das Handling von KOs schon extrem verbessern. (Mehrfachselektion, dann rechte Maustaste mit einem Befehl wie z.B. "Kopieren nach" oder von mir aus mit mehreren Schritten ähnlich beim "Merken")

[gaert]

Das geht - allerdings nur einzeln... "Merken" und "Hierher verschieben"

PS: Ganze Ordner duplizieren ist in Arbeit...

PPS: Oder einen Datenbank-Editor installieren und manuell die ForlderID ändern - so mache ich das zur Zeit