Test/Support Adapter SqueezeboxRPC
-
In deinem Beispiel die 1,96
-
Ich habe jetzt die 0.8.26 installiert. Per Default werden mir 10 Balken angeboten, das zeigt, das Update ist angekommen. Jetzt geht aber nichts mehr, der Balken ist immer dunkel.
-
@killroy2 said in Test Adapter SqueezeboxRPC v0.8.x Latest:
Ich habe jetzt die 0.8.26 installiert. Per Default werden mir 10 Balken angeboten, das zeigt, das Update ist angekommen. Jetzt geht aber nichts mehr, der Balken ist immer dunkel.
schau mal, ob in calctype was drin steht, ansonsten wähle dort segstep aus.
-
hat gefehlt, damit funktioniert es.
-
@killroy2 ok, sehr gut. habe gerade noch eine initialisierung ergänzt, damit der volumebar nahtlos auch bei den anderen funktioniert, die ihn schon verwendet haben
-
@OliverIO: Danke für Deine ausführliche Rückmeldung.
Wenn der Player nur kurz disconnected ist, dann ist der Reconnect innerhalb ca 10 Sekunden wieder da. Wenn der Adapter allerdings merkt, das der Player vom LMS offiziell als Disconnected geführt wird, dann werden alle Pollingabfragen gestoppt ...
Ja, so steht es auch in der Command Line Interface Dokumentation:
- A new client is notified using "client new". "client disconnect" is sent when a client disconnects. Unless it reconnects (as signaled by "client reconnect") before a number of minutes, the client will be automatically forgotten by the server (as indicated by command/notification "client forget".)
Die Logs meiner Vorgängeranwendung sagen, dass genau 5 Minuten nach einem "client disconnect" der LMS den Zustand "client forget" ausruft. In der Zwischenzeit ankommende Verbindungen werden als "client reconnect" behandelt. Nach diesem Zeitpunkt kommende Verbindungen gelten als "client new".
... und erst die Regelmäßige Serverabfrage, die alle 30 Sekunden läuft, reaktiviert den Client im Adapter wieder.
Die 30 Sekunden kannst du in den Instanzsettings unter Timer-Settings / Serverrefresh (sec) default: 30 anpassen.Diesen Parameter hatte ich heute Nachmittag schon auf 5 runter gedreht. Eine Verbesserung war für mich nicht erkennbar.
Auf meiner Todo-Liste habe ich noch eine Verbesserung stehen, die für bestimmte Ereignisse das Polling verbessert, in dem der LMS einen dann zeitnah aktiv informiert, wenn so etwas passiert.
D.h. der Adapter "sitzt seine Serverrefresh-Zeit vollständig ab" und fragt erst danach beim Server nach, ob es etwas Neues gibt. Er hat also in diesem Sinn keinen "Newsletter" des Servers abonniert. In meiner vorherigen Anwendung war dieser "Newsletter" über listen/subscribe Kommandos an den LMS bestellt, so dass die Anwendung zeitnah vom LMS bei z.B. neu ankommenden Verbindungen informiert wurde. Dies erklärt, warum sich beim Hochfahren des Clients in meiner neuen Anwendung die Wartezeit spürbar erhöht hat.
Aktiviere mal mittels dem History-Adapter auf dem Connected-Datenpunkt die Historie, dann siehst du genau, wann sich da etwas verändert und vergleiche den Zustand mit der Anzeige in der LMS-Gui im Dropdown oben rechts. [...] du siehst, ob der LMS den Client erkennt und mein Adapter nicht.
Guter Ansatz. Das werde ich in den nächsten Tagen mal angehen.
-
@hsteinme
ich schau mir zum einen die an ob es bei der server refresh zeit einen fehler gibt und dann bin gerade schon am schauen wie ich das mit telnet umgesetzt bekomme. das wird aber ein wenig dauern, da diese Woche schon ziemlich voll ist und ich ein wenig in Deutschland unterwegs bin. -
Danke! Aber bitte keine Hektik: Die Hochfahr-Thematik gehört nicht zur Kategorie "lebensbedrohlich und dringend".
-
@hsteinme
Muss dich leider entäuschen
Die ersten Tests sind gerade erfolgreich abgeschlossen worden.
Connect und Reconnect werden adhoc registriert.Aber dennoch noch nicht veröffentlichungsreif.
Da ich hier mit den Netzwerk-Sockets spiele muss ich erst ausführlich testen, das ich hier keine Speicherlecks rein bekommen.
Aber sieht generell gut aus. -
Dann werde ich die vereinbarten Vergleichsmessungen zur (Re)Connect-Erkennung erst mal sein lassen, da Du eh schon eine Lösung in der Hinterhand hast.
Wie gesagt:
die Reaktionsgeschwindigkeit und die Hilfsbereitschaft des Entwicklers im Forum haben mich sehr beeindruckt
-
@hsteinme
so in der Version 0.8.28 habe ich die Funktionalität eingebaut.
Das Server und die Playerobjekte werden nun aktualisiert, sobald signalisiert wird, das ein Player connected oder disconnected.
ggfs. musst du die Funktion erst in den Adapter Settings unter Reiter Performance aktivieren.Bei mir hat es Funktioniert, da das bei andern nicht unbedingt der Fall sein muss (man kann nicht alle Fälle vorausdenken).
Bitte aktiviere zusätzlich noch in den Settings Reiter Debug Settings die Einstellung "Create debug output for server" und stelle nach Speichern der Konfiguration in der Instanzübersicht in der Expertendarstellung den Log-Level der Instanz auf "debug".
Dort solltest du dann einmal sehen, ob sich der Adapter mittels Telnet mit dem LNS verbindet.
Im Log sieht das dann wie folgt aus:squeezeboxrpc.0 2020-01-09 00:21:34.576 debug (16011) doTelnet recieved reconnect for : 00:27:00:be:00:b7 squeezeboxrpc.0 2020-01-09 00:21:02.032 debug (16011) doTelnet recieved disconnect for : 00:27:00:be:00:b7 squeezeboxrpc.0 2020-01-09 00:20:13.265 debug (16011) doTelnet connected to server!Wenn Fehler auftauchen, dann bitte diese hier melden.
-
@OliverIO sagte in Test Adapter SqueezeboxRPC v0.8.x Latest:
so in der Version 0.8.28 habe ich die Funktionalität eingebaut.
Danke schön für die schnelle Bereitstellung, OliverIO!
ggfs. musst du die Funktion erst in den Adapter Settings unter Reiter Performance aktivieren.
"ggfs."? In welchem gegebenen Fall?
"in den Adapter Settings"? Meinst Du die Instanzen Settings? Im dortigen Reiter performance settings sehe ich jedoch nur zwei altbekannte Optionen zu den Playlist-Infos und zu den anderen LMS Servern. Mehr ist bei mir nicht zu finden.
*Bitte aktiviere zusätzlich noch in den Settings Reiter Debug Settings die Einstellung "Create debug output for server" und stelle nach Speichern der Konfiguration in der Instanzübersicht in der Expertendarstellung den Log-Level der Instanz auf "debug".
Das habe ich getan.
Dort solltest du dann einmal sehen, ob sich der Adapter mittels Telnet mit dem LNS verbindet.
Im Log sieht das dann wie folgt aus:Derartige Einträge sehe ich bei mir nicht, auch nicht nach einem stop/start von ioBroker.
-
@hsteinme
dann bitte auf der commandozeile folgenden befehl eingeben:iobroker upload squeezeboxrpc
-
@OliverIO Alternativ bzw als erstes kannst du auch noch <strg> + <f5> auf der Konfigurationsseite machen, falls im browsercache noch die alte seite gespeichert ist
-
@OliverIO sagte in Test Adapter SqueezeboxRPC v0.8.x Latest:
iobroker upload squeezeboxrpc
Das ist ja ein schönes Kommando
Danach waren nun drei Optionen unter den performance settings zu sehen. Ich habe dann die telnet-Methode aktiviert. Die gesuchten doTelnet Einträge waren danach auch im Log zu sehen.Heute scheint aber kein guter Tag zum Testen zu sein. Etwa nur in 10% der Einschaltvorgänge meiner Badezimmer-Squeezebox wurde eine Musikausgabe gestartet. Erste Blicke in mein Anwendungslog und in die History des Connected-Datenpunkts legen den Schluss nahe, dass der Connected-Datenpunkt in diesen Fällen nicht auf 1 gesetzt wurde. Da ich momentan unter Zeitdruck stehe, schiebe ich dieses Thema auf die nächsten Tage. Ich schaue dann etwas tiefer und genauer hin und melde mich hier wieder.
-
Das playlist widget steht schon seit längerem noch auf der Entwicklungsliste.
Hat jemand Lust mit mir zu besprechen, wobei man bei der Entwicklung der Playlist achten sollte, so dass es die folgenden Anforderungen erfüllt werden
(Liste kann ggfs. auch erweitert werden):Stufe 1: Nur Anzeige
- Bereitstellung folgender Informationen je Track auf einer Playlist: Titel, Album, Artist, RadioName, Duration, Bitrate, Type
- Konfigurierbares Ein/Ausblenden einzelner Informationen
- Anpassen der Reihenfolge zur Ausgabe der Informationen
- Jede Information wird in einem eigenen DIV ausgegeben mit einem adressierbaren class-name
- Standardlayout wird wegen vereinfachtem Einsatz mitgegeben, kann aber durch eigene CSS-Angaben angepasst werden.
Sufe 2: (Interaktion)
- Auswahl eines Titels welcher dann gespielt wird (problem, der vorhandene Playbutton kann hier wahrscheinlich nicht wiederverwendet werden, sondern muss explizit neu Programmiert werden, wenn er verwednet werden kann, kann dieser nicht über vis gestylt werden. Alternativ eine vereinfachte Version
- Umsortieren der vorgegebenen Playlist (Titel eine Position hoch/runter
Relativ kurzfristig könnte Level 1 fertig gestellt werden. Mich würde interessieren was man bei Konfiguration sonst noch so beachten müsste, dass ich hier nicht in eine falsche Richtung laufe.
-
@hsteinme sagte in Test Adapter SqueezeboxRPC v0.8.x Latest:
schiebe ich dieses Thema auf die nächsten Tage. Ich schaue dann etwas tiefer und genauer hin und melde mich hier wieder.
@OliverIO: Heute habe ich nun meine angekündigte Test-Vertiefung durchführen können - mit einem leider überraschenden Ergebnis.
Test-Nebenbedingungen:
- meine eigenen Squeezebox-Skripte = nicht aktiv
- Squeezebox = Squeezebox Duet
- Serverrefresh = 30
- Player refresh = 950
- Favorite refresh = 720
- Discovery refresh = 30
- Provide Playlistinfos in as JSON-datapoint = true
- Search for other LMS-Server = false
- Create debug output for Server = true
- andere Create * output for * = false
In der ersten Testreihe wurde die Option "Use Telnet for advanced signaling" auf false gesetzt. Die Ergebnisse:
--------------------------------------- Auszeit bis Conn.=1 Abbruch nach --------------------------------------- 10 30 10 95 10 60 10 65 10 85 --------------------------------------- 50 38 50 58 50 -- 150 50 43 50 40 ---------------------------------------Zur Erläuterung:
- Auszeit: Sekunden zwischen Aus- und Einschalten der Squeezebox
- bis Conn.=1: Sekunden vom Einschalten bis Connected-Status 1 wurde
- Abbruch nach: Sekunden vom Einschalten bis Abbruch der Messung, wenn Connected-Status nicht 1 wurde
- Ausschalten: Stromversorgung der Squeezebox ausschalten
- Einschalten: Stromversorgung der Squeezebox einschalten
In der (versuchten) zweiten Testreihe wurde die Option "Use Telnet for advanced signaling" auf true gesetzt. Die Wirksamkeit dieser Einstellung wurde im Log über die Existenz der doTelnet-Einträge überprüft.
Das Ergebnis: Nach dem Restart des Adapters stand Connected zunächst auf null. Beim ersten Einschalten der Squeezebox wechselte (nach der üblichen Wartezeit) der Connected-Status auf 1. Nachfolgendes Ausschalten sowie daraufhin erfolgte mehrmalige Aus-/Einschaltvorgänge änderten nichts am Connected-Status. Er blieb standhaft auf 1.
Dieses Verhalten entspricht auch meiner ersten Auf-die-Schnelle-Erfahrung vom Donnerstag: Beim ersten Einschalten startete meine Anwendung eine Musikausgabe, danach nie wieder. Nach dem Ausschalten der Telnet-Option startete meine Anwendung (fast) immer eine Musikausgabe. (Zum "fast" siehe auch oben den nach 150 Sekunden abgebrochenen Testlauf.)
Welche Informationen kann ich Dir noch liefern, um Dich bei der Diagnose dieses Verhaltens zu unterstützen?
Übrigens: Eine derartige Testreihe kann auch gut mit der SqueezePlay App auf einem PC durchgeführt werden (Einschalten = Starten der App, Ausschalten = Schließen der App), wobei natürlich die Wartezeiten auf Connect = 1 deutlich geringer sind, da die Hochfahrzeiten der Anwendung wesentlich kleiner als die Hochfahrzeiten einer "realen" Squeezebox sind.
-
@OliverIO sagte in Test Adapter SqueezeboxRPC v0.8.x Latest:
Hat jemand Lust mit mir zu besprechen, wobei man bei der Entwicklung der Playlist achten sollte, [...]
Stufe 1: Nur Anzeige- Anzahl der Playlist-Items
- Positonsnummer des aktuellen Items
-
@hsteinme
hab mir das verhalten vom LMS nochmal angeschaut und folgendes ist mir aufgefallen.
Man darf nicht nur den Status Connected anschauen, sondern auch Power.
Den verwaltet der LMS unabhängig voneinander, so dass
Ein Gerät aus sein kann (power=0), aber dennoch noch connected (connected=1)
Für den LMS kann erstaunlicherweise ein Gerät auch nicht connected (connected = 0) sein und dennoch an (power=1). Das habe ich im adapter aber korrigiert.Für dein Skript musst du nach dem Status Power schauen. folgende Zustände können nun vorkommen
power=0,connected=0; gerät nicht verfügbar
power=1,connected=0; kann nicht mehr in iobroker vorkommen, LMS kennt das aber noch
Power=0,connected=1; player ist mit LMS verbunden, aber Soft ausgeschaltet
Power=1,connected=1, player verbunden und eingeschaltetDa ich Power bei der Ereignissignalisierung noch nicht berücksichtigt hatte, habe ich das nun ergänzt, sowie die oben erwähnte Korrektur eingearbeitet.
Damit man sieht was sonst noch über die Ereignissteuerung läuft, werden alle eingehenden Daten nun im Debug-Level ausgegeben.
Dies steht nun in Version 0.8.29 zur Verfügung. -
@OliverIO: Heißen Dank für die wieder mal schnelle Diagnose und Lösungsbereitstellung.
Zwei Logs aus meiner früheren Anwendung:
Rec 22.12.2019 07:58:17 Data Received (47/47): xx:xx:xx:xx:ca:58 client disconnect Rec 22.12.2019 08:03:17 Data Received (43/43): xx:xx:xx:xx:ca:58 client forget Rec 22.12.2019 08:03:17 Data Received (43/83): xx:xx:xx:xx:ca:58 playlist stop Rec 22.12.2019 08:14:35 Data Received (40/40): xx:xx:xx:xx:ca:58 client newWurde einem Client der Strom entzogen, so reichte der Server nach kurzer Zeit ein Signal "client disconnect" hoch. Blieb der Client weiter stromlos, so kam nach 5 Minuten die Notification "client forget". Bei einer erneuten Stromzufuhr meldete dann der Server "client new".
Rec 22.12.2019 00:06:59 Data Received (47/47): xx:xx:xx:xx:ca:58 client disconnect Rec 22.12.2019 00:07:12 Data Received (46/46): xx:xx:xx:xx:ca:58 client reconnectErhielt ein stromlos gewordener Client innerhalb der 5-Minuten-Galgenfrist wieder Strom, so wurde seine Reanimation mit dem Status "client reconnect" kundgetan.
Meine frühere Anwendung reagierte also simpel auf die Signale "client new" und "client reconnect", auf sonst nix.
Man darf nicht nur den Status Connected anschauen, sondern auch Power.
Das Signal "power 1" konnte ich bisher ignorieren.
folgende Zustände können nun vorkommen
power=0,connected=0; gerät nicht verfügbar
power=1,connected=0; kann nicht mehr in iobroker vorkommen, LMS kennt das aber noch
Power=0,connected=1; player ist mit LMS verbunden, aber Soft ausgeschaltet
Power=1,connected=1, player verbunden und eingeschaltetJa, dem ist so. Das konnte ich ebenfalls verifizieren.
Für dein Skript musst du nach dem Status Power schauen.
Ja, auch dem ist nun so. Ich habe es nun in meinem Skript geändert (ein Hoch auf den Erfinder der Replace-all-Funktion in Editoren).
Damit man sieht was sonst noch über die Ereignissteuerung läuft, werden alle eingehenden Daten nun im Debug-Level ausgegeben.
Schön, dann kann ich ab sofort darauf verzichten, einen Telnet-Client mit "listen 1" mitlaufen zu lassen.
Dies steht nun in Version 0.8.29 zur Verfügung.
Danke schön! Runter geladen, installiert, Upload angestoßen (!), getestet: Siehe da, es läuft alles bestens
Daher konnte ich mir natürlich Zeitmessungen nicht verkneifen:--------------------------------------- Auszeit bis Power=1 Abbruch nach --------------------------------------- 10 35 10 50 10 14 10 31 10 38 10 38 10 37 10 51 ---------------------------------------Auch wenn diese geringe Zahl an Testläufen nicht repräsentativ sein kann, so wage ich doch ein erstes Fazit:
- Die zuvor aufgetretenen großen Ausreisser nach oben wurden nicht mehr beobachtet.
- Auch die Werte im mittleren Bereich haben sich im Allgemeinen verkürzt.
Von daher hat der Wechsel "vom Abfrage-Modus auf den Lausch-Modus" wohl die erhoffte Wirkung erzielt
Übrigens: Bei meinem heutigen Handling mit LMS/Adapter/Skript habe ich erneut zweimal die Situation gehabt, dass nach dem Einschalten des Clients keine Power/Connected-Änderung an mein Skript gemeldet wurde. Da ich gerade parallel einen Telnet-Client zwecks LMS-Beobachtung mitlaufen hatte, konnte ich jedoch die "Unschuld" des Adapters belegen: Der LMS selbst hatte die Status-Änderung nicht über die listen-Schiene signalisiert.
