Sonos Player disappeared

[87insane]

Da wir alle die Ursache nicht kennen, könnte ich auch nur raten warum das so gut geht.

Glaskugel: es sieht für mich so aus, als ob etwas voll läuft. Nach disable 1, 0 geht es direkt wieder weil vermutlich an der Stelle auch noch mehr passiert.. Sowas wie Belege Cache oder so. Habe bisher aber nicht in den Quelltext gesehen. Denke da kann man ggf. Die Ursache oder vllt die Lösung finden

Gesendet von meinem LM-G810 mit Tapatalk

[hoppel118]

Daran kann es nicht liegen. Das ,,(attr Sonos disable 1)(deleteattr Sonos disable)" macht mein DOIF auch.

Gruß Hoppel

[87insane]

Ja aber eben anders. Zu oft neu starten hat bei mir immer alle Geräte mit gerissen. Ab und an sind aber nur einzelne auf disapper, das Modul macht seinen Durchgang und alles ist auf einmal down. Deswegen empfehle ich diese Variante. Jeder von euch kann lesen das da kein zauberspruch steht.

Hab das doif übrigends in einem anderen Thread mit gleichem Inhalt bekommen von einem anderen User hier. Nur um den Eigenlob mal nicht zu sehr in den Vordergrund zu stellen. Hab viel getestet und wie gesagt, ist das ohne Zusatz bei mir am besten. So zuverlässig das die Klingel drüber läuft. Aber das ganze Gerede über das Thema hat mich auf eine Idee gebracht.
Also ich bin kein Programmierer aber eine Ahnung wo ggf was stecken könnte. Schaue mir das morgen mal an.... Vllt kann dann jemand mit tieferer Ahnung die Vermutung entschlüsseln/verbessern. Bevor ich einen Code nur noch schlimmer mache.

Gesendet von meinem LM-G810 mit Tapatalk

[87insane]

Hallo zusammen... Ich habe mal ein wenig in das Modul gesehen. Eigentlich sollte nachdem ein Gerät disappeared ein Prozess weiterhin danach suchen..

Code Auswählen Erweitern

7116         # Prüfen, ob der Player auf 'disappeared' steht, und in diesem Fall den DiscoverProcess neu anstarten...
7117         if (SONOS_Client_Data_Retreive($udn, 'reading', 'presence', 'disappeared') eq 'disappeared') {
7118                 SONOS_Log $udn, 1, "Transport-Event: device '$name' is marked as disappeared. Restarting discovery-process!";
7119                
7120                 SONOS_RestartControlPoint();
7121         }
7122        
7123         return 0;

Es sollte dann eigentlich am Ende das hier getan werden:

Code Auswählen Erweitern

5400 sub SONOS_RestartControlPoint() {
5401         if (defined($SONOS_Controlpoint)) {
5402                 $SONOS_RestartControlPoint = 1;
5403                
5404                 $SONOS_Controlpoint->stopSearch($SONOS_Search);
5405                 $SONOS_Controlpoint->stopHandling();
5406                
5407                 SONOS_Log undef, 4, 'ControlPoint is successfully stopped for restarting!';
5408         }
5409 }

Zudem gibt es mehrfach im Code folgendes:

Code Auswählen Erweitern

448         my $presence = ReadingsVal($device, 'presence', 'disappeared');
449         $presence = 'disappeared' if ($presence =~ m/~~NotLoadedMarker~~/i);


So verstehe ich das:
Wenn ein Player offline geht, starte die SUB und such weiter.
Der Sub Prozess scheint also aus einem mir nicht ersichtlichem Grund nicht sauber zu laufen. Aber ich finde auch das der Prozess aussieht als fehlt nach dem anhalten der erneute Start.
Ich sehe nur Dinge in Form von wenn = disappeared dann Ende. Finde nichts wo dann auch wieder was starten sollte....

Hier würde ich einen der Modulentwickler, Programmierer oder sehr gerne auch irgend wen, der helfen kann, an Board haben
Es gibt viele hier die das sicherlich verstehen und helfen könnten. Ich frage mal ganz lieb hier @Beta-User, @KölnSolar, @KernSani, @CoolTux, @Otto123, @Prof. Dr. Peter Henning, @rudolfkoenig?
Ich will keinen mit der Verlinkung nerven aber das SONOS Modul ist ein Teil von FHEM und ich bin mir bei allen Aufgezählten Personen sicher, dies locker lösen zu können. Ich biete mich an zum testen oder aber mit ggf. Hinweisen, weitere Analyse

Danke und Gruß

[KernSani]

Es ehrt mich ja, dass du mir das zutraust... allerdings bezweifle ich, dass ich so auf die Schnelle mal ein mir unbekanntes Modul fixe (und ich nehme an den übrigen genannten geht es ähnlich). Was ist denn mit Reinerlein, als Maintainer des Moduls?   

[Otto123]

da ich das Modul Sonos nur für rudimentäre Funktionen nutze - überlege ich die ganze Zeit ob ich nicht auf sonos2mqtt umsteige.

Ich kann beim fix vom Modul  wirklich nicht helfen, das überfordert mich, glaube ich

[87insane]

Hey und danke schonmal für Euer Feedback!

@KernSani: Ich erwarte das nicht mal eben und würde die Arbeit auch übernehmen wenn mich einer, sagen wir mal "rein holt", das zu verstehen. An sich liest sich der Quelltext gut. Ich verstehe sicher nicht alles aber das was ich verstehe ergibt für mich Sinn.

@Otto123: Auch eine gute Idee. Allerdings finde ich es schade wenn ein Modul, welches in FHEM implementiert ist, wenn man so will.. Einfach "stirbt".

@Reinerlein: Was sagst du dazu? Das Thema kommt ja immer wieder hoch..... (nicht als böses Kommentar zu verstehen).

Wenn jeder ein paar Prozent gibt, haben wir am Ende 100 und keiner hat sich dabei zu sehr angestrengt

[mumpitzstuff]

Ich habe mal in den Code kurz rein gesehen...

1.) Die Funktion RestartControlPoint() wird an mehreren Stellen bei Fehlern aufgerufen, was so eigentlich in Ordnung ist.

2.) Innerhalb der Funktion RestartControlPoint() wird die Variable $SONOS_RestartControlPoint = 1; gesetzt. Diese bewirkt innerhalb der Funktion SONOS_Discover() das der ControlPoint restartet wird.

Code Auswählen Erweitern


do {
$SONOS_RestartControlPoint = 0;

eval {
$SONOS_Controlpoint = UPnP::ControlPoint->new(SearchPort => 0, SubscriptionPort => 0, SubscriptionURL => '/fhemmodule', MaxWait => 30, LogLevel => $SONOS_Client_LogLevel, UsedOnlyIP => \@usedonlyIPs, IgnoreIP => \@ignoredIPs, ReusePort => $reusePort);
$SONOS_Search = $SONOS_Controlpoint->searchByType('urn:schemas-upnp-org:device:ZonePlayer:1', \&SONOS_Discover_Callback);

#$SONOS_Controlpoint->handle;
my @mysockets = $SONOS_Controlpoint->sockets();
my $select = IO::Select->new(@mysockets);

while (!$SONOS_RestartControlPoint) {
# UPnP-Sockets abfragen...
if (my @sockets = $select->can_read(0.01)) {
for my $sock (@sockets) {
$SONOS_Controlpoint->handleOnce($sock);
}
}

# Befehlsqueue abfragen...
while ($SONOS_Client_ReceiveQueue->pending()) {
SONOS_Discover_DoQueue($SONOS_Client_ReceiveQueue->dequeue());
}
}
};
$error = $@;

# Nur wenn es der Fehler mit der XML-Struktur ist, dann den UPnP-Handler nochmal anstarten... 
if (($error =~ m/multiple roots, wrong element '.*?'/si) || ($error =~ m/junk '.*?' after XML element/si) || ($error =~ m/mismatched tag '.*?'/si) || ($error =~ m/no element found/si) || ($error =~ m/500 Can't connect to/si) || ($error =~ m/not properly closed tag '.*?'/si) || ($error =~ m/Bad arg length for Socket::unpack_sockaddr_in/si)) {
SONOS_Log undef, 2, "Error during UPnP-Handling, restarting handling: $error";
SONOS_StopControlPoint();
} else {
SONOS_Log undef, 2, "Error during UPnP-Handling: $error";
SONOS_StopControlPoint();

undef($error);
}
} while ($error || $SONOS_RestartControlPoint);


Da $SONOS_RestartControlPoint auf 0 gesetzt wird innerhalb der Schleife, kann die Schleife durch diese Variable nicht weiter laufen. Damit hängt das Verlassen oder nicht Verlassen der Schleife von $error ab. Wenn also beim erneuten Aufbau des ControlPoints ein Fehler auftritt (z.B. weil der Port belegt ist), dann wird undef($error) ausgeführt, die Schleife wird verlassen und Ende Gelände.

Ich könnte anbieten da mal was rein zu patchen, so das mehrfach versucht wird den Controlpoint wieder aufzubauen (10x oder so). Ich kann allerdings nicht sagen ob das irgendwas bringen wird. Ich vermute vielmehr, das der Abbau des ControlPoints fehlerhaft ist und der Port nicht freigegeben wird (in einem der Beiträge stand sowas drin).

3.) Diese Dinge sind unwichtig, da dieser maximal der Anzeige dienen, aber keine Auswirkungen auf die Funktionsweise des Moduls haben, soweit ich das erkennen konnte.

[Otto123]

3.) versteh ich nicht?

Zu sonos2mqtt:
hab ich gestern mal probiert: geht gefühlt flott und zügig (mein Pib hatte seinerzeit eine Vervielfachung der Last nach Inbetriebnahme des Sonos Moduls und der Restart des Sonos Moduls braucht ja etwas)
Ich habe mit getrennten Instanzen getestet 1. sonos2mqtt 2. FHEM mit MQTT2_Server, das hat vielleicht auch generell etwas

Aber! Ich bin weit davon entfernt zu sagen, das ist mal eben so einzurichten die define Sonos Sonos !!!
Da muss ich jetzt irgendwie bridgeRegexp bauen damit mehrere Devices entstehen, die publish Codes müssen eingepflegt werden. Sicher was schönes für attrTemplate
Die Anbindung der Sprachengine ist mir auch noch unklar.

Irgendwer hatte hier mal gepostet er hat da schon Erfahrungen, das würde mich interessieren. Ich habe mich erstmal ganz schön prasslig angestellt.

Generell gefällt mir die Richtung -> mqtt. Ich versuche bei Alternativen immer mqtt zu wählen.

Gruß Otto

[mumpitzstuff]

Die Zeilen wo $presence auf disappeared gesetzt wird wenn ein Marker gefunden wird, sorgt lediglich dafür, das irgendwo ein Reading/Text erscheint, wo das drin steht. Ich kann aber keine weitere Logik erkennen, die aufgrund dieser lokalen Varisble irgendwas machen würde.

[Otto123]

Wenn der Player disappeared steht, lässt er sich doch nicht mehr steuern!?

[87insane]

Korrekt. Er ist dann wie weg. Aber wenn du als Beispiel einen von drei einfach mal stromlos machst gehen alle anderen (nicht gruppiert) auch schnell auf disapper. Ich habe alles mögliche probiert.

Sonos2mqtt hört sich schön an und wenn Zeit dann fange ich mal an. Finde aber das eigentliche Problem im aktuellen hauptmodul wichtiger.

Wenn du die Frage der sprachsteuerung auf das normale Modul beziehst, kann ich gern helfen. Mache schelle, trockner usw darüber.

@mumpitzstuff danke für deine Analyse. Richtig gut das du dir das angesehen hast. Aus deinem Text entnehme ich das du was probieren könntest aber dir relativ sicher bist das es nicht dieses Problem an sich löst, sondern runder laufen könnte...?

Gesendet von meinem LM-G810 mit Tapatalk

[Otto123]

Wenn du die Frage der sprachsteuerung auf das normale Modul beziehst, kann ich gern helfen. Mache schelle, trockner usw darüber.

Ne ne - ich meine sonos2mqtt Mein normales Modul läuft, ohne Probleme. So einmal die Woche schlägt mein DOIF an (disable/enable) ohne jede spürbare Beeinträchtigung.

[87insane]

Aber an sich stecke ich ein wenig mit drin bei Sprache....
Beta-User ist wegen den Templates ja eh mit an Board. Ggf. kann man da was abgucken.

Bei mir "stürzt" es auch nicht so oft ab wie bei vielen anderen anscheinend. Allerdings ist das Problem an sich ja da.

Wie gehen wir am besten weiter vor?

[mumpitzstuff]

Ich kann versuchen was zu machen, müsste dann aber blind was tun, weil ich kein SONOS System habe und deshalb eigentlich nix probieren kann. Ich bräuchte dann jemanden der das testet.

Auf was steht denn bei euch das Attribut reusePort? Wenn das nicht gesetzt ist oder auf 0 steht, dann setzt das mal auf 1. Vielleicht behebt das das Problem bereits. Ansonsten bräuchte ich ein wenig mehr Infos darüber, was im Logfile auftaucht, wenn ihr diesen Fehler habt.

Je mehr ich mir die ControlPoint ansehe, desto mehr bin ich der Meinung, das die Probleme eher daher kommen anstatt aus dem SONOS Modul. Soweit ich sehen kann, wird dort gar kein close irgendwo aufgerufen, um die Sockets auch wieder freizugeben. Das führt dann natürlich zu Problemen, wenn man versucht die erneut aufzumachen. Außerdem werden die reuse Parameter für bestimmte Verbindungen gesetzt und mal wieder nicht. Alles sehr komisch in dem Modul.

Ich habe mal auf die Schnelle was gehackt und in der ControlPoint.pm die meines Erachtens richtigen reuse parameter gesetzt (reusePort hab ich mal fest auf 1 gesetzt um an der Stelle nichts anbrennen zu lassen). Außerdem habe ich im SONOS Modul in der oben angesprochenen Funktion einen retry counter von 20 eingebaut und mache jetzt explizit ein close auf den Sockets der ControlPoint. Ich hoffe ich habe nichts verpfuscht und vielleicht verbessert sich sogar irgendwas.