LBS(Sammlung) Squeeze

[wintermute]

Aaalsooo... bezugnehmend auf fisch und den Bladerunner
Wie von fisch schon bemerkt: Intern arbeitet der LMS grundsaetzlich nur mit Playlisten, auchs wenns nicht so ausschaut. Also auch wenn ich zB nur einen Track auswaehle, so wird daraus im Player eine Playlist die er abarbeitet. Eine solche Playlist technisch dann auch dasselbe wie eine gespeichte Playlist im LMS - darum kann man im LMS auch eine Playlist zusammenstellen und dann unten rechts auf "Speichern" klicken. Eine Playlist kann im Repeat oder ohne Repeat laufen, zudem gibt es noch 3 Shuffle Modi:
1) kein Shuffle
2) Tracks zufaellig sortieren
3) Alben zufaellig sortieren

Wenn eine Durchsage abgespielt wird, dann wird eine temporaere Playlist mit der Durchsage erzeugt und die aktuelle Playlist als tempplaylist_<playerID> gespeichert. Dieser Vorgang wird vom LMS allein durchgefuehrt, der Baustein erzeugt nur die Playlist mit der Durchsage und spielt die dann ab.
Wenn diese "Durchsagen-Playlist" abgelaufen ist (also der Player wieder in den Modus "stop" wechselt), dann wird die tempplaylist restauriert und (je nach vorheriger Situation) wieder abgespielt. Auch das macht der LMS alleine, also wenn da zB die Position im Track nicht stimmt, dann hat der LMS das verbockt, nicht ich

Einschub: mir persoenlich kommt das so vor, als taete der LMS die aktuelle Position nicht staendig speichern, sondern nur mal so "zwischendurch". Auch beim Restaurieren steht im Player zunaechst mal der Trackanfang, wird aber abgespielt, springt der Player auf die letzte Position im Track. Zumindest bei mir
Allerdings funktioniert das scheinbar nicht, wenn die Position im Track zB "nah am Anfang" stand. Und schnelle Wechsel (besonders beim testen) haben mir auch teilweise dazu gefuehrt, dass der LMS die Position vergessen hat, im "Wirkbetrieb" ist mir das Verhalten allerdings bisher nicht nachvollziehbar untergekommen...
Drum: am besten nicht hektisch KOs setzen, sondern dem LMS nach einer Durchsage 2 oder 3 Sekunden Zeit geben, damit er sich wieder setzen kann
Einschub Ende

Wenn die aktuelle Playlist auf Repeat steht, dann wird auch die Durchsage im Repeat gespielt (wie geschrieben, das ist einfach noch nicht fertig, kommt aber - natuerlich). Das bedeutet, dass der Player von alleine nicht mehr zum "stop" kommt und daher auch die tempplaylist nicht mehr restauriert wird - es sei denn, man schaltet manuell auf "stop" (nicht auf "pause", es muss schon "stop" sein!).
Wenn die aktuelle Playlist im Shuffle steht, dann wird die Trackposition nicht gespeichert und beim Restaurieren bei einem zufaelligen Track gestartet. Das ist vom LMS so beabsichtigt, ist also "by-design" und IMHO auch sinnvoll. Dennoch muss der Baustein irgendwann mal diese Status korrekt verwerten und verarbeiten. Wie gesagt, das kommt noch...
Eine Verzoegerung beim Restaurieren (oder besser vorm Abspielen) der tempplaylist kann zB daher kommen, dass die Verbindung zum Remote-Stream erst wieer aufgebaut werden muss. Wenn da Verzoegerungen auftreten kommt das leider aus der Natur der Sache, da kann man auch nix dran machen
Aber wie schon geschrieben tritt das (wenn ueberhaupt) nur bei Remote-Streams auf, lokale Playlisten sollten sofort wieder anspringen.

Warum der Kommando-LBS nur Playlisten und keine vorgegebenen URLs oder Files abspielen kann, hat damit zu tun, dass ich das selber so am praktischsten fand, vor allem wenn man das in einer Visu darstellen moechte (zB mit Radio Icons oder so). Technisch spricht natuerlich nix dagegen auch direkte Streams im Kommando-Baustein verwertbar zu machen, aber ich denke das ist im Handling zu kompliziert... andersrum isses ja nur ein zusaetzlicher Eingang, bau ich also mal dazu. Aber mit gespeicherten Playlisten im LMS ist es bedeutend einfacher, glaubt mir

Die Variable V1 enthaelt den Timestamp (in Epochalzeit) wann die aktuelle Ansage gestartet wurde und wird zu 0 wenn die Ansage zu Ende ist. Das wird spaeter dafuer benoetigt, Ansagen im Repeat oder Ansagen die einfach zu lang sind, nach einer bestimmten Zeit abzubrechen. Mit der aktuellen oder letzten Position im track hat das nix zu tun, das verwaltet - wie gesagt - der LMS alleine.

[wintermute]

Edit: Fehler gefunden

Puh...

[fisch3009]

Wieder einiges klarer geworden.
Warum meine per Visu ausgelösten KNX-Telegramme (alle nicht nur die Durchsage KO) immer zweimal eintreffen ist mir zwar noch nicht klar, aber das hat ja nichts mit deinem Baustein zu tun.

Das mit dem Position wiederherstellen, klappt bei mir aber auch nach längerem Laufen lassen eines Tracks nicht, wenn du das dem LMS nicht sagst, sondern der LMS das intern aus seiner Playlist (habe ich das so richtig verstanden) wiederherstellt, kannst du da auch nichts dran machen. Vielleicht bin ich ja immer noch zu ungeduldig :-)
Einen Wunsch hätte ich noch, ich finde das mit den Playlisten beim Kommando LBS viel praktischer als die Dateinamen beim Durchsage LBS, würde mir also beim Durchsage LBS, wenn ich darf auch wünschen, dass ich da ne Playliste ranschreibe (ich möchte eigentlich nicht herausfinden, wo meine Musikdateien jetzt genau liegen, wenn ich mir für jede Ansage einfach ne Playlist im LMS zusammenklicke finde ich persönlich das einfacher zu pflegen).
Auf jeden Fall sehr gute Arbeit!!!

[wintermute]

Warum meine per Visu ausgelösten KNX-Telegramme (alle nicht nur die Durchsage KO) immer zweimal eintreffen ist mir zwar noch nicht klar, aber das hat ja nichts mit deinem Baustein zu tun.

Vielleicht Wechsel zwischen 1/0? Also beim Druecken/Loslassen? Ich kanns leider nicht nachvollziehen, ich hab noch immer keine Visu

Das mit dem Position wiederherstellen, klappt bei mir aber auch nach längerem Laufen lassen eines Tracks nicht, wenn du das dem LMS nicht sagst, sondern der LMS das intern aus seiner Playlist (habe ich das so richtig verstanden) wiederherstellt, kannst du da auch nichts dran machen. Vielleicht bin ich ja immer noch zu ungeduldig :-)

War auch bei mir bisher ein grosses Problem... (eigentlich das groesste, bisher) ich bin da aber weiter dran und probiere rum... im schlimmsten Fall muss ich gucken wie ich die Position im Baustein restaurieren kann. Ich schreib da nochmal was zu wenn ich mehr rumprobiert habe, wie gesagt ist der Durchsage-Baustein erstmal nur ne Sneak-Preview fuer die Unerschrockenen

Einen Wunsch hätte ich noch, ich finde das mit den Playlisten beim Kommando LBS viel praktischer als die Dateinamen beim Durchsage LBS, würde mir also beim Durchsage LBS, wenn ich darf auch wünschen, dass ich da ne Playliste ranschreibe (ich möchte eigentlich nicht herausfinden, wo meine Musikdateien jetzt genau liegen, wenn ich mir für jede Ansage einfach ne Playlist im LMS zusammenklicke finde ich persönlich das einfacher zu pflegen).

Verstehe... ich hab da keine Notwendigkeit gesehen weil es ja prinzipiell keinen Unterschied gibt zwischen nem Filenamen und nem Playlistnamen (und ich finde das eigentlich auch unnoetigen Aufwand fuer jede Durchsage eine eigene Playlist zu erstellen), aber das soll ja nicht nur bei mir funktionieren. Was weiss ich, was Ihr da schlussendlich baut?
Also ja, ich pack nen Playlist-Eingang dazu...

Auf jeden Fall sehr gute Arbeit!!!

Danke, nett zu hoeren!

gruesse :: Michael

[rdeckard]

Michael, habe heute Abend viel rumgetestet und dabei sind mir folgende Dinge aufgefallen:

• Weiterhin falsche oder zumindest verzögerte Anzeige der Stati (Play/Stop/Pause/Volume/Power) bei synchronisierten Player (bei mir 2)
• Wenn ich eine Durchsage auslöse, liefert der zweite Player ein Pause-Status zurück (was dann wieder auf Play korrigiert wird). Die Durchsage läuft aber korrekt auf beiden Playern.
• Aus dem Power Off Modus schaltet eine Durchsage die Player nicht ein. Sie müssen spielen oder zumindest im Stop-Status sein.

Sieht aber nicht so schlecht aus. Das mit den falschen/verzögerten Stati müsste eigentlich funktionieren, da sie auf dem LMS GUI auch korrekt angezeigt werden.

Ich mache mir immer noch Gedanken, wie man die Sache mit der Synchronisierung anpacken sollte. Ich gehe das Problem dabei bewusst von der anderen Seite an, also wie soll man es schlussendlich in der Visu steuern können. Denn es ist klar, dass wir in der Visu (zurzeit) keine Player dynamisch zusammenfassen können. Und selbst, wenn es mal dazu passende Visuelemente gäbe, so denke ich nicht, dass dies der Zweck einer Visu ist. Also kein "markiere Player 1, markiere Player 3, klicke auf Synchronisieren". Das mag in einer mausgesteuerten GUI (wie die LMS GUI) funktionieren, aber sollte nicht der Ansatz für eine (meist) touchbediente Visu sein.

Somit kommt es darauf raus, dass die möglichen Synchronisierungen ("Gruppen") bereits vordefiniert sind und dann einfach nur noch in der Visu angeklickt würden.
Die Gruppen müsste man dann im LBS definieren können. z.B.
SyncGroup01=P1, P3
SyncGroup02=P2, P3, P5
etc.
Ich würde hier auch Gruppen definieren, welche eine Art "Follow-Me"-Funktion abdecken. Manchmal möchte man ja evtl. im ganzen EG oder OG die gleiche Musik hören, manchmal aber nur im Bad, manchmal im Bad und im angrenzenden Schlafzimmer. Dieses dynamische Gruppieren wäre ja am Anfang über die Visu zu steuern gewesen.
Aber eben...selbst, wenn es ginge, sollte man diesen Weg nicht gehen.
Um trotzdem eine Art dynamisches Gruppieren zu ermöglichen, könnte man halt alle in einem Haus sinnvollen Kombinationen vordefinieren können (Bad im OG und Technikraum im Keller muss man ja kaum miteinander synchronisieren wollen). Hat man dies gemacht, wäre man sehr flexibel und könnte in der Visu dann einfach die SyncGruppen anzeigen lassen, die man braucht.
Abhängig von der Anzahl von Zonen, die in einem Haus über Squeeze Player verwaltet würden, können hier doch einige Gruppen entstehen. Ob man diese dann einfach mal als LBS-Eingänge (z.B. 10 Stk.) definiert oder einfach im Code drinlässt, müsste man halt noch prüfen.

Zurzeit werden ja glaub die Player einzig über ihre MAC-Adresse angesteuert. In meinem obigen Beispiel einer typischen SyncGroup wäre eine Auflistung von MAC-Adressen sicher nicht userfreundlich. D.h. im client LBS sollte man dann noch einen Player-Namen definieren können (z.B. P1 oder halt auch Bad) und bei der Gruppe würde man diese aufzählen.

Der technische Teil wäre dann "nur" noch das Auflösen der Player-Namen in die entsprechenden MAC-Adressen und das Senden eines "SYNC MAC1, MAC2, MAC3" (abstrakt gesehen) an den LMS.
Tricky würde noch werden, was du mit bereits laufenden Sync-Gruppen machst. Ein Player kann ja nur in einer Gruppe sei. D.h. man müsste zuerst die einzelnen Player aus einer Gruppe entfernen und dann neu setzen. (Vielleicht macht dies der LMS von alleine, wenn man eine neue Gruppe definiert)
Habe leider immer noch nur mit 2 Playern gespielt. Sobald ich dann mehr habe, sehe ich, wie sich dies verhält.

Das wäre so grob mein "Konzept", wie man das Sync-Thema angehen könnte. In welche Richtung denkst du eigentlich?

[wintermute]

Das wäre so grob mein "Konzept", wie man das Sync-Thema angehen könnte. In welche Richtung denkst du eigentlich?

Danke fuer die Ausfuehrungen!
Momentan waere meine hoechste Prioritaet dabei zunaechst, dass die Player vernuenftig angesteuert werden. Also Play/Pause/Volume und so muss funktionieren. In vielen Faellen scheint es wichtig sein zu wissen, wer der Sync-Master eines Players ist (das waere dann gleichbedeutend mit: ich bin in einer Gruppe). Vorgesehen waere also dem Client-Baustein einen Ausgang zuzufuegen in dem die MAC des Sync-Masters steht. Gleichzeitig kaeme dann noch ein Eingang hinzu, ueber den man die MAC des Sync-Masters setzen kann, also quasi den Player einer Sync-Gruppe zufuegt. So aehnlich isses ja auch im LMS aufgebaut, da sucht man ja auch fuer einen Player den Master aus.
Wie jetzt die verschiedenen Sync-Optionen abgebildet werden (also Power/Lautstaerke - zeitliche Sync werde ich vermutlich fest kodieren, denn das ist IMHO der Hauptvorteil der Verbubbelung) weiss ich noch nicht, das lasse ich mal auf mich zukommen

Ob man Player bei Namen oder MAC identifiziert hab ich mir anfaenglich lange ueberlegt und bin dann bei er MAC haengen geblieben. Das hat vor allem technische Gruende (die MAC ist das erste was man braucht, alle weiteren Infos zu einem Player haengen davon ab - zudem werden alle LMS Kommandos ueber die MAC versendet) allerdings hatte ich mir auch gedacht, dass es in eeiner Gebaeudesteuerung relativ schnuppe ist ob da jetzt intern die MAC oder der Name verwendet wird (die muss ja zB niemand eintippen). Der Client hat einen Ausgang in dem der Name drinsteht, das sollte eigentlich ausreichend sein um auch Sync-Gruppen in einer Visu abbilden zu koennen. Eine Ausnahme davon waere der oben angesprochene Sync-Master: wenn da eine playerID rausfaellt (was der Fall sein wird), dann kann man da vermutlich so viel mit anfangen koennen.
Ich denke fuer solche Zwecke wird dann spaeter nochmal ein Helper-Baustein hinzukommen, der zB playerIDs in Namen (oder andersrum) tauschen kann, oder Kuenstlernamen in IDs oder IDs in Titel... wenn man zB Playlisten zusammenstellen will kann man sowas brauchen.

Aber wie gesagt: erstmal muss ich das Verbubbeln genau begreifen, dann muss ich zusehen dass die bisherige Funktionalitaet hinkommt und dann taste ich mich vorsichtig weiter Aber nochmal danke fuer dein Posting, das hilft schon sehr bei der Orientierung!

gruesse :: Michael

[wintermute]

rdeckard
Zum Verstaendnis Deines Play/Stop Problems: also Du hast zwei verbubbelte Player, zwei Client-Bausteine und schickst ueber das selbe KO (also quasi zeitgleich) einen Play Befehl an beide Client-Bausteine. Ist das so korrekt?

[jonofe]

wie schalte ich eigentlich DEBUG Output an. Ich finde es einfach nicht.

[wintermute]

wie schalte ich eigentlich DEBUG Output an. Ich finde es einfach nicht.

Im Source nach "$DEBUG" suchen und da "1" oder "TRUE" oder "foobar" reinschreiben - ich wollte keinen Eingang extra dafuer reservieren
Gibts allerdings nicht bei allen Bausteinen!

[jonofe]

Okay, hab ich gefunden. Habe gerade das Problem, dass der Squeeze Server Baustein einfach nicht startet.
Habe alle anderen Logikseiten deaktiviert und nur ein Squeeze Server Baustein mit Trigger=1.
Damit müsste doch dann eigentlich ein Prozess laufen, oder? Ich habe keine Ahnung woran es liegt.

2016-03-20 15_56_51-EDOMI · Administration.png

Wie kann ich das denn Debuggen? Im Tracelog erscheint nichts, obwohl DEBUG auf true gesetzt habe. Keine Ahnung wo ich suchen soll.

[wintermute]

Wie kann ich das denn Debuggen? Im Tracelog erscheint nichts, obwohl DEBUG auf true gesetzt habe. Keine Ahnung wo ich suchen soll.

Du kannst ein writeToTraceLog ins den LBS Teil packen und gucken ob er da ueberhaupt ankommt... der EXEC schreibt ziemlich direkt am Anfang einen Eintrag ins Tracelog (auch ohne DEBUG).
Ist vllt die Logikseite deaktiviert?

[jonofe]

Die Seite ist aktiv. Habe schon alle anderen deaktiviert. Nur diese eine ist noch aktiv.
Kann es noch irgendwas mit dem Encoding des PHP Files zu tun haben. Glaube mein altes Zenstudio für Eclipse macht da ggf. Probleme.

[wintermute]

Kann es noch irgendwas mit dem Encoding des PHP Files zu tun haben. Glaube mein altes Zenstudio für Eclipse macht da ggf. Probleme.

Prinzipiell schon, ja... aber dann muesste trotzdem irgendwas passieren und/oder Edomi einen Fehler werfen...
Mach doch mal bitte im Source (im LBS Teil) aus dem

if ($E[1]['refresh']) {
  if ($E[1]['value']) { 

ein

if ($E[1]['refresh']) {
  if ($E[1]['value']) {
    writeToTraceLog(0,true,"debug"); 

Zumindest das sollte dann ja im Tracelog auftauchen...

[Robby]

...steht dein Kommando KO [644] auch auf Variant 10.000 Zeichen

[jonofe]

Glaube ich habe zumindest die Fehlermeldung gefunden.
Normalerweise müsste ein php Prozess mit EXE19000200.php Skript laufen. Dies war nicht der Fall.
Also habe ich mal das Skript welches ja in /usr/local/edomi/www/data/liveproject/lbs/ liegt an der Kommandozeile gestartet und da bekomme ich:

Fatal error: Cannot redeclare finish() in /usr/local/edomi/www/data/liveproject/lbs/EXE19000200.php on line 137

Und ich habe jetzt eine Vermutung. Habe heute morgen owfs (1wire) kompiliert. OWFS baut dabei eine Bibliothek für owfs.so, welche ich in /etc/php.ini.d entsprechend eingebunden habe. Könnte sein, dass dort eine Funktion finish definiert wird.