Sonos Player disappeared

[TomLee]

Keine Ahnung da bin ich zu sehr Laie, einfach mal deaktivieren/disablen und ausprobieren.

[hoppel118]

Commanref und Wiki sind hier tatsächlich identisch.

Mein Fazit: Das folgende DOIF beinhaltet nur einen DO-Block. Die einzelnen Befehle der Befehlskette, sind jeweils in Klammern gesetzt und somit ist beim wait das Komma zu verwenden. Zumindest lese ich das aus dem von mir zuvor zitierten Abschnitt.

Siehst du das anders?

Ich habe es nun nochmal wie folgt getestet:

Code Auswählen Erweitern

define di_Sonos_Reload DOIF ([Sonos] eq "disabled")
  (attr Sonos disable 1)(deleteattr Sonos disable)(set Hoppels_WhatsApp send Sonos Zentrale: automatically enabled by DOIF)
attr di_Sonos_Reload checkReadingEvent 1
attr di_Sonos_Reload do always
attr di_Sonos_Reload wait 0,60,60

Code Auswählen Erweitern

attr Sonos event-on-change-reading state

Vorhin gegen 20 Uhr ist das Problem erneut aufgetreten. Das DOIF hat nicht gegriffen.

Woran kann das liegen, dass das DOIF nicht getriggert wird?

Es bleibt zu klären, warum dieses DOIF nicht getriggert wird. Wie kann man das analysieren?

Viele Grüße Hoppel

[sTaN]

[mention]hoppel118 [/mention] Ich teste dein DOIF mal sobald der Fehler erneut auftritt. Habe soeben erst den LG TV ausgeschlossen und will nicht zu viele Stellschrauben verändern.

[hoppel118]

Das ist mal interessant. Habe zwar nicht das LG Modul im Einsatz aber habe einen LG65 Zoll TV. Meinst du der UPnP Server könnte das Problem sein? Allerdings hatte ich extra die IP des TV mit im Attribut ignoredIPs gesetzt. Sodass er eigentlich schon nicht mehr reinfunken dürfte

EDIT: Wollte ihn setzen, habe es bisher aber wohl vergessen. [emoji85] Habe den LG TV jetzt mal auf ignorieren gesetzt.

Ich habe bei mir unter ,,usedonlyIPs" alle IPs meiner Sonos-Player hinterlegt. Somit ist meinem Verständnis nach alles andere ausgeschlossen und kann mit UPnP nicht mehr ,,reinfunken". Leider ist das nicht die Lösung.

[sTaN]

Ich habe bei mir unter ,,usedonlyIPs" alle IPs meiner Sonos-Player hinterlegt. Somit ist meinem Verständnis nach alles andere ausgeschlossen und kann mit UPnP nicht mehr ,,reinfunken". Leider ist das nicht die Lösung.

Schade...Das Attribut habe ich auch eben entdeckt und wollte ich statt ignoredIPs verwenden. [emoji17]

[hoppel118]

[mention]hoppel118 [/mention] Ich teste dein DOIF mal sobald der Fehler erneut auftritt. Habe soeben erst den LG TV ausgeschlossen und will nicht zu viele Stellschrauben verändern.

Super, freu mich auf dein Ergebnis.

Ich hatte jetzt übrigens fast einen Monat Ruhe. In der letzten Woche ist es dann aber gleich zwei mal wieder aufgetreten. Keine Ahnung, was das auslöst. Beim letzten Mal ist es mitten in der Nach passiert. Da lief hier gar nichts mehr. Das DOIF mit dem at hat aber korrekt funktioniert und das Modul inkl. Subprozess neugestartet.

Wie häufig tritt das denn bei euch eigentlich auf?

By the way... Ich habe hier auch ein Unifi Netztwerk und mit den Broadcast- bzw. Multicast-Optionen bereits gespielt. Hat aber alles nichts gebracht.

Wer Interesse hat tiefer einzusteigen, kann sich ja mal hier belesen: https://github.com/netdata/netdata/issues/6527

Bei dem github issue habe ich irgendwann mal versucht, dem Thema auf die Schliche zu kommen. Ich dachte dann immer wieder, dass ich es jetzt gelöst habe, aber irgendwann trat das Problem dann wieder auf. Das Ticket ist zwar geschlossen, aber gelöst ist es nicht.

Insbesondere würde mich mal interessieren, was bei euch folgende Befehle ergeben:

Code Auswählen Erweitern

netstat -anus

Code Auswählen Erweitern

netstat -unlp | grep ":1900"

Habt ihr auch diese udp ,,packet receive errors" und ,,receive buffer errors"?

Meine Vermutung ist, dass hier die Ursache liegt. Wahrscheinlich kann das aber nur der Modulentwickler lösen. Denn diese udp errors entstehen bei mir nur, wenn das Sonos Modul aktiv ist.

Gruß Hoppel

[sTaN]

[mention]hoppel118 [/mention] Ich klemme mich morgen noch mal ausgiebig dahinter und gebe dir die Rückmeldung auf deine Abfragen.


Gut zu wissen, dass du auch ein Unifi Netzwerk hast. Denke das haben viele hier. Vielleicht kann man hier Off Topic per PN oder so mal noch ein paar Settings vergleichen. Bei mir tritt das Problem täglich Nachts auf. Ich dachte immer zur gleichen Zeit gegen 02:00 Uhr morgens. Habe keinerlei Zwangstrennungen seitens Provider (Unitymedia/Vodafone) oder ähnliches aktiv.
Aber Problem trat auch schon zu anderen Zeiten auf (siehe letztens 00:30 Uhr)

Ich habe auch noch ein zweites Problem, dass mein harmony Hub ständig auf disconnect geht. Diverse Beiträge sagen immer nur es liegt am Netzwerk. Nach FHEM Neustart läuft es mal 4 Tage und dann irgendwann fängt es wieder an und das regelmäßig alle 20 Minuten.

Deshalb dachte ich zunächst auch ich habe ein Netzwerkthema aber hier scheint irgendwo anders noch der Wurm drin. Ich will nicht grad behaupten, dass ich in dem Bereich nicht versiert bin und habe diverse Themen bereits geprüft und auch teilweise nur minimalistische Settings gehabt. Auch mal VLAN für die Sonos gearbeitet.

Bin auch der Meinung, dass nur der Modulentwickler das Problem in den Griff bekommen kann und hier unterstütze ich gerne wo ich kann.

Gruß
sTaN

[sTaN]

Super, freu mich auf dein Ergebnis.

Tatsächlich haben sich diese Nacht meine Sonos nicht aufgehangen, nachdem ich gestern den LG TV auf die ignored Liste gepackt habe...

Insbesondere würde mich mal interessieren, was bei euch folgende Befehle ergeben:

Code Auswählen Erweitern

netstat -anus

Code Auswählen Erweitern

netstat -unlp | grep ":1900"

Meine Ausgaben sehen wie folgt aus:

Code Auswählen Erweitern

netstat -anus
IcmpMsg:
    InType0: 999
    InType3: 40762
    InType8: 3
    OutType0: 3
    OutType3: 40766
    OutType8: 3506
Udp:
    1275579 packets received
    4 packets to unknown port received
    291887 packet receive errors
    177924 packets sent
    291887 receive buffer errors
    0 send buffer errors
    IgnoredMulti: 166457
UdpLite:
IpExt:
    InMcastPkts: 867973
    OutMcastPkts: 178651
    InBcastPkts: 85677
    OutBcastPkts: 2
    InOctets: 7826468392
    OutOctets: 6042856026
    InMcastOctets: 338985273
    OutMcastOctets: 67518365
    InBcastOctets: 21860178
    OutBcastOctets: 260
    InNoECTPkts: 14613945
    InECT0Pkts: 719


Code Auswählen Erweitern

netstat -unlp | grep ":1900"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
udp   165440      0 0.0.0.0:1900            0.0.0.0:*                           -                   
udp        0      0 0.0.0.0:1900            0.0.0.0:*                           -     

Habt ihr auch diese udp ,,packet receive errors" und ,,receive buffer errors"?

Aber sowas von 

Sobald ich den nächsten Disconnect habe, setze ich dein DOIF ein. Ansonsten habe ich aktuell perfmon installiert und muss auch feststellen, dass das Sonos Modul wahnsinnig Ressourcen Frist. Allein nach dem Start von perfmon folgende Überschreitungen, die alle vom Sonos Modul kommen:

Code Auswählen Erweitern

2020.04.16 16:58:35 1: Perfmon: possible freeze starting at 16:58:32, delay is 3.661
2020.04.16 16:55:31 1: Perfmon: possible freeze starting at 16:55:28, delay is 3.319
2020.04.16 16:52:27 1: Perfmon: possible freeze starting at 16:52:23, delay is 4.028
2020.04.16 16:51:20 1: Perfmon: possible freeze starting at 16:51:17, delay is 3.939
2020.04.16 16:49:22 1: Perfmon: possible freeze starting at 16:49:19, delay is 3.82
2020.04.16 16:47:50 1: Perfmon: possible freeze starting at 16:47:48, delay is 2.068
2020.04.16 16:47:47 1: Perfmon: possible freeze starting at 16:47:46, delay is 1.828
2020.04.16 16:47:34 1: Perfmon: possible freeze starting at 16:47:33, delay is 1.722
2020.04.16 16:47:32 1: Perfmon: possible freeze starting at 16:47:28, delay is 4.024

Dazu gab es ja auch schon diesen Thread hier.

Gruß sTaN

[andre07]

Hallo
Ich benutze seit über ein Jahr eine Version von Januar 2018 und seitdem ist ruhe mit Player disappeared
wird das Modul überhaupt noch gepflegt Fehlerbereinigt.

Andre

[hoppel118]

Aber sowas von 

Ich habe den Verdacht, dass es einen Zusammenhang zwischen den ganzen udp Fehlern und "Sonos Player disappeared" gibt. Ist aber nur eine Vermutung, da ich nicht weiß, wie man das weiter analysieren könnte. Evtl. können ja nochmal ein paar andere Leute prüfen, ob sie diese udp Fehler auch haben. Wie gesagt, sobald man das Sonos Modul disabled, sind auch die udp errors vorbei.

Sobald ich den nächsten Disconnect habe, setze ich dein DOIF ein. Ansonsten habe ich aktuell perfmon installiert und muss auch feststellen, dass das Sonos Modul wahnsinnig Ressourcen Frist. Allein nach dem Start von perfmon folgende Überschreitungen, die alle vom Sonos Modul kommen:

Gut, aber denk dran: Bei mir funktioniert nur die Lösung mit dem at. Wäre aber toll, wenn du dir die DOIF-Lösung ohne at mal anschauen könntest. ICh steige nicht dahinter, warum das nicht funktioniert.

Danke und Gruß Hoppel

[willib]

Gerade funktionierte mein harmony hub nicht. In dem Zuge sind auch wieder die Player disappeared. Das Sonos Modul geht doch selbständig auf disabled. Was macht das Modul vorher? Kann das Modul nicht selbst neu starten oder wenigstens ein Fehler Event erzeugen?
Ich habe auch diverse Fehler vom harmony, mqtt und hmlan im Log. Um 9:10 Uhr habe ich dann das Sonos Modul neu gestartet.

Code Auswählen Erweitern

2020.05.01 08:15:54 3: MQTT2_SERVER: MQTT2_SERVER_192.168.178.77_38998/awtrix left us (keepalive check)
2020.05.01 08:15:54 3: MQTT2_SERVER: MQTT2_SERVER_192.168.178.106_64746/RFID_Reader left us (keepalive check)
2020.05.01 08:15:54 1: HMUARTLGW HMLAN:keepAlive KeepAlive sent 175.566s too late, this might cause a disconnect!
2020.05.01 08:15:55 2: SONOS0: LastProcessAnswer way too old (Lastanswer: 1588313532 ~ 2020-05-01 08:12:12)... try to restart the process and connection...
2020.05.01 08:15:55 2: harmony: disconnect
2020.05.01 08:15:55 1: 192.168.178.39:2001 disconnected, waiting to reappear (HMLAN:keepAlive)
2020.05.01 08:15:55 1: 192.168.178.39:2000 disconnected, waiting to reappear (HMLAN)
2020.05.01 08:15:55 3: Opening HMLAN:keepAlive device 192.168.178.39:2001
2020.05.01 08:15:55 1: 192.168.178.39:2000 reappeared (HMLAN)
2020.05.01 08:15:55 3: HMLAN:keepAlive device opened
2020.05.01 08:15:55 3: HMUARTLGW HMLAN BidCoS-port opened
2020.05.01 08:15:56 3: HMUARTLGW HMLAN:keepAlive KeepAlive-port opened
2020.05.01 08:15:57 3: harmony: connected
2020.05.01 08:15:58 3: harmony: new config
2020.05.01 08:16:06 1: Error parsing >Hello from AWTRIX< for
2020.05.01 08:24:11 1: HMUARTLGW HMLAN:keepAlive KeepAlive sent 14.156s too late, this might cause a disconnect!
2020.05.01 08:24:11 3: MQTT2_SERVER: MQTT2_SERVER_192.168.178.106_58707/RFID_Reader left us (keepalive check)
2020.05.01 08:24:11 1: 192.168.178.39:2001 disconnected, waiting to reappear (HMLAN:keepAlive)
2020.05.01 08:24:11 1: 192.168.178.39:2000 disconnected, waiting to reappear (HMLAN)
2020.05.01 08:24:11 3: Opening HMLAN:keepAlive device 192.168.178.39:2001
2020.05.01 08:24:11 1: 192.168.178.39:2000 reappeared (HMLAN)
2020.05.01 08:24:11 3: HMLAN:keepAlive device opened
2020.05.01 08:24:11 3: HMUARTLGW HMLAN BidCoS-port opened
2020.05.01 08:24:11 3: HMUARTLGW HMLAN:keepAlive KeepAlive-port opened
2020.05.01 08:27:53 1: PERL WARNING: Use of uninitialized value $ret in numeric le (<=) at FHEM/HttpUtils.pm line 646.
2020.05.01 08:43:15 3: MQTT2_SERVER: MQTT2_SERVER_192.168.178.106_51094/RFID_Reader left us (keepalive check)
2020.05.01 08:43:15 1: HMUARTLGW HMLAN:keepAlive KeepAlive sent 12.963s too late, this might cause a disconnect!
2020.05.01 08:43:15 1: 192.168.178.39:2000 disconnected, waiting to reappear (HMLAN)
2020.05.01 08:43:15 1: 192.168.178.39:2001 disconnected, waiting to reappear (HMLAN:keepAlive)
2020.05.01 08:43:15 3: Opening HMLAN:keepAlive device 192.168.178.39:2001
2020.05.01 08:43:15 1: 192.168.178.39:2000 reappeared (HMLAN)
2020.05.01 08:43:15 3: HMLAN:keepAlive device opened
2020.05.01 08:43:15 3: HMUARTLGW HMLAN BidCoS-port opened
2020.05.01 08:43:15 3: HMUARTLGW HMLAN:keepAlive KeepAlive-port opened
2020.05.01 08:47:37 2: harmony: disconnect
2020.05.01 08:47:49 3: harmony: connected
2020.05.01 08:47:50 3: harmony: new config
2020.05.01 08:51:23 2: harmony: disconnect
2020.05.01 08:51:35 3: harmony: connected
2020.05.01 08:51:36 3: harmony: new config
2020.05.01 09:10:56 1: RMDIR: ./restoreDir/save/2020-04-25
2020.05.01 09:11:48 1: SONOS0: Kein UPnP-Server gefunden... Starte selber einen und warte 1 Sekunde(n) darauf...
2020.05.01 09:11:49 1: SONOS0: ./FHEM/00_SONOS.pm is started by fhem...

[Otto123]

Ich würde sagen, etwas blockiert dein FHEM gewaltig.
freezemon könnte helfen den Schuldigen zu finden?

[hoppel118]

Kann das Modul nicht selbst neu starten oder wenigstens ein Fehler Event erzeugen?

In den letzten 20 Posts haben wir einen Workaround mit at und doif diskutiert. Dieser wurde hier von @aski71 vorgestellt:

https://forum.fhem.de/index.php?topic=46058.msg937508#msg937508


Gruß Hoppel

[willib]

Ok. Danke. Habe ich jetzt so übernommen. Ich hatte verstanden, das es nicht immer funktioniert. Ich habe das rescan network weg gelassen. Vermutlich kann das wait noch verkürzt werden. Wenn ich das Attribut händisch gesetzt und wider gelöscht habe lagen maximal 10 Sekunden dazwischen. Hat aber immer funktioniert. Freezemon läuft jetzt auch.

[hoppel118]

Mit dem at gemeinsam funktioniert das DOIF bei mir immer. Das rescan network habe ich auch weggelassen. Es müsste eigentlich auch ohne at funktionieren, tut es aber nicht. Warum nicht? Da hört mein Verständnis dann auf...

Gruß Hoppel