Sonos Player disappeared

[Reinerlein]

Hallo sTaN,

wie mumpitzstuff geschrieben hat, sollte die hier hochgeladene Version zumindest in der Lage sein, sich selbst zu retten...
Das eigentliche Problem ist aber noch nicht entdeckt: Warum überhaupt reagiert der Sub Prozess nicht mehr?

Dein Prozess hängt beim Laden von TuneIn-Mediaressourcen fest. Ich habe dort mal eine Fehlermeldungsmöglichkeit eingebaut. Vielleicht passiert ja was...

Grüße
Reinerlein

[mumpitzstuff]

Wenn es keine Loops sind die irgendwie keinen Ausgang mehr finden, dann könnte ein read auf irgend eine Verbindung (socket) sowas auslösen, wenn hier kein timeout existiert und z.B. keine Daten mehr kommen. Dann hängt so ein read gern forever und wartet auf Daten die nie kommen. Verhindern kann man sowas mit:

Code Auswählen Erweitern

https://perldoc.perl.org/IO/Select.html

da man hier einen Timeout mitgeben kann. Schau doch vielleicht noch mal nach, ob du dahingehend noch etwas entdecken kannst (nur so eine Idee die ich grad hatte).

[sTaN]

Ich finde es vor allem interessant, dass ich das Problem erst jetzt wieder habe und bis vor zwei Monaten Ruhe war.
Irgendwie habe ich die Vermutung, dass hier andere Netzwerkgeräte dieses Verhalten auslösen. Ich werde mal versuchen usedonlyIPs zu arbeiten und nur die Sonos Player anzugeben.

Ansonsten versuche ich mal die neue Version der SONOS.pm aus.

Danke und Gruß
sTaN

[Reinerlein]

Hi,

@mumpitzstuff: Der Fhem-Teil läuft ja über die offiziellen Wege (man wird mittels ReadFn informiert, dass etwas vorliegt, und ich lese solange, bis ich alles aus dem Buffer habe).
Der Sub Prozess nutzt can_read- und can_write-Selektoren...

Bei sTaN hängt er irgendwie beim externen Laden der TuneIn-Mediainformationen. Das kommt auch aus dem Internet, und wird hier über einen UserAgent geladen... ich will erstmal sehen, ob und wenn ja mit welchem Fehler der da wieder rauskommt... u.U. muss ich da mal tiefer reinschauen...

Aber irgendwas ist es ja, da hast du schon Recht... ich habe da aber auch schon sehr oft drüber geschaut...

@sTaN: Das mit den IP-Einschränkungen brauchst du nur zu machen, wenn im Log eine entsprechende Fehlermeldung auftaucht (in der Art von

Loading device description failed with error: 500 Can't connect to 192.168.2.29:2869 (timeout) at ./FHEM/00_SONOS.pm line xx thread 1

Denn nur dann wird diese IP überhaupt als Player betrachtet, und in die interne Liste der Player übertragen (bzw. ein Fhem-Device angelegt)... ich habe hier im Haus solch ein Attribut nicht gesetzt, und auch die üblichen Kandidaten wie NAS, FritzBox, Windows-Server, AppleTV, FireTV u.ä.
Das ist nicht immer ein Problem...

Grüße
Reinerlein

[mumpitzstuff]

Kannst du mir ausgehend von der Version aus #345 eine Zeile nennen bitte, wo du in etwa die Vermutung hast das was passiert?

[Reinerlein]

Hi mumpitzstuff,

meinst du die Sache bei sTaN?
Da gibt es ein eval ab Zeile 4635. Dazu habe ich jetzt noch die Fehlerbehandlung gepackt... mal schauen...

Grüße
Reinerlein

[sTaN]

Kannst du mir ausgehend von der Version aus #345 eine Zeile nennen bitte, wo du in etwa die Vermutung hast das was passiert?

Bisher nicht aber aus dem Logfile in Beitrag #342.
Bzw. beruft sich meine Vermutung auf das fhem.log (siehe Anhang), was in Beitrag #342 fehlt. Mir ist eben erst aufgefallen, dass er nur einen Teil der Logs durch das Attribut SubProcessLogfileName in das sonoslog aus Beitrag #345 schreibt, aber ein Großteil noch im Hauptlogfile von fhem landet. Hier in Zeile 452 versucht er die Philips HUE Bridge zu kontaktieren. Nun weiß ich nicht, ob er generell das ganze Sunetz auf vorhandene UPnP Server absucht oder das vielleicht auch Probleme machen könnte?

Auf jeden Fall hat auch das Attribut usedonlyIPs keine Besserung gebracht und ich habe soeben die Module aus Beitrag #345 installiert.

Mal schauen, wie es sich damit verhält.
sTaN

[sTaN]

Könnte die Ursache auch nur an einem Sonos Player liegen? Mein Sonos in der Küche bleibt nämlich auch nach Installation der neuen Module auf disappeared. Im Logfile sehe ich bereits jetzt Meldungen wie:

Code Auswählen Erweitern


2020.06.26 14:08:56 5: SW: DoWork:undef:refreshProcessAnswer:
2020.06.26 14:08:56 5: SONOS0: Long time, no hear from SubProcess... sending ping-request

2020.06.26 14:06:56 5: SW: DoWork:undef:refreshProcessAnswer:
2020.06.26 14:06:56 5: SONOS0: Long time, no hear from SubProcess... sending ping-request

2020.06.26 14:04:56 5: SW: DoWork:undef:refreshProcessAnswer:
2020.06.26 14:04:56 5: SONOS0: Long time, no hear from SubProcess... sending ping-request

Habe den Sonos auch schon stromlos gemacht. Alle anderen sind online bzw. appeared.

[sTaN]

Hier mal neues Futter mit Logs der neuen Module. Auch mit den neuen Modulen gehen die Player nach kurzer Zeit auf disappeared.
Meine jetzige Vermutung ist der Sonos in der Küche. IP .221 am Ende. Der ist von Beginn an auf disappeared!

Macht eventuell eine Neuanlage des Sonos devices Sinn?

Danke und Gruß
sTaN

[sTaN]

@sTaN: Das mit den IP-Einschränkungen brauchst du nur zu machen, wenn im Log eine entsprechende Fehlermeldung auftaucht (in der Art von  Denn nur dann wird diese IP überhaupt als Player betrachtet, und in die interne Liste der Player übertragen (bzw. ein Fhem-Device angelegt)... ich habe hier im Haus solch ein Attribut nicht gesetzt, und auch die üblichen Kandidaten wie NAS, FritzBox, Windows-Server, AppleTV, FireTV u.ä.
Das ist nicht immer ein Problem...

Grüße
Reinerlein

Ja in der Tat hatte ich genau diese Meldungen. Ein mal von meinen Nanoleaf Canvas und LG TV.
Und genau da scheint aktuell auch das Problem zu sein, warum mein FHEM nach Neuanlage des Sonos devices klemmt.

Bekomme nämlich aktuell diese Meldung:

Code Auswählen Erweitern

Loading device description failed with error: 422 Unprocessable Entity (Location: http://192.168.188.203:16021) at ./FHEM/00_SONOS.pm line 2463 thread 1.

Und das sind meine Nanoleaf Canvas. Ich glaube vor meinem Routertausch war die 203 eines meiner Sonos Player.

Ich bin jetzt mal wie folgt vorgegangen und möchte kurz berichten:

• alte Sonos device gelöscht und anschließend ehem neugestartet.

[li]Sonos device neu angelegt mittels [/li][/list]

Code Auswählen Erweitern

define Sonos SONOS[/li]
[li]Status waiting subprocess erscheint und danach geht erst mal nichts mehr in FHEM. Webinterface lädt nicht mehr. Das dauert dann ca. 5 Minuten.[/li]
[li]Anschließend waren alle Sonos Player, auch der in der Küche online bzw. appeared. Alle Player sind nach ca. 3 Minuten auf disappeard und auch das Sonos device ist auf disable.[/li]
[li]Nachdem ich das device mit [/li][/list]

Code Auswählen Erweitern

defmod Sonos SONOS localhost:4711 120 1 5

modifizieren wollt, hängt FHEM wieder ca. 5-10 Minuten.[/li]

Ich habe die Vermutung, dass das reine Löschen des Sonos devices nicht ausreicht und ich auch alle Player zuvor löschen muss. Das werde ich mal versuchen.
sTaN

[87insane]

Generell empfiehlt sich, wenn dann immer ein "komplettes" löschen der Player... Wegen der Zonen usw. Musste ich mal wegen der Benamung komplett machen

[mumpitzstuff]

@Reinerlein:

Ich würde vielleicht Zugriffe dieser Art:

Code Auswählen Erweitern

my $ua = LWP::UserAgent->new(agent => $SONOS_USERAGENT);
my $response = $ua->request(POST 'http://legato.radiotime.com/Radio.asmx', 'content-type' => 'text/xml; charset="utf-8"',

mit einem Timeout versehen im Bereich von 5-10s oder so. Der default für das Timeout sind ansonsten 180s. Ich bin mir nicht sicher was dann alles schief laufen kann, wenn da etwas so lange hängen bleibt. Von solchen Aufrufen scheinst du jede Menge im Modul zu verwenden.

An anderen Stellen verwendest du auch:

Code Auswählen Erweitern

my $result = get('https://embed.spotify.com/oembed/?url='.$trackID);

Hier kannst du nicht mal einen Timeout vorgeben, sondern dieser ist fest bei 180s. Generell würde ich davon abraten an mehreren Stellen auf unterschiedliche Art und Weise URLs aufzurufen und Daten abzuholen. Vielleicht kannst du das über eine separate Funktion erledigen auf genau eine Art und Weise? Dann kannst du das Timeout auch zentral festlegen. Die Funktionen sind auch blockierend meines Erachtens, da sind 3min echt tödlich (internet offline und 10 url aufrufen nacheinander = 30min warten auf nix).
Vielleicht kannst du an der Stelle auch generell auf die FHEM Funktionen umstellen:

https://wiki.fhem.de/wiki/HttpUtils

HttpUtils_NonblockingGet ist wirklich eine schöne Sache, würde aber erhebliche Umstellungen in deinem Modul bedeuten. Aber auch  HttpUtils_BlockingGet würde es ja erst einmal tun. Der Standardwert für das Timeout liegt hier übrigens bei 4s...

PS: Du könntest auch mal versuchen dein Internet zu blockieren (Kabel ziehen) und gucken wie sich danach dein SONOS Modul im internen Netzwerk so verhält...

[Reinerlein]

Hi mumpitzstuff,

das mit dem Timeout habe ich auch schon in Überlegung. Aber Fhem ist nicht betroffen, da diese Zugriffe ausschließlich im SubProzess erfolgen...

Ich habe ja schon eine Prozedur gebaut (SONOS_ReadURL), da muss ich mal sehen, ob ich sie überall einsetzen kann...

Grüße
Reinerlein

[mumpitzstuff]

Ja aber wie gesagt. Wenn das Internet weg ist, dann braucht ein Zyklus deines Subprozesses ewig, weil es bei jedem Request minutenlang wartet. Ich würde auf jedenfall auf get() komplett verzichten und stattdessen die andere Methode verwenden und dort immer ein Timeout setzen von vielleicht 5s.

Außerdem habe ich noch 2x recv() gefunden. Auch hier gibt es kein Timeout. Wenn nix kommt dann wartest du hier forever. Hier steht was, wie du auch hier ein Timeout definieren kannst:

https://stackoverflow.com/questions/2876024/linux-is-there-a-read-or-recv-from-socket-with-timeout

Ich würde aber anstatt der socket option lieber select bzw. can_read verwenden.

[Reinerlein]

Hi mumpitzstuff,

die beiden recv sind meiner Meinung nach ok, das eine ist als Resultat einer can_read-Abfrage, und das andere direkt nach dem öffnen des Sockets. Das kann also nur schiefgehen, wenn dort nicht der SubProzess dran ist, sondern jemand anderes, der nicht reden will (was für einen Server-Prozess schon echt selten ist)...
Vielleicht baue ich da aber sowieso noch was um... das sieht noch nicht gut aus... mal schauen... das ist aber auch nicht der problematische Bereich...

Grüße
Reinerlein