LBS(Sammlung) Squeeze

[rdeckard]

Das mit zwei verschiedenen Kommando- und Status-KO hat (wie erwartet) nicht funktioniert. Hab jetzt (bis auf diese beiden KOs) alle KO's für jede Player-Gruppe doppelt erfasst und zugewiesen. Es funktioniert soweit auch gut. Nur ein Problem habe ich: die Pausen-Funktion für die eine Player-Gruppe geht nicht, obwohl ich die KO's gecheckt habe. Die restlichen Kommandos für diese Player-Gruppe funktionieren.
Bei der anderen Player-Gruppe geht alles. (Muss glaub nochmals genauer suchen...irgendwo habe ich was falsch eingetragen)

Bei der Durchsage habe ich natürlich jetzt das Problem, dass ich diese ja nur einer PlayerID (und somit nur eine Player-Gruppe) fix zuweisen kann. Da meine Türklingel auch darüber geht, werde ich vermutlich die Klingel-Durchsage auf die EG-Player-Gruppe setzen. Dann hört man wenigstens dort den Gong über die Lautsprecher.

Was passiert eigentlich, wenn ich den Durchsage-LBS ein zweites Mal in die Logik nehme (dann mit der PlayerID der zweiten Player-Gruppe)? Könnte man so durch EINEN Trigger (z.B. Klingeltaste) ZWEI (identische) Durchsagen parallel auslösen? Dass diese dann nicht synchron sind, wäre in diesem Fall nicht so tragisch (EG und OG sind ja soweit getrennt, dass man das kaum bemerken würde. Zudem geht es ja um einen Gong oder sonstige Durchsagen.)
Das wäre evtl. noch ein gute Alternative für das Ansage-an-Alle-Problem.

[starwarsfan]

Hi,

ist es korrekt, dass Du im zweiten Command-LBS an E2 das gleiche KO verwendest, was in beiden LBS an E11 anliegt?

Hier ein Bild, wie es im Moment aussieht:

2016-05-04_Squeeze.png

[wintermute]

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.

Ja, korrekt... damit sollten auch die Probleme mit doppelten Befehlen, verzoegerten und sonderbaren Rueckmeldungen aufhoeren... hoffe ich

Wie muss ich dazu die Logik ändern, damit ich zumindest diese beiden Gruppen getrennt steuern kann? Hier ein Bild, wie es im Moment aussieht:
...
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?

Kommando- und Status-KO werden immer nur einmal benoetigt (streng genommen einmal fuer jeden Server-LBS). Die Logik sieht fuer mich erstmal ok aus so wie sie ist.
Aber ja, wenn man das in die Visu bringen will, dann braucht man entsprechende KOs (intern) fuer die jeweiligen Clients... oder aber fuer Client-Gruppen, wenn die Synchronisierung dauerhaft so bleiben soll, dann reicht es ja dass jeweils fuer einen Player aus der Sync-Gruppe zu erstellen.
Wenngleich mein Ziel schon waere, das in Zukunft "sauberer" gestalten zu koennen

[gaert]

Sofern Du die richtige FolderId angibst ist's gefahrlos Am Besten erstmal 1 KO per GUI verschieben und dort die FolderId in der DB ablesen...

[rdeckard]

Ja, das mit der FolderID direkt in der DB ändern ist in diesem Fall wohl das schnellste (und sollte ja auch einigermassen gefahrlos sein).
Das mit dem einzeln "Merken/Verschieben" habe ich übersehen. Ist immerhin eine Möglichkeit. ;-)

[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

[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")

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

[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

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

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]

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]

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]

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.

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