Sonos Player disappeared

mumpitzstuff · 03 Juni 2020, 14:44:50

Hmm stimmt. Da wird in den Tiefen des Moduls syn als Default gesetzt. Muss ich weiter gucken.

87insane · 03 Juni 2020, 15:04:14

Sorry :-/

Gesendet von meinem LM-G810 mit Tapatalk

mumpitzstuff · 03 Juni 2020, 20:39:02

Habs mir angesehen und ich glaube das ausgerechnet der default Ping vom Typ syn falsch implementiert ist. Bevor ich da rum fummel schaut mal bitte ob ein anderer Ping Type Abhilfe für das Problem schafft. Ihr könnt ja mal mit udp oder tcp probieren...

87insane · 03 Juni 2020, 20:41:57

Hab mal auf TCP gestellt. Bin mir nicht sicher aber hatte ich glaube ich schon mal. Mal sehen was passiert.

juemuc · 03 Juni 2020, 21:15:04

Hallo zusammen,

bei mir steht der pingType schon immer auf tcp. Trotzdem habe ich hin und wieder den Fehler.

Viele Grüße
Jürgen

mumpitzstuff · 03 Juni 2020, 21:23:09

Gut aber hin und wieder ist was anderes als wenn es an der Stelle gar nicht geht. Ich würde gern wissen ob es bei syn gar nicht geht und bei tcp/udp zumindest ab und zu das Richtige passiert.
Dann würde ich erst einmal das syn Problem beheben und dann kann man weiter sehen.

PS: Der Max Retry Counter beim Alive Check steht übrigens auf 3. Das ist vielleicht ein bischen wenig und ich werde das dann auch gleich mal erhöhen, in der Hoffnung, dadurch den sporadischen Fehler reduzieren oder ganz beseitigen zu können. Ansonsten bräuchte ich ein Logfile Auszug zu dem Problem.

87insane · 03 Juni 2020, 21:39:45

Wenn meine schelle nicht geht oder die Waschmaschine sich nicht meldet bin ich nicht alleine tot

:-P Spaß, weiß wie du das meinst und bin am testen. Für den Test ist es dann aber auch für alle egal, denn das kann jeder mit der original Version.

Gesendet von meinem LM-G810 mit Tapatalk

det. · 03 Juni 2020, 22:09:11

ein Umstellen auf die anderen Möglichkeiten als syn und none mit anschließendem SONOS RescanNetwork bringt bei der aktuellen Version von hier leider keine Änderung. Alle ausgeschalteten Player noch appeared.
Oder wäre dazu ein Fhem Neustart nötig?

mumpitzstuff · 03 Juni 2020, 22:21:22

Stell doch bitte Verbose auf 5. Dann müsstest du sowas hier im Logfile sehen:

Code Auswählen

2020.05.31 11:21:32 5: SONOS3: PingType: udp
2020.05.31 11:21:32 4: SONOS3: <ip> is alive

Und wenn das Gerät nicht gefunden wird sowas hier:

Code Auswählen

"$host is NOT alive, but in merci level ".$SONOS_Thread_IsAlive_Counter{$host}.'/'.$SONOS_Thread_IsAlive_Counter_MaxMerci.'.'

Code Auswählen

"$host is REALLY NOT alive (out of merci maxlevel '".$SONOS_Thread_IsAlive_Counter_MaxMerci.'\'

Je nachdem was man vorher drin stehen hatte bei pingType, muss man eventuell ein shutdown restart machen, damit der IsAlive Thread los läuft.

87insane · 03 Juni 2020, 22:59:11

Wenn ich mal kurz fragen darf oder mal meine Meinung sagen darf...
Wer ein UDP Paket als Aussage für ein online/offline Gerät in diesem Umfeld nimmt, naja...
Ich denke von allen Paketen hier, ist dies in diesem Fall am ungünstigsten. Immerhin ist das hier kein Teamspeak, beidem es keinen interessiert ob das eigentliche Paket auch ankommt. Es muss quittiert werden. So denke ich zumindest und deswegen ist alles außer UDP auch nur zu testen. (Hört sich sehr hart an, ist aber nicht so gemeint, wäre eben schön wenn die 3,4 Dinge schnell getestet sind. Wir sind ja schon ein paar Tage dran...) Wir alle wollen ein Kaltgetränk und sagen - Läuft jetzt

Zitatdamit der IsAlive Thread los läuft

Guter Hinweis! Danke! Ich laufe weiter auf tcp....melde mich wenn ich was finde.

mumpitzstuff · 03 Juni 2020, 23:43:10

Haha ich hab da nur irgendwas anderes als syn eingetragen, mir darüber aber keine Gedanken gemacht. Udp ist halt leichtgewichtiger und da man es mehrmals probiert, relativiert sich das angesprochene Problem auch ein wenig. Aber ja, vermutlich ist es besser erst mal mit tcp zu testen.

mumpitzstuff · 04 Juni 2020, 22:21:42

https://github.com/mumpitzstuff/fhem-SONOS

Ich habe hier das angepasste SONOS Modul und die ControlPoint abgelegt. Den syn Ping habe ich hoffentlich gefixt. Disappeared Probleme sollte seltener oder hoffentlich gar nicht mehr auftauchen.

87insane · 04 Juni 2020, 22:41:32

Habe vorhin alles was pingtype angeht ausgemacht. Mein FHEM hing nur noch. Aber ich konnte leider nicht lokalisieren warum im Detail.
Kann leider erst am WE weiter testen bei dieser Geschichte hier aber spiele die neuen Daten schnellst möglich ein.
Hast du wünsche für den Test mit den Daten?

mumpitzstuff · 04 Juni 2020, 23:14:54

Gerät ausschalten und gucken ob es jetzt richtig als disappeared nach rund 5min erkannt wird und ob es dann nach dem Anschalten wieder funktioniert und angesprochen werden kann.

Ich konnte bisher zumindest prüfen, das der Server nach einem shutdown restart und einem disable 1/disable 0 ordnungsgemäß wieder hochzufahren scheint.

det. · 05 Juni 2020, 12:36:17

mit syn: "ob es dann nach dem Anschalten wieder funktioniert und angesprochen werden kann" -- Ja, funktioniert
"ob es jetzt richtig als disappeared nach rund 5min erkannt wird" -- Nein, bliebt auf appeared
mit tcp: hängt FHEM web einige 10s nach Abschalten eines Players und die Anzeige des abgespielten Titels bei laufendem Player kommt sehr verzögert, daher werde ich bei Syn bleiben
"ob es dann nach dem Anschalten wieder funktioniert und angesprochen werden kann" -- Ja, funktioniert
"ob es jetzt richtig als disappeared nach rund 5min erkannt wird" -- Ja, aber braucht bei mir deutlich über 5 min - eher 15min
noch ein LOG Auszug nach Neustart mit Einstellung tcp:

Code Auswählen

Unsubscription request failed with error: 500 Can't connect to 192.168.2.26:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.26:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.26:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.26:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.25:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.26:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.25:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.25:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
Unsubscription request failed with error: 500 Can't connect to 192.168.2.25:1400 (No route to host) at FHEM/lib/UPnP/ControlPoint.pm line 1163 thread 1.
2020.06.05 12:04:11 1: PERL WARNING: Redundant argument in sprintf at ./FHEM/21_SONOSPLAYER.pm line 432.
2020.06.05 12:01:52 1: SONOS4: Restore-Thread gestartet. Warte auf Arbeit...
2020.06.05 12:01:52 1: PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4790.
2020.06.05 12:01:52 1: SONOS3: IsAlive-Thread gestartet. Warte 120 Sekunden und pruefe dann alle 120 Sekunden...
2020.06.05 12:01:52 1: SONOS2: LongJobs-Thread gestartet. Prüfe auf LongJobs...
2020.06.05 12:01:51 1: SONOS1: UPnP-Thread gestartet.
2020.06.05 12:01:40 1: SONOS0: ./FHEM/00_SONOS.pm is listening to Port 4711
2020.06.05 12:01:40 1: SONOS0: ./FHEM/00_SONOS.pm is started by fhem...
2020.06.05 12:01:39 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 1 Sekunde(n) darauf...
2020.06.05 12:01:39 0: Server started with 537 defined entities (fhem.pl:22082/2020-05-31 perl:5.026001 os:linux user:fhem pid:16769)