LBS(Sammlung) Squeeze

[Winni]

Noch eine Frage zu Sleep:
Bringt der Ausgang die restliche Zeit bis abgschaltet wird, oder "nur" den Wert der ursprünglich übergeben wurde?
Ein laufendes herunterzählen ist nun wirklich nicht notwendig, aber ich fände es schön, wenn der Ausgabewert die Ausschaltzeit liefern würde.
Kann man natürlich selber ausserhalb des LBS jederzeit machen, deswegen geht's mir hauptsächlich um eine Aufklärung was eigentlich geliefert werden soll.

Danke, Winni

[wintermute]

Bringt der Ausgang die restliche Zeit bis abgschaltet wird, oder "nur" den Wert der ursprünglich übergeben wurde?

RTFM

A17: Sleep-Modus - Zeit in Sekunden bis der Player abschaltet (nur wenn 'sleep' aktiv), sonst 0

Das ist momentan so, weil das genau die Info ist, die der LMS auswirft. Sinnvoller waere vielleicht wirklich die Uhrzeit, aber dann muesste der LBS korrekterweise einen Eingang zur Definition der Zeitzone haben o\
Wenn das so wie es ist fuer alle ausreicht (und man das bei Bedarf ueber einen weiteren LBS aunders aufbereiten kann/moechte), dann wuerd ich das eigentlich gern so belassen. Mir ist das aber im Prinzip erstmal schnuppe, ich richte mich da nach dem Bedarf
Ist ja ohnehin nur die erste sleep-Implementierung und daher durchaus noch "Subject-to-change"

[Winni]

RTFM

A17: Sleep-Modus - Zeit in Sekunden bis der Player abschaltet (nur wenn 'sleep' aktiv), sonst 0

Hm, hab' ich durchaus gelesen, ist aber interpretationsfähig.
Bei mir ist es auf alle Fälle so, dass ich 300 Sekunden einstelle, der Ausgang auf 300 Sekunden bleibt (also nicht herunterzählt) und sogar nach Abschaltung weiterhin die 300 behält. In dieser Form macht der Ausgang eigentlich überhaupt keinen Sinn. Schön wäre, wenn zumindest der Ausgang auf 0 geht, wenn der Player abgeschaltet wird (egal ob manuell oder aufgrund des Zeitablaufes.
Alles andere könnte und würde ich extern lösen.

[wintermute]

Ok, ein Bug
Danke, baue ich (irgendwie) um.

BTW: ich hab einen Zeitformatierungsbaustein hochgeladen, das koennte sowohl hier, als auch irgendwann mal beim Kalender hilfreich sein
https://service.knx-user-forum.de/?c...ad&id=19000153

Ich werde den alsbald noch erweitern, so dass auch Epochalzeit rausgeworfen werden kann - damit liessen sich dann recht einfach auch Zeitberechnungen (Addieren, Subtrahieren, Differenz) realisieren...

[Winni]

Wenn ich mir nochwas wünschen darf:
Schuffle ein/ausschalten mit Status... randomplay tracks... würde noch gut zu dem Baustein passen,
Favoriten abspielen werd ich extern machen, ausser du willst das auch noch integrieren:
favorites playlist play item_id:#

[wintermute]

Hmm... weiss der Gleichmacher wieso, aber iwie hatte ich das garnicht auf dem Schirm o\
Ja, klar... gehoert DEFO dazu, wird verbaut.

Danke!

[wintermute]

Ok, ein Bug

Das ist gar kein Bug, das steht auch in der Hilfe:

Ein Wert ≠0 an E5 aktualisiert die Zeit-Infos des aktuellen Tracks (also Time, Duration und Position) sowie zur Dauer bis zum Sleep-Modus (falls aktiv).

Allerdings ist das trotzdem nicht ganz normal, denn zumindest wenn der Player ausgeht muesste der Wert (automatisch) auf 0 springen, also ohne refresh.

[rdeckard]

So, Michael. Ich bin nach einer kurzen Zeit der Abstinenz (wegen Neuverkabelung der Lautsprecherkabel im Netzwerkschrank) nun wieder beim Thema Squeeze.
Nach langen Vorlaufschwierigkeiten habe ich es am Wochenende sogar geschafft, meine SIP Türstation so einzubinden, dass ein Drücken der Klingeltaste ein MP3 über Edomi und dem Squeeze LBS (Durchsage) abspielt! (Jetzt fehlt mir nur noch das Montieren von weiteren Deckenlautsprecher im EG und weitere Raspi Squeezeplayer für die noch fehlenden Zonen)

Leider kommen aber jetzt auch wieder (die etwas verdängten) Probleme mit dem Squeeze LBS (bzw. dem ganzen LMS-System) zum Vorschein.

Zurzeit habe ich immer noch (nur) 2 synchronisierte Player (Bad und Büro) und die folgenden Probleme:

1. Player-Stati werden nicht oder nur stark verzögert an den synchronisierten Player angezeigt.
2. Pause-Funktion geht nicht (mehr). Musik stoppt für einen kurzen Augenblick, spielt aber dann sofort wieder weiter.
3. Relative Lautstärkeänderung (+/-) nimmt zurzeit einen anderen Inkrementswert, als eigentlich angegeben.
4. Ist der Player auf Stop und man spielt eine Durchsage, so wird nach der Durchsage die gecachte Playerliste gestartet, anstatt wieder auf Stop zu gehen.
5. Ist der Player auf Off, so wird eine Durchsage nicht abgespielt (ich dachte, die Durchsage schaltet den Player automatisch ein)

Das sind jetzt nur so meine Erfahrungen von gestern Abend. Ein paar Sachen haben früher problemlos funktioniert. Könnte also sein, dass ich irgendetwas falsch konfiguriert habe (obwohl ich eigentlich am LBS/LMS-System nichts grossartiges geändert habe).

Ein Hauptproblem (und nun mit der Türklingel-Durchsage akut) ist jedoch die Frage, wie man eine Durchsage auf ALLE Player (oder zumindest eine vordefinierte Gruppe) senden kann, unabhängig von den aktuell konfigurierten Player-Gruppen (Synchronisierungen).
Ich habe die Befürchtung, dass wir hier die Grenze des Squeeze-Systems überschreiten. Denn dafür wurde dies ja nicht entwickelt. (Ist ja keine Musik-Matrix, mit der man x-Player mit x-Musikquellen schnell verbinden UND synchronisieren kann.)

Klar geht das Ganze in das (noch offene) dynamische Gruppieren/Synchronisieren von Playern über den LBS. Aber selbst wenn das mal klappen würde, so müsste der LBS bei jedem Klingeln (bzw. bei jeder Durchsage) zuerst alle Player synchronisieren (in meinem Fall wären es im Endausbau ca. 10-12 Zonen) und dann die Durchsage abspielen. Ich glaube nicht, dass das so schnell gehen wird, wie wir es uns vermutlich wünschen. Gerade bei einer Klingel erwartet man ja sofort beim Knopfdrücken einen Ton und nicht erst 10 Sek. später. (Bei anderen Durchsagen wäre es nicht so kritisch, weil man da den Zeitpunkt der Auslösung nicht so exakt kennt.)

Bin zwar immer wieder positiv überrascht, wie schnell schon jetzt mein Türstation-Klingelton abgespielt wird, wenn man den Weg bedenkt. (SIP-Station gibt über ein Relais ein Signal aus, welches im Hauptverteiler an einem Binäreingang abgefangen wird. Dies triggert eine GA, welche dann von einem Edomit LBS erkannt wird und anschliessend über den Squeeze LBS ein MP3 über den LMS und Raspi Player abspielt. Und das passiert gefühlt in Echtzeit, sofern die Player aktiv sind.)

Aber das Gruppieren von vielen Playern könnte dann schon eine Spur länger dauern. Evtl. dann zu lange.

Alternativ wäre natürlich das Ausweichen auf einen Multizonen-Vertärker. Aber das lasse ich mir im Moment noch etwas offen. (Komplett neue Baustelle und ja auch nicht ganz günstig.)

Wie stehst du eigentlich zum Thema Synchronsieren, vorallem jetzt auch bei Durchsagen?

(Ich werde mich in den nächsten Tagen sicher bisschen intensiver um die oben erwähnten Probleme mit Debugs etc. kümmern.)

[wintermute]

Zurzeit habe ich immer noch (nur) 2 synchronisierte Player (Bad und Büro) und die folgenden Probleme:

Erstmal (wie immer) danke fuers Feedback, dadurch hab ich ein paar konkrete Ansatzpunkte zum Weiterbauen

-Player-Stati werden nicht oder nur stark verzögert an den synchronisierten Player angezeigt.

Das muss ich nachstellen, bin ich bisher nur noch nicht zu gekommen...

-Pause-Funktion geht nicht (mehr). Musik stoppt für einen kurzen Augenblick, spielt aber dann sofort wieder weiter.

Ich vermute, Du hast 2 Client/Kommando-LBS und schickst einen Befehl an beide Player synchron, richtig?
Dann hat das wahrscheinlich damit zu tun, dass das von Dir gewaehlte Kommando des Status umschaltet. Da beide Player durch den Sync dasselbe tun, passiert also das folgende:
-Client-LBS 1 empfaengt pause/play-Umschaltung fuer Player 1 und schaltet (zB) von Play auf Pause
-der LMS schickt denselben Befehl an Player 2 (weil die ja im Sync sind) und Player 2 schaltet (zB) von Play auf Pause
-Client-LBS 2 empfaengt pause/play-Umschaltung fuer Player 2 und schaltet (jetzt) von Pause auf Play
-der LMS schickt eben wieder diesen Befehl an Player 1 (weil die ja im Sync sind)
Ergebnis: Play/Pause/Play
Ich habe das jetzt nicht nachgestellt, aber vermutlich hat das damit zu tun...

-Relative Lautstärkeänderung (+/-) nimmt zurzeit einen anderen Inkrementswert, als eigentlich angegeben.

siehe obigen Punkt, aber auch Post #4:
https://knx-user-forum.de/forum/proj...726#post927726
fisch3009 hast Du da eigentlich etwas naeheres zu rausgefunden?
Wenn ich nur einen Player (unsynchronisiert) steuere funktioniert das...

-Ist der Player auf Stop und man spielt eine Durchsage, so wird nach der Durchsage die gecachte Playerliste gestartet, anstatt wieder auf Stop zu gehen.
-Ist der Player auf Off, so wird eine Durchsage nicht abgespielt (ich dachte, die Durchsage schaltet den Player automatisch ein)

Das liegt einfach daran, dass der Durchsage-LBS noch nicht fertig ist... das kommt aber noch

Ein Hauptproblem (und nun mit der Türklingel-Durchsage akut) ist jedoch die Frage, wie man eine Durchsage auf ALLE Player (oder zumindest eine vordefinierte Gruppe) senden kann, unabhängig von den aktuell konfigurierten Player-Gruppen (Synchronisierungen).

In der ersten Planung sollte der Durchsage-Baustein auch an einen Broadcast senden koennen, das habe ich aber mittlerweile wieder verworfen. Grund dafuer ist im wesentlichen die Tatsache, dass der Baustein nach einer Durchsage darauf wartet, dass der betreffende Player auf "Stop" schaltet und dann den bisherigen Zustand wieder herstellt. Oder aber eben dasselbe tut, wenn die Durchsage durch einen Befehl unterbrochen wird.
Das wird a) zu unflexibel und b) zu undurchschaubar in der Programmierung, daher habe ich mich dazu entschieden, dass fuer jeden Player der Durchsagen spielen soll ein eigenen Durchsage-LBS verbaut werden muss. Das hat dann auch den Vorteil, dass man bestimmte Ansagen nur zu bestimmten Playern schickt oder Ruhezeiten oder sowas aehnliches je nach Player realisieren kann. Davon ab geh ich da mit Deiner Einschaetzung konform, dass vorheriges Synchronisieren der Player (nur zum Zwecke der Durchsage) nicht so prickelnd ist...

Wie stehst du eigentlich zum Thema Synchronsieren, vorallem jetzt auch bei Durchsagen?

Das Verbubbeln stellt momentan prinzipiell ein Problem dar (siehe auch oben angefuehrte Issue) aber wie schon geschrieben wird es offiziell ja noch nicht unterstuetzt
Im Prinzip koennte man den Sync ja dadurch "simulieren", dass man mehrere Player durch die Bausteine parallel ansteuert, aber dadurch geht das IMHO sehr wichtige Feature des Syncens verloren, naemlich die zeitliche Synchronisation beim Abspielen. Also muss der LMS-Sync irgendwann mal sauber implementiert werden, da geht wohl kein Weg dran vorbei. Die ersten Schritte in die Richtung sind ja auch schon getan, die Client-Bausteine wissen ob sie Sync-Slave oder Master sind und wissen ebenfalls wie die "eigene" Sync-Gruppe ausschaut.
Jetzt hab ich da aber nen prinzipielles Dingen mit: naemlich was soll der Client-LBS tun, wenn er zB ein Kommando erhaelt, aber ein Sync-Slave ist?
Korrekt waere entweder:
a) das Kommando ignorieren und garnix machen oder
b) das Kommando an den Master der eigenen Gruppe weitergeben und dem Master die Ausfuehrung ueberlassen

Was jedenfalls konzeptionell nicht vorgesehen ist, dass mehrere Client-LBS identische Kommandos empfangen (wie hier in vielen Szenarien gesehen). Klar kann man das so machen, aber es funktioniert dann alles nicht mehr richtig wenn man im LMS Sync nutzt.
Wuerde man a) von oben realisieren, so muesste die Logik staendig wissen wer jetzt eigentlich der betreffende Master ist und die Visu und/oder die KOs entsprechend aufbereiten bevor sie an den Baustein gegeben werden. Das ist IMHO schwer unpraktisch und daher nicht wirklich praktikabel... allerdings wuerde das "parallele Verschicken von Kommandos" von oben in dem Szenario funktionieren.
Wuerde man b) von oben umsetzen, so wuerde es aus Sicht der Visu sicherlich besser funktionieren (denn da steuere ich ja immer nur einen Player, streng genommen), allerdings funktionieren dann die "parallelen Kommandos" nicht mehr.

Ich bin eigentlich ziemlich ueberzeugt, dass b) der richtige Weg ist. Das bedeutet aber, dass einige hier gezeigte Szenarien umgebaut werden muessten weil sie dann so nicht mehr funktionieren werden. Allerdings muss man da dann evtl Ausnahmen treffen wenn es um Durchsagen geht - auch weiss ich momentan noch nicht wie sich das mit der Verbubbelung der Lautstaerke verhaelt, ich muss mir da in einer ruhigen Minute mal ein Testszenario zusammenbasteln um das naeher untersuchen zu koennen...

[rdeckard]

Darf ich mal schüchtern fragen, ob du evtl. wieder mal am Durchsage-LBS arbeitest?

Nachdem ich nun meine SIP Türstation als Klingel konfigurieren konnte, fehlt mir nur noch dein Durchsage-LBS. Genauer gesagt, sollte nach dem Abspielen einfach der Zustand vor dem Abspielen hergestellt werden. (Wenn AUS oder auf STOP, wieder auf AUS/STOP setzen)

Im Moment wird zwar die vorherige Playliste wiederhergestellt, aber der Playstatus nicht. War der Player vorher gestoppt und man spielt eine Durchsage ab, dann spielt nach der Durchsage die (Musik/Radio) Playlist. D.h. wenn jemand tagsüber in meiner Abwesenheit die Klingel betätigt, läuft dann den Rest des Tages Musik im Haus.

Ich vermute, es fehlt nicht viel...aber wäre genial, wenn du das bei Gelegenheit noch fixen könntest.

Danke!

[wintermute]

Darf ich mal schüchtern fragen, ob du evtl. wieder mal am Durchsage-LBS arbeitest?

Ja! Nein! Doch! Ohh! Also...
Moechten tu ich schon gern, aber mir fehlt momentan irgendwie die Zeit ein Test-Szenario zusammen zu basteln - momentan komm ich irgendwie zu nix.
Ich versuche mich zu bessern - es ist nicht so, dass ich das Thema einschlafen lassen moechte, ich brauch das ja beizeiten auch selber...

gruesse :: Michael

[rdeckard]

Mir war gar nicht bewusst, dass das "Durchsage-Problem" auch mit dem Sync (mehrere Player) zusammenhing. Ich habe jetzt in der Logik nur mal ein Player "verdrahtet", weil die Synchronisierung ja eh der LMS verwaltet. (Und unterschiedlich steuern muss ich es ja vom Edomi noch nicht, solange die Sync-Funktionalität noch nicht implementiert ist.)
Und wenn ich jetzt die Durchsage abspiele, dann wird der alte Player-Status eigentlich korrekt wiedergegeben. Folgende Tests habe ich gemacht:

VOR DURCHSAGE	NACH DURCHSAGE
Playing	Playing
Pausiert	Gestopped (oder pausiert?)
Gestopped	Gestopped (oder pausiert?)
Off	On (Playing)

Ob er nach der Durchsage gestopped oder nur pausiert war, weiss ich jetzt grad nicht. Mir fiel nur auf, dass er weiterspielte, nachdem ich nur auf PAUSE geklickt habe.

Einziges Problem scheint der Zustand OFF vor der Durchsage zu sein. Denn dann müsste er nach der Durchsage sich auch wieder ausschalten. Aber bleibt auf On (und schlimmer, spielt dann die Standard-Playlist ab).

Aber damit kann ich jetzt schon die Klingel nutzen. Muss einfach den Player auf ON (und stopped) setzen.

[wintermute]

Ja, das mit dem Verbubbeln stellt fuer die Durchsage in der Tat ein Problem dar. Ich weiss noch nicht wirklich wie ich damit am besten umgehe...
Vorneweg: das mit dem On/Off/Repeat/Shuffle-Status war in der ersten Version einfach nicht implementiert, das kommt. Sync ist etwas problematischer.

Erstmal: wenn man mit Syncs arbeitet, dann ist es keine gute Idee Kommandos parallel an mehrere Clients zu geben, das fuehrt nur zu Verwirrung. Aber auch wenn man das nicht so macht, dann gibts bei den Durchsagen Probleme, weil ja die Durchsagen-LBS pro Clients sind. Bei ner Bimmel zB legt man die ja gern "fest" auf unterschiedliche Clients. Die Frage ist dann: was passiert bei einer Durchsage? IMHO waers am sinnvollsten eine Durchsage nicht abzuspielen wenn der Player Mitglied einer Sync-Gruppe ist, also den Durchsagen-Befehl einfach zu ignorieren. Wenn der Player dann aber grad in einer Sync-Gruppe ist, zu dessen Master keine Durchsagen geschickt werden, dann bleibts stumm... waer auch doof...

Wie soll man das am besten loesen? Hat da jemand ne Idee zu?

[fisch3009]

Idee dazu:
Wenn einer der synchronisierten Player von der Durchsage betroffen ist:
- Synchronisierung trennen
- Durchsage absetzen
- Synchronisierung wiederherstellen
- Zustand von vorher an den Master wieder absetzen (wie ist das eigentlich mit dem Master zu verstehen, sind nicht alle Player gleich berechtigt, wenn sie synchronisiert sind? Zumindest wirkt das so, wenn ich über Squeezer oder die Weboberfläche an irgendeinen der synchronisierten Player einen Auftrag (Play, Pause, andere Titel) gebe, wird das durchgeführt)

[rdeckard]

wie ist das eigentlich mit dem Master zu verstehen, sind nicht alle Player gleich berechtigt, wenn sie synchronisiert sind? Zumindest wirkt das so, wenn ich über Squeezer oder die Weboberfläche an irgendeinen der synchronisierten Player einen Auftrag (Play, Pause, andere Titel) gebe, wird das durchgeführt

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. (Das Wort Synchronisierung bezieht sich in diesen Fällen dann auf die Audio-Quelle und vorallem auf das synchrone Abspielen)
Natürlich kann man aber auch alles synchronisiert steuern...vereinfacht die Sache natürlich stark.