Sonos Player disappeared

87insane · 28 Mai 2020, 22:48:33

Wenn ich die beiden Dateien compare... sieht schön aus.
Ich kann natürlich nicht so gut im Detail verstehen was da passiert aber ich biete mich an. Lade mir die Dateien gleich runter. Test ist dann aber erst morgen, da ich aktuell noch in was anderem hänge.

Danke! Für mich hört und liest sich das zumindest logisch. Ich weiß aber nicht in wie weit da FHEM Abhängigkeiten oder so betroffen sind. Ggf. macht es Sinn, das dies einer der Ein-geschworenen mal gegen checkt. Also nach einem sinnigem Test-Durchlauf.

Danke Dir! Echt schön das jemand ohne dieses System überhaupt mal darein schaut. Meist macht man das ja aus Interesse oder so. Wird immer angenehmer hier

PS: Kommt zumindest ohne Fehler hoch.. rest, morgen. Bin gespannt!

hoppel118 · 29 Mai 2020, 08:23:16

Super, danke allen, die sich hier gerade einbringen. Bin etwas länger im Urlaub und kann hier nicht wirklich unterstützen/testen. Ich versuche heute Abend mal die beiden Dateien per Smartphone/VPN auszutauschen.

Wie soll ich das Loglevel einstellen? Gibt es eigentlich eine Möglichkeit die Logs vom Sonos-Modul (oder irgend ein anderes Modul) in eine eigene Datei umzuleiten?

Viele Grüße Hoppel

87insane · 29 Mai 2020, 08:27:59

Das Sonos Modul kann das laut Doku via attr.

Ich hab die Daten gestern Abend rein geschmissen. Vorhin ging noch alles. Im log sind keine fehler aufgetaucht und mir ist nichts anderes aufgefallen.
Dennoch die frage ob es nicht sinn macht das speziell mit zu loggen. Wenn ja, ideen? So tief war ich noch nicht in den Modulen mit drin...

Danke und bis später

Gesendet von meinem LM-G810 mit Tapatalk

hoppel118 · 29 Mai 2020, 08:53:03

Zitat von: 87insane am 29 Mai 2020, 08:27:59
Das Sonos Modul kann das laut Doku via attr.

Danke für die Info. Stimmt, folgendes steht dazu im Wiki:

Zitat
SubProcessLogfileName <Pfad>: Hiermit kann für den SubProzess eine eigene Logdatei angegeben werden. Unter Windows z.B. überschreiben sich die beiden Logausgaben (von Fhem und SubProzess) sonst gegenseitig. Wenn "-" angegeben wird, wird wie bisher auf STDOUT (und damit im Fhem-Log) geloggt. Der Hauptanwendungsfall ist die mehr oder weniger kurzfristige Fehlersuche. Es werden keinerlei Variablenwerte ersetzt, und der Wert direkt als Dateiname verwendet.

Zitat von: mumpitzstuff am 28 Mai 2020, 22:39:40Auf 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.

Dann hoffe ich mal, dass wir nicht alle zu blöd waren, das Wiki zu lesen.

Nach deinem Hinweis habe ich gerade folgendes gefunden:

Zitat
reusePort(0,1): Eines von (0,1). Gibt an, ob die Portwiederwendung für SSDP aktiviert werden soll, oder nicht. Kann Restart-Probleme lösen. Wenn man diese Probleme nicht hat, sollte man das Attribut nicht setzen.

Hat das schonmal jemand mit den disappeared-Problemen probiert? Ich persönlich nicht.

Macht es Sinn, dass zu testen, bevor man das angepasste Modul installiert? Wie seht ihr das?

Danke und viele Grüße Hoppel

87insane · 29 Mai 2020, 09:01:28

Tatsächlich habe ich alles mögliche probiert - das aber nicht! Hatte gerade extra nochmal geguckt.

Wie oft hattest du bisher die restarts?
Auch würde mich interessieren, warum dort steht das wenn man Probleme hat soll man das testen und wenn nicht, bloß nicht setzen..?

Ich hab die Daten drin und den disappercheck (doif) aus geschaltet. Wie wäre es wenn du es mit dem attr testest?

Muss ich mal schauen wie der Code um das attr aussieht.

EDIT: Hab hier auch noch was altes von reinerlein selber gefunden: https://forum.fhem.de/index.php/topic,89349.msg901696.html#msg901696
Hilft uns das?

Gesendet von meinem LM-G810 mit Tapatalk

hoppel118 · 29 Mai 2020, 09:23:15

Jo, ich schalte das attr gleich mal an und mein DOIF aus ohne die Dateien auszutauschen.

Das Logfile aktiviere ich dann heute Abend, wenn ich etwas Zeit habe.

Ich wäre niemals darauf gekommen, reuseport mit den disappeared-Problemen in Verbindung zu bringen...

Das kann ewig dauern bis ich eine Aussage dazu treffen kann, ob das Problem gelöst ist. Manchmal tritt das Problem mehrmals täglich, manchmal einmal im Monat auf.

Gruß Hoppel

87insane · 29 Mai 2020, 09:29:30

Ja gut das bedeutet testen.. Deswegen ist es ja auch gut das so viele hier gerade aktiv sind...

Noch was gefunden in anderem Zusammenhang aber auch mit Problemen.... https://forum.fhem.de/index.php/topic,52561.msg443690.html#msg443690

Die Frage die sich mir hier stellt... Was nutzt FHEM für andere Module? Also macht es Sinn diese Einstellung zu nutzen? Entstehen Nachteile?

Nobby1805 · 29 Mai 2020, 09:58:09

Zitat von: 87insane am 29 Mai 2020, 08:27:59
Das Sonos Modul kann das laut Doku via attr.

wie die Doku schon sagt, damit wird die Ausgabe des SUB-PROZESSES in eine Datei umgeleitet.

Ich hatte vor einiger Zeit ähnliche Probleme mit Reinerlein diskutiert, wo es um Kommunikationsprobleme zwischen dem Hauptprozess und dem SONOS-Subprocess ging und das "normale" Logging schwer (bis nicht) interpretierbar war, weil es zu unschönen Vermischungen der beiden Log-Streams kam.

Leider wurde das eigentliche Problem nicht lokalisiert. Nach Einbau weiterer Logs war zu erkennen, dass manchmal anscheinend eine Message zwischen Haupt- und Sub-Process nicht ankommt ... aber warum?

Ich habe dann nach längerer Suche aufgegeben und mache jetzt jede Nacht ein Disable und Enable, zumindest sind die Probleme jetzt weg.

87insane · 29 Mai 2020, 10:12:44

Welche Message oder ist es zufällig? Um so genauer unsere Beschreibungen, um so eher können wir die glaskugel weg legen

Ist doch schon mal einer der erfolgreicheren dissapper threads

Gesendet von meinem LM-G810 mit Tapatalk

Nobby1805 · 29 Mai 2020, 11:52:32

... manchmal ... anscheinend ...

nichts genaues weiß man leider nicht ... bei mir trat es immer mal wieder mit der Keep-Alive-Message auf und dann kam die "... way too old ..."-Meldung

mumpitzstuff · 29 Mai 2020, 15:00:37

Ich habe in diesem Thread weiter vorn noch ein Logfile gefunden und noch eine weitere Stelle gefunden die Probleme machen könnte. In der Funktion SONOS_ProcessRenew() wird der Discovery Process neu gestartet, wenn ein Timeout bei einer Subscription erreicht wurde (30 Minuten). An dieser Stelle habe ich Code eingefügt, der nun den gesamten ControlPoint restartet, da sich unter Umständen ja auch dieser komplett verabschiedet hat.
Ich habe beide Dateien noch einmal angehangen...

PS: Im SONOS Modul gibt es auch noch 2 Stellen im Code die ohne reusePort und ohne reuseAddr arbeiten. Vielleicht sollte ich da mal versuchen diese Optionen ebenfalls noch einzubauen, bin mir aber zumindest an der einen Stelle nicht ganz sicher, ob das zum Konzept gehört, deshalb habe ich es erst einmal gelassen.

hoppel118 · 29 Mai 2020, 20:01:28

@mumpitzstuff So wie ich das sehe, teste ich am besten gleich deine beiden Dateien. Alles was du hier schreibst hört sich sinnvoll an.

reusePort muss ich dann aber trotzdem noch auf 1 setzen, oder ist das attr jetzt obsolet?

verbose setze ich auf 5, die Ausgabe des subprozesses werde ich dann auch aktivieren.

Gruß Hoppel

mumpitzstuff · 29 Mai 2020, 20:32:07

In der Testversion habe ich reusePort immer auf 1 gesetzt, um erst mal von Einstellungen unabhängig zu sein. Du Must also nichts einstellen wenn du beide Dateien installierst.

hoppel118 · 29 Mai 2020, 20:37:10

Ok, danke dir! Werde es später installieren.

87insane · 29 Mai 2020, 20:50:20

Was ist aus dem eigentlichem Betreuer geworden? Weiß das wer etwas?

Bei mir läuft heute sogar den ganzen Tag Musik im Garten. Bedeutet, mit umklemmen läuft es noch. Ich hänge aber noch bei der Frage was das Problem ggf global auslöst oder bedingt. Der ganze Verkehr läuft auf verschiedenen Prozessen usw. Fhem weit kann ich das aber nicht beurteilen.

Gesendet von meinem LM-G810 mit Tapatalk