Sonos Player disappeared

Begonnen von aherby, 22 Dezember 2015, 18:20:38

Vorheriges Thema - Nächstes Thema

mumpitzstuff

#180
So habe jetzt doch noch eine Version gebastelt...

Den Zeitraum zwischen stop und restart an der oben genannten Stelle habe ich auf 120 Sekunden erhöht. Es kann somit 2 Minuten dauern, bis Sonos nach einem disappear wieder funktioniert. Außerdem habe ich die Funktion SONOS_StartClientProcessIfNeccessary so umgestellt, das der Server zuerst gekillt wird, wenn er bereits vorhanden ist, und danach aber in jedem Fall neu gestartet wird.

In der Hilfe vom Modul steht was davon drin, das man den Server auch manuell starten könnte:

ZitatMan kann den Server unabhängig von FHEM selbst starten (um ihn dauerhaft und unabhängig von FHEM laufen zu lassen):

Ich kann aber nicht glauben, dass das wirklich jemals funktioniert hat. Wie auch immer, das geht mit der Änderung definitiv nicht mehr. Der selbst gestartete Prozess wird jetzt abgeschossen und intern neu gestartet.

Ich bin gespannt ob das irgendwas verbessert. Falls nicht, hätte ich noch 1-2 andere Ideen, die auch das externe Starten des Prozesses erlauben würden.

PS: Alle vorhergehenden Änderungen im SONOS Modul habe ich erst mal wieder entfernt.

Nobby1805

Zitat von: mumpitzstuff am 01 Juni 2020, 22:48:32
1.) Einer der Clients kann zeitwelig nicht erreicht werden. Dadurch wird 4x ein "SW: DoWork:undef:refreshProcessAnswer:" ausgelöst.
Das ist so nicht richtig, das refreshProcessAnswer wird immer alle INTERVAL (das ist ein Internal des Hauptmoduls) Sekunden ausgelöst. Es besteht hier auch kein (direkter) Zusammenhang zu den einzelnen Playern sondern soll die Kommunikation zwischen dem FHEM-Prozess und dem Sonos-Sub "überwachen"
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

mumpitzstuff

#182
Okay mag sein. Entscheidend hier ist, das an dieser Stelle bei Abwesenheit eines Players irgendwann was entscheidendes passiert, wie in den folgenden Punkten beschrieben.

Probiert bitte mal die angehängten Dateien und stellt das ausschalten eines Players nach bzw. guckt dann, ob alles wieder funktioniert, wenn man den Player wieder einschaltet. Vom Log brauche ich dann nur die 2-3 Minuten, nachdem ihr den Player wieder eingeschaltet habt. Bzw. ihr müsstet irgendwas wie unter Punkt 3 beschrieben sehen. Das und alles was danach dann passiert ist sehr interessant für mich.

Ich bin zuversichtlich hier etwas gefunden zu haben. :)

87insane

Hey zusammen,

ich habe die Datein nicht ausprobiert bisher da ich das nicht mehr so ganz nachvollziehen kann.

So wie ich es nachstellen kann, reicht ja die Abwesenheit nicht aus um das Problem zu erzeugen. Sondern der Abwesende Player muss wieder im Netz sein und dann stürzt alles ab. Ich hatte in meinem Test mehr als eine Stunde gewartet. Das schrieb ich (glaube ich) auch. Wenn ich das korrekt verstanden habe, würde mir also das neue Modul nichts bringen da ich ja schon mit sehr viel Zeit dazwischen testete.

Es scheint mir mal ganz einfach beschrieben einfach noch etwas offen zu sein und das blockiert dann alles. Nun wäre meine Frage an Dich als Spezi..
- Gibt eine Möglichkeit etwas wie dynamisches vergeben von Threads oder so möglich? Es wäre ja ok wenn ein alter Thread eine Weile braucht um zu sterben. Der Player, der nun neu ins Netz käme, würde somit direkt einen neuen Thread bekommen und nicht den alten, halb toten...

Otto123

Bei meinem Problem gestern ist kein Player weggegangen oder wieder gekommen. Da ist an der Sonso Umgebung manuell nichts passiert. Seit 2 Wochen ist ein Player offline, den FHEM noch kennt.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

mumpitzstuff

Das SONOS Modul braucht einen Server, der standardmässig auf Port 4711 läuft. Bei verschiedenen Problemen/Fehlern, läuft das Modul in eine Funktion, die diesen Server bei Existenz abschiesst, aber nicht wieder neu startet. Genau das ist bei 87insane passiert und vermutlich auch bei Otto. Und genau das (und nichts anderes) hoffe ich behoben zu haben.

Ihr vermischt hier allerdings 2 Dinge. Ich habe nicht behoben, das ein Player als offline erkannt und auch als offline angezeigt wird! Das macht das SONOS Modul momentan anscheinend einfach nicht. Erst wenn man versucht z.B.  auf das ausgeschaltete Gerät zuzugreifen läuft das Modul in die besagte Funktion und schießt sich ab. Es gibt aber aber sicher auch noch andere Dinge die dazu führen können, die mir aktuell unbekannt sind. Das ist aber momentan auch völlig egal, denn es geht darum, dass das Modul weiter läuft, nachdem diese Funktion getriggert wurde. Im originalen Modul kackt es immer ab, in meiner Version hoffentlich nicht mehr. Wenn das der Fall wäre, dann würde der Absturz an der Stelle abgefangen werden und jeder würde profitieren.

87insane

Schiebe die Daten mal rein und teste erneut...dauert aber da ich arbeiten bin.

Gesendet von meinem LM-G810 mit Tapatalk


det.

noch ein alter Sonos Nutzer...
Habe die 2 Dateien eben mal ausgetauscht. Der Connect am PC spielt zur vollsten Zufriedenheit. Da die Dinger bei mir alle bei Nichtnutzung komplett vom Strom gehen und durch Event beim Strom einschalten über ein MSwitch zeitgesteuert gestartet, gruppiert und zum Radio abspielen überredet werden, habe ich viele der hier so besprochenen Probleme nicht. D.h. ich nutze die ausschließlich zum Musikhören. (Durchsagen etc. nur über Alexa) 
Das die Dinger obwohl stromlos auf appeared stehen bleiben, ist schon immer so. Aber da die einen akustischen Rückkanal haben  ;D ist mir das egal.
Demzufolge kann ich nicht wirklich viel zum Testen beitragen. Wenn Ihr hier nichts von mir hört, geht mein Dank an mumpitzstuff für seine Mühe - nicht gemeckert ist Lob genug  8)
LG
det.

juemuc

Hallo zusammen,

ich finde es super, dass ihr versucht das ein oder andere Problem zu lösen. Soweit es mir möglich ist, helfe ich gerne beim Testen. Ein Umstieg auf sonos2mqqt wäre ein Neu-Anfang  :-[ für mich.

Das aktuelle update läuft auf meinem Testsystem aktuell ohne Probleme. Heute hatte ich ohne erkennbaren Grund folgende Meldung im Logfile:

2020.06.02 20:10:54 1: SONOS1: ZoneGroupTopology-Event: device 'Sonos_Wohnzimmer' is marked as disappeared. Restarting discovery-process!


Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

87insane

Zitat...sonos2mqqt wäre ein Neu-Anfang...
Das existiert in FHEM ja auch erst seit gefühlten zwei Sekunden ;)
Wir haben aber schon Gerätekontrolle und Templates.

An sich läuft das in meinen Augen genauso wie das Modul nur das man eben das Template auswählen muss. (Design natürlich noch in Aufbau).
Ich will hier keine Werbung machen, da ich ja sogar selber hier versuche das grade zu biegen. Wäre es eine Beziehung, würde ich quasi fremd gehen :-P
Spaß bei Seite... Mir ist es am Ende (auch wenn ich das Modul dann nicht mehr nutze, weil ich es gern einheitlich habe) nicht egal das dies hier nicht sauber läuft. Ich finde das die "Grundmodule" laufen sollten. Ich meine wir haben hier z.B. eine 21 vor dem Modul namen und keine 98. (Von den 98ern könnte in meinen Augen übrigends auch einige mal ein LevelUp erhalten).

mumpitzstuff

#190
Zitat von: juemuc am 02 Juni 2020, 21:46:11
Hallo zusammen,

ich finde es super, dass ihr versucht das ein oder andere Problem zu lösen. Soweit es mir möglich ist, helfe ich gerne beim Testen. Ein Umstieg auf sonos2mqqt wäre ein Neu-Anfang  :-[ für mich.

Das aktuelle update läuft auf meinem Testsystem aktuell ohne Probleme. Heute hatte ich ohne erkennbaren Grund folgende Meldung im Logfile:

2020.06.02 20:10:54 1: SONOS1: ZoneGroupTopology-Event: device 'Sonos_Wohnzimmer' is marked as disappeared. Restarting discovery-process!


Viele Grüße
Jürgen

Nach dieser Meldung wird in der Regel der ControlPoint neu gestartet, was mitunter zu Problemen führen kann, da die Ports noch vom alten ControlPoint belegt sind. Dieses Problem habe ich ebenfalls schon in einigen Userposts gesehen. Ich habe die ControlPoint.pm modifiziert, um dieses Problem möglichst zu beseitigen (siehe #180). Wenn du danach allerdings keine Meldungen im Logfile hattest, das irgendwelche Ports oder Adressen belegt waren, dann ist alles gut gegangen. Mögliche Fehlermeldungen im Logfile wären:

Error creating search socket
Error creating subscription socket
Error creating SSDP multicast listen socket

juemuc

Zitat von: mumpitzstuff am 02 Juni 2020, 22:13:45

Error creating search socket
Error creating subscription socket
Error creating SSDP multicast listen socket


Diese Meldungen hatte ich glücklicherweise noch nicht  :D
Allerdings habe ich grundsätzlich das Problem, das nach einem Update mit FHEM-Neustart der Port 4711 noch belegt ist.
2020.05.31 14:42:08 0: SONOS0: Can't bind Port 4711: Bind failed: Address already in use at ./FHEM/00_SONOS.pm line 9870. Nach 3 - 4 Versuchen ist der Port dann frei.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

mumpitzstuff

#192
Ich habe das Modul so überarbeitet, das der Fehler nach einem Restart nicht mehr kommen sollte. Falls Retries notwendig sein sollten, so wird das mit dem LogLevel 1 anstatt 0 ausgegeben, so das man die Ausgabe mit Verbose 0 ausblenden kann. In meinen Versuchen konnte ich aber keine Retries mehr sehen... (ControlPoint.pm ist unverändert).

Außerdem bin ich der Meinung den Grund dafür gefunden zu haben, weshalb ein abgeschalteter Player nicht auf disappear steht. Die Erklärung ist eigentlich ganz simpel. Man muss das Attribut pingType auf irgendwas anderes als auf "none" setzen. Ich konnte nachvollziehen, dass das Modul innerhalb der Funktion SONOS_IsAlive() folgendes macht:

my $pingType = $SONOS_Client_Data{pingType};
return 1 if (lc($pingType) eq 'none');


return 1 bedeutet alive. Setzt also irgendwas anderes als none und dann funktioniert der Alive Check hoffentlich.

PS: Um das Posten neuer Versionen zu vereinfachen, werde ich die nächste Version ins Github packen, das vereinfacht das Ganze ein wenig.

det.

Zitat von: mumpitzstuff am 03 Juni 2020, 01:22:22

Außerdem bin ich der Meinung den Grund dafür gefunden zu haben, weshalb ein abgeschalteter Player nicht auf disappear steht. Die Erklärung ist eigentlich ganz simpel. Man muss das Attribut pingType auf irgendwas anderes als auf "none" setzen. Ich konnte nachvollziehen, dass das Modul innerhalb der Funktion SONOS_IsAlive() folgendes macht:

my $pingType = $SONOS_Client_Data{pingType};
return 1 if (lc($pingType) eq 'none');


return 1 bedeutet alive. Setzt also irgendwas anderes als none und dann funktioniert der Alive Check hoffentlich.


pingType steht schon immer auf syn. Sorry, daran liegt es nicht. Rest funktioniert aber prima.
LG
det.

87insane

Sieht man auch im log bei mir das er einen Typ anzeigt.

Gesendet von meinem LM-G810 mit Tapatalk