Sonos steuern

[Ralli]

Danke. Ich hätte auch den Kontext lesen sollen  .

Hab's nun entsprechend Deinem Tipp auskommentiert. Nun ist Ruhe.

[dev0]

Wenn bei einer Sonos Gruppe, der Masterplayer in den transportState STOPPED oder PAUSED_PLAYBACK wechselt, dann belibt der transportState des Slaves weiterhin auf PLAYING stehen. Für das smartVISU Sonos Widget habe ich zwar einen Workaround in den fronthem Converter eingebaut, der das abfängt, aber ich bin gerade bei einem Workflow wieder darüber gestolpert...

@Reiner: Kannst Du das bitte fixen oder ist das bewußt so?

/Uli

[Reinerlein]

Hallo Uli,

das mit dem Transportstate wird so vom Player geliefert. Im Prinzip ist das ja auch korrekt so.

Ich wollte das jetzt ungern umschrauben, da das immer bedeutet, dass ich den Status beim Master abfrage, bzw. bei einer Statusänderung am Master alle Slaves mit aktualisieren müsste... das dauert CPU-Zeit, und nicht jeder braucht das.
Außerdem repräsentiert das Fhem-Device dann nicht mehr den Original-Zustand des Playerdevices. Das ist ja auch nicht wirklich gut.
Sowas muss immer in der Darstellungsschicht aufgearbeitet werden, da verschiedene Darstellungen ja auch verschiedene Anforderungen haben (könnten).

Fhem hat jetzt leider keine direkte Controller-Schicht, die diese internen Informationen dann an eine View-Schicht weiterreichen könnte... vielleicht könnte man da was mit dem Modul ReadingsProxy in Zusammenhang mit userReadings machen... das ist aber sehr individuell...

Grüße
Reiner

[dev0]

Hey Reiner,

das mit dem Transportstate wird so vom Player geliefert. Im Prinzip ist das ja auch korrekt so.

Dann habe ich das Prinzip oder die Logik wirklich nicht verstanden, aber wenn der Player das so liefert, dann finde ich es völlig ok das nicht zu ändern.
Ich habe die Player eh schon um (Start,Stop,Pause,...) Readings erweitert, die den Zustand mit 0 und 1 darstellen, wird über ein Notify getriggert. Hatte gestern nur nicht mehr daran gedacht wieso ich das eingebaut hatte

Eine ganz andere Frage habe ich aber noch: Es kommt regelmäßig vor, dass FHEM für 1-3s, seltener auch bis zu 10s, einfriert. Diese Freezes treten bei Statusänderunden der Player auf (Abspielen start, gruppieren, etc.). Hast Du noch vor, das auf non-blocking umzustellen (wenn es überhaupt möglich ist) oder macht es Sinn Sonos in eine eigene FHEM Instanz zu verbannen?

/Uli

[Reinerlein]

Hi Uli,

zu dem Transportstate: Naja, der zweite Player spielt die ganze Zeit das ab, was der erste Player liefert. Wenn der nichts liefert, kommt halt nichts raus, es wird aber trotzdem aktiv auf dem Stream gelauscht, und, wenn was kommt, das abgespielt.
Das ist vielleicht vergleichbar mit einem Webserver. Der läuft ja auch aktiv und wartet auf Browserverbindungen, die er bedienen kann. Nur weil es gerade keine Clients gibt, ist der Neue-Clients-Lausch-Prozess ja trotzdem aktiv....

Aber zum Freeze: eigentlich sollte kein solcher Freeze auftreten. Die gesamte Kommunikation mit den Playern läuft ja in dem eigenständigen Prozess ab.
Aber natürlich werden mal mehr oder weniger Daten vom SubProzess an Fhem übertragen. Irgendwann will man schließlich die Informationen mal sehen... Alles was Non-Blocking geht, ist damit also umgesetzt. Das Übertragen an Fhem selbst geht ja nunmal nicht Non-Blocking.

Diese Informationen werden sind bei einem Titelwechsel ja eine ganze Menge, oder bei einem Gruppierungswechsel oder Alarmaktualisierungen. Aber es sind auch nicht so viele, dass Fhem dabei nennenswert behindert werden sollte.
Aber prinzipiell hast du natürlich Recht: Ab einer bestimmten Menge an Aktualisierungen (sprich ab einer bestimmten Menge an Playern, die gerade aktiv genutzt werden) wird es z.B. mit einem Raspberry eng an der CPU-Front.
Ich habe z.B. das Problem, dass meine beiden Kinder je einen Player haben. Die hören auf eine andere Art und Weise Musik Bei mir läuft so eine Liste oder das Radio einfach durch, habe also alle paar Minuten mal einen Titelwechsel. Bei den Kindern wird ständig vor- und zurückgesprungen und kurz mal pausiert und wieder angestartet und so weiter... das ist dann die Hölle bei Fhem

Also auslagern nur dann, wenn es eine Leistungsfähigere Maschine ist. Aber auch dann müssen die Infos durchs Netz (z.B. über Fhem2Fhem) kommen. Oder das ganze Fhem zieht auf eine solche Maschine um...
Oder mal die ganzen Notifies, die man so für die Player hat, überprüfen. Vielleicht hat sich da auch eine ungünstige Verkettung ergeben...

Das ganze ist nicht so einfach zu entscheiden

Grüße
Reiner

[dev0]

Hi Reiner,
die Freezes scheinen tatsächlich von einer hohen CPU Auslastung auf einem Kern herzurühren. Die Hardware (4x 1.7GHz Cortex-A9, 2Gbyte LPDDR2, eMMC4 NAND, Ubuntu 14.04 Server) finde ich persönlich für den Einsatztweck aber gar nicht so unterdimensioniert. Ethernet ist allerdings bei dem Board nur über USB2.0 angebunden. Interessanterweise lassen sich die Freezes nicht immer reproduzieren, auch wenn ich alle zusätzlichen Notifies deaktiviere. Teilweise kann ich 3 Strereopärchen gruppieren ohne eine nennenswerte Verzögerung, dann mal wieder 1-3s Stillstand... Ohne Aktionen von Sonos liegt die CPU Auslastung max. um 8-9% und der Systemload ist mit unter 0.1 auch ok.
Ich denke, dass eine 2. Instanz auf der selben Maschine etwas bringen könnte um die Hauptinstanz zu entlasten. Mal sehen, wenn ich etwas Luft habe werde ich es mal testen. Ich hätte zwar noch einen unausgelasteten und potenten XEON Server hier, aber das wäre mit Kanon auf Spatzen für ein FHEM, finde ich.
Lese ich das zwischen den Zeilen richtig, dass bei Dir diese Verzögerungen auch auftreten, wenn Deine Kinder zappen?

/Uli

[Reinerlein]

Hi Uli,

wenn meine Kinder zappen, habe ich bislang keine Freezes, sondern die Informationen brauchen ein wenig, um in Fhem anzukommen, und die CPU-Last schlägt oben an. Ich habe das aber auch nur auf einem Pi laufen.
Deine Hardware erscheint mir aber mehr als ausreichend für diese Aufgabe

Was du vielleicht auch versuchen kannst, ist den SubProzess einer anderen CPU zuordnen (sofern das so einfach geht).
Des Weiteren kannst du den SubProzess selber auf einer anderen Maschine starten, und in Fhem dann die entsprechenden Verbindungsdaten (Host und Port) am Sonos-Device bei der Definition mitteilen. Dann startet Fhem keinen eigenen SubProzess, sondern verwendet den von dir gestarteten (der überlebt dann auch einen Fhem-Neustart, da nur die Verbindung dorthin neu gemacht wird, das bedeutet, dass du nach einem Sonos-Modul Update diesen SubProzess selber neustarten musst).

Mir sieht das eher nach einer Zusammenwirkung von mehreren Themen aus. Das ist immer schwierig zu finden, und meistens überhaupt nicht zu lösen.
Eine solche Fehlersuche fängt ja, wie von dir ja schon gemacht, immer mit dem Nachstellen und Reproduzieren an. Wenn man da schon nicht so richtig vorankommt, ist es auch schwierig eine Verbesserung festzustellen.

Tut mir leid, wenn ich dir da keine besseren Tips geben kann...

Grüße
Reiner

[dev0]

Was du vielleicht auch versuchen kannst, ist den SubProzess einer anderen CPU zuordnen (sofern das so einfach geht).

Das geht, aber der Scheduler unter Linux kann die CPU Affinity Mask in der Regel besser verwalten, wenn man nicht eingreift. Aber die Idee den Subprozess auszulagern finde ich interessant. Wie starte ich den Subprozess auf dem anderen Rechner? Erschließt sich mir gerade leider nicht.

Vielen Dank schon mal für Deine freundliche Unterstützung!

/Uli

[Reinerlein]

Hallo Uli,

das hänge ich auch nicht an die große Glocke, da der Supportaufwand da u.U. groß sein kann
Es steht ein kleiner Hinweis in der Commandref.

Mit

Code Auswählen Erweitern


perl 00_SONOS.pm <ServerPort> <Verboselevel>
kannst du den eigenständigen Prozess starten. Dieser lauscht auf dem angegebenen Port, und hat den angegebenen Verboselevel für die Logausgabe (auf der Konsole).

In Fhem musst du beim Define des Sonos-Devices dann den Namen oder die IP des Rechners, auf dem der Prozess läuft, angeben, und die beim Start vergebene Portnummer.
Der SubProzess muss bereits laufen, wenn Fhem versucht darauf zuzugreifen!

Grüße
Reiner

[Loredo]

Wenn bei einer Sonos Gruppe, der Masterplayer in den transportState STOPPED oder PAUSED_PLAYBACK wechselt, dann belibt der transportState des Slaves weiterhin auf PLAYING stehen. Für das smartVISU Sonos Widget habe ich zwar einen Workaround in den fronthem Converter eingebaut, der das abfängt, aber ich bin gerade bei einem Workflow wieder darüber gestolpert...

@Reiner: Kannst Du das bitte fixen oder ist das bewußt so?

/Uli

Mir hat da geholfen ein eigenes Reading für state zu definieren (habe es state2 genannt) und über stateFormat auch als STATE zu verwenden.
Habe ich hier mal gepostet gehabt.

[dev0]

Danke Reiner,

funktioniert auf Anhieb. Allerdings bleibt das Problem bestehen. Die CPU Last geht weiterhin kurzfristig auf 100%, wenn ich Player gruppiere.
Wenn ich das über die command line ausführe, dann sind die Freezes auch reproduzier bar:

Code Auswählen Erweitern

group
2015.11.03 11:20:49.394 1: Perfmon: possible freeze starting at 11:20:45, delay is 4.394
2015.11.03 11:20:51.728 1: Perfmon: possible freeze starting at 11:20:50, delay is 1.728
2015.11.03 11:20:53.150 1: Perfmon: possible freeze starting at 11:20:52, delay is 1.15

ungroup
2015.11.03 11:21:21.705 1: Perfmon: possible freeze starting at 11:21:19, delay is 2.705
2015.11.03 11:21:23.033 1: Perfmon: possible freeze starting at 11:21:22, delay is 1.033

track wechsel
2015.11.03 11:24:50.801 1: Perfmon: possible freeze starting at 11:24:50, delay is 1.05

Auffällig finde ich, dass beim Gruppieren 3 und beim Aufheben der Gruppen 2 Freezes nacheinander auftreten...

Aber wenn ich wirklich der Einzige bin, bei dem das auftritt oder dem das schon mal störend aufgefallen ist, dann mach Dir keine weiteren Gedanken darum, Reiner. Dann muss ich das halt wirklich mit FHEM2FHEM und RFHEM auslagern. Schade, dass es noch kein Tool/Modul gibt, mit dem das bidirektional out of the box "mal eben" funktioniert.

@Loredo: Danke für den Tipp, ich hatte das ähnlich gelöst

/Uli

[SVLoneStar]

Hallo Reiner,
folgendes Problem: Nach einem Neustart meines CubieTruck erhalte ich (gefühlt) 5000 Einträge folgender Meldung im Log :

Code Auswählen Erweitern

Loading device description failed with error: 200 OK at ./FHEM/00_SONOS.pm line 3591 thread 1.

Es sind zwei Sonos:Play1 im Einsatz, bei beiden und auch beim Sonos-Device steht der LogLevel auf 1.

Was ist zu tun? Benötigst Du weitere Informationen?

Besten Dank,
Stefan

Edit: Post gekürzt, sorry.

[Elektrolurch]

Sorry, aber das bring nun rein gar nichts:
Loading device description failed with error: 200 OK at ./FHEM/00_SONOS.pm line 3591 thread 1.

davon 5000 Zeilen hier zu veröffentlichen. Dadurch wird der eh schon lange tret (Beitrag) nur noch länger und es dauert entsprechend lange, bis die Antwort auf den Server  hochgeladen wurde und
ich benutze einen  Screenreader und die vielen völlig  aussagelosen, unnützen Zeilenwiederholungen sind für mich eine Barriere.
Also bitte mit Verstand Infos einstellen. Danke.

Elektrolurch

[SVLoneStar]

Sorry, aber das bring nun rein gar nichts:
Loading device description failed with error: 200 OK at ./FHEM/00_SONOS.pm line 3591 thread 1.

davon 5000 Zeilen hier zu veröffentlichen. Dadurch wird der eh schon lange tret (Beitrag) nur noch länger und es dauert entsprechend lange, bis die Antwort auf den Server  hochgeladen wurde und
ich benutze einen  Screenreader und die vielen völlig  aussagelosen, unnützen Zeilenwiederholungen sind für mich eine Barriere.
Also bitte mit Verstand Infos einstellen. Danke.

Elektrolurch

Hallo Elektrolurch,
entschuldigung - verstanden und geändert.

Gruß,
Stefan

[Spuckiii]

Hab da mal eine kurze Frage. Die SuFu hat mir leider nichts ausgespuckt. Ist es möglich z.b. im Schlafzimmer und im Kinderzimmer je 1 Sonos Box aufzustellen und so einzustellen dass z.b. das Tablett im Kinderzimmer nur auf seine SonosBox drauf zu greifen kann und nicht auch auf die im Schlafzimmer? ggfs. auch nur auf 1 dem Player zugewiesene Abspielliste?