Sonos Player disappeared

Begonnen von aherby, 22 Dezember 2015, 18:20:38

Vorheriges Thema - Nächstes Thema

mumpitzstuff

#210
Okay dann mal der Reihe nach:

1.) Dein IsAlive Thread wird nur alle 120 Sekunden ausgeführt, was du in deinem Device anscheinend als Interval konfiguriert hast. Da ich den Retry Counter auf 10 erhöht habe, bedeutet das: 10 * 2min = 20min. Ich vermute also das du das erst nach 20min sehen würdest.

2.) Das irgendwas nicht mehr so gut läuft mit ausgeschaltetem Player und tcp als Ping liegt nicht an meinen Änderungen. Das Verhalten lässt sich mit Sicherheit auch mit dem Originalmodul reproduzieren. Ob ich da im Detail eine Ursache identifizieren kann, muss ich gucken. Die Information ist aber super und hilft vielleicht dem einen oder anderen, der solche Probleme bereits beobachtet hat. Btw was steht denn in dem Reading location des Players drin, den du ausgeschaltet hattest?

3.) Die rund 15min dürften exakt 20min sein. Ich habe den default Wert verwenet, der bei 30s liegt, deshalb meine Schätzung von 5min.

4.) Die Fehlermeldung: "PERL WARNING: Redundant argument in sprintf at ./FHEM/21_SONOSPLAYER.pm line 432." scheint von deinem Attribut simulateCurrentTrackPositionPercentFormat im SONOSPLAYER zu kommen. Was steht denn da bei dir drin? Es sollte irgendwas in der Art sein: %.1f

5.) Den FHEM Fehler "PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4790" kann ich nicht lokalisieren. Eventuell könntest du den stacktrace in FHEM aktivieren, dann sieht man wahrscheinlich genau wo es her kommt. Auf jeden Fall ist es ein fehlerhaftes readingsBulkUpdateIfChanged(), wahrscheinlich irgendwo aus den Tiefen des SONOS Moduls.

6.) Die Fehler aus der ControlPoint hängen mit hoher Wahrscheinlichkeit mit den Versuchen zusammen, den ausgeschalteten Player wieder zu finden. Leider kümmert sich die gesamte ControlPoint nicht um Loglevel von FHEM und pumpt daher jeden Mist ins Logfile rein. Daran kann ich aber auf die Schnelle nichts ändern, außer das iich meiner ControlPoint diese Fehlermeldung entfernen kann, falls gewünscht.

Alles in allem sieht es doch schon ganz gut aus und vielleicht finde ich auch noch was bezüglich dem tcp Ping Problem...

juemuc

Also bei mir geht die Sonosbox (Playbar) nach wenigen Minuten in den Status disappeared (Stecker gezogen). Allerdings auch mit den "Original".
Sonos läuft bei mir auf 2 pi's und einem Ubuntu-System (Testsystem). 
Dann "Stecker rein". Alles wieder ok (in allen Systemen).

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

det.

Zitat von: mumpitzstuff am 05 Juni 2020, 20:15:59
Okay dann mal der Reihe nach:

1.) Dein IsAlive Thread wird nur alle 120 Sekunden ausgeführt -- genau so war es -- auf 30 s geändert

2.) Das irgendwas nicht mehr so gut läuft mit ausgeschaltetem Player und tcp als Ping liegt nicht an meinen Änderungen. -- hatte ich Dir auch nie angelastet - mit syn ist das weg und das läuft bei mir eh geschmeidiger

3.) Die rund 15min dürften exakt 20min sein. Ich habe den default Wert verwenet, der bei 30s liegt -- siehe 1

4.) Die Fehlermeldung: "PERL WARNING: Redundant argument in sprintf at ./FHEM/21_SONOSPLAYER.pm line 432." scheint von deinem Attribut simulateCurrentTrackPositionPercentFormat im SONOSPLAYER zu kommen. Was steht denn da bei dir drin? Es sollte irgendwas in der Art sein: %.1f -- das ist eine Listbox mit Auswahl von 0 bis 60 -- bei mir 0

5.) Den FHEM Fehler "PERL WARNING: Use of uninitialized value $value in string eq at fhem.pl line 4790" kann ich nicht lokalisieren. Eventuell könntest du den stacktrace in FHEM aktivieren, dann sieht man wahrscheinlich genau wo es her kommt. Auf jeden Fall ist es ein fehlerhaftes readingsBulkUpdateIfChanged(), wahrscheinlich irgendwo aus den Tiefen des SONOS Moduls. -- vieleicht später mal, wenn Du es nicht als übermäßig dringend siehst?

6.) Die Fehler aus der ControlPoint - gibt es nur bei tcp - wäre mir egal
Alles in allem sieht es doch schon ganz gut aus und vielleicht finde ich auch noch was bezüglich dem tcp Ping Problem...
Auf jeden Fall vielen Dank für Deinen Einsatz - bitte check das doch am Ende dann mal ins svn ein.
LG
det.

mumpitzstuff

Zitat von: juemuc am 05 Juni 2020, 20:26:08
Also bei mir geht die Sonosbox (Playbar) nach wenigen Minuten in den Status disappeared (Stecker gezogen). Allerdings auch mit den "Original".
Sonos läuft bei mir auf 2 pi's und einem Ubuntu-System (Testsystem). 
Dann "Stecker rein". Alles wieder ok (in allen Systemen).

Viele Grüße
Jürgen

Geht das bei dir auch mit syn Ping mit dem "Original"?

mumpitzstuff

@det:

Was steht denn in dem Reading location des Players drin, den du ausgeschaltet hattest?

Zu 4.) Das verstehe ich nicht recht. Wenn ich mir ein SONOSPLAYER Device anlege, dann ist das Attribut simulateCurrentTrackPositionPercentFormat bei mir ein Textfeld, in das ich einen beliebigen String reinschreiben kann. Versuch mal das Attribut wie folgt zu setzen bitte:

attr <SONOSPLAYER Device> simulateCurrentTrackPositionPercentFormat %.1f

det.

Zitat von: mumpitzstuff am 05 Juni 2020, 21:14:54
@det:
Zu 4.) Das verstehe ich nicht recht. Wenn ich mir ein SONOSPLAYER Device anlege, dann ist das Attribut simulateCurrentTrackPositionPercentFormat bei mir ein Textfeld, in das ich einen beliebigen String reinschreiben kann. Versuch mal das Attribut wie folgt zu setzen bitte:

attr <SONOSPLAYER Device> simulateCurrentTrackPositionPercentFormat %.1f
4) -- habe ich bei allen Playern soeben angelegt.
Was steht denn in den Readings  location der Player drin, die du ausgeschaltet hattest?  -- HISTORISCHE Daten

location http://192.168.2.25:1400/xml/device_description.xml2019-07-22 14:04:18

location http://192.168.2.26:1400/xml/device_description.xml2019-07-22 14:04:21

location http://192.168.2.27:1400/xml/device_description.xml2019-07-22 14:04:19

location http://192.168.2.22:1400/xml/device_description.xml2019-07-22 14:04:24


die ältesten anderen Readings sind von 2017 - sollte ich da mal aufräumen?
LG
det.

juemuc

Zitat von: mumpitzstuff am 05 Juni 2020, 21:00:35
Geht das bei dir auch mit syn Ping mit dem "Original"?

Nein, da bleibt der Player auf appeared. Mit PingType "tcp" geht der Player immer auf "disappeared". Konnte dies mit 3 Systemen parallel testen.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

mumpitzstuff

Okay dann passt das ja. Ich habe nur den syn Ping gefixt (was dummerweise der Default ist). Alle anderen Ping Arten sollten vorher funktioniert haben und mit meiner angepassten Version genauso.

87insane

Zitat von: mumpitzstuff am 06 Juni 2020, 00:44:43
Okay dann passt das ja. Ich habe nur den syn Ping gefixt (was dummerweise der Default ist). Alle anderen Ping Arten sollten vorher funktioniert haben und mit meiner angepassten Version genauso.
Ne dem ist nicht so. TCP ging auch nicht. Verfiziere das aber mit dem aktuellen nochmal.

Gesendet von meinem LM-G810 mit Tapatalk


mumpitzstuff

Ich habe es noch mal mit einem Script geprüft. Der tcp Ping funktioniert schon wie gewünscht, so wie er implementiert war und auch noch ist. Ich kann dir das Script auch noch mal zur Verfügung stellen, dann kannst du das unabhängig von fhem prüfen. Geht aber erst morgen...

87insane

#220
Prüfe gerne alles damit das rund wird! Danke für deine Mühen.

Edit: an der Stelle würde ich mir gern auch doppelte Arbeit sparen. Also ohne angeben zu wollen ist mir klar wie ein Netzwerk funktioniert. Ich bin gespannt wie du das nun gegen prüfen willst. Bis auf UDP bin ich mit den alternativen absolut einverstanden :) also mir wäre es egal wie geprüft wird.

Gesendet von meinem LM-G810 mit Tapatalk

mumpitzstuff

So ich habe die 4 Ping Arten noch mal genau unter die Lupe genommen und leider funktioniert weder die originale syn version richtig, noch meine. Ich habe jetzt mal ein Script gebastelt, mit dem man die 4 ping arten durchprobieren kann. Oben im Script kann man die IP so anpassen, das sie der IP eines SONOS Gerätes entspricht. Alle Pings sollten jetzt "reachable" anzeigen (UDP funktioniert nur, wenn das SONOS Gerät das ECHO Protokoll unterstützt). Danach kannst du die IP auf etwas ändern, das es nicht in deinem lokalen Netzwerk gibt und jetzt müssten alle "not reachable" anzeigen.

Kannst du mir das bitte bestätigen? Funktioniert der UDP Ping überhaupt? Wenn ja, passe ich das SONOS Modul entsprechend an und dann sollte es reibungslos gehen.

PS: Den Port bitte nicht verändern, das ist der Port der auch im SONOS Modul verwendet wird.

Nobby1805

Alle SONOS-Geräte sind mit allen Methoden reachable, unbekanntes Gerät ist not reachable ;)
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

Nobby1805

Ich habe bei mir im SONOS-Modul zusätzliche Loggings eingebaut, z.B. wird die Zeit ausgegeben, die zwischen den Keep-Alives abgelaufen ist
Zitat2020.06.07 11:13:26.495 2: SONOS0: LastProcessAnswer 60.0386807918549
Da ist mir dann aufgefallen, dass wenn ein SONOS-Gerät abgeschaltet ist folgende Ausgabe alle 30 Minuten kommt
Zitat2020.06.06 08:37:38.616 2: SONOS0: LastProcessAnswer 60.0346438884735
2020.06.06 08:38:38.647 2: SONOS0: LastProcessAnswer 120.065936803818
2020.06.06 08:39:38.696 2: SONOS0: LastProcessAnswer 180.112892866135
2020.06.06 08:41:02.819 2: SONOS0: LastProcessAnswer 60.0335249900818
und bei 240 Sekunden wäre dann die Meldung "... way too old ..." gekommen und Sonos hätte sich aufgehängt. Was passiert dort alle 30 Minuten?

Es wird ein RenewSubscription durchgeführt, das sind bei den bei mir vorhandenen Geräten zwischen 2 und 9 einzelne Renews für die jeweils ein Timeout von 20 Sekunden eingestellt ist und die Keepalives hängen in der Bearbeitungsqueue hinter den Renews und werden dadurch verzögert.

Was ich jetzt nicht verstehe ist, warum in SONOS_ProcessRenew der Timeout-Fall nicht erkannt wird und der Player nicht entfernt wird (obwohl das, soweit ich die Kommentare dort verstehe, passieren sollte)?
FHEM-Featurelevel: 6.2   (fhem.pl:28227/2023-11-29) auf Windows 10 Pro mit Strawberry Perl 5.32.1.1-32bit
TabletUI: 2.7.15
IO: 2xHMLAN(0.965)|HMUSB2(0.967)

mumpitzstuff

#224
Zitat von: Nobby1805 am 07 Juni 2020, 10:41:53
Alle SONOS-Geräte sind mit allen Methoden reachable, unbekanntes Gerät ist not reachable ;)

Sehr gut. Danke. Dann passe ich das Modul entsprechend an.

Das andere muss ich mir in Ruhe ansehen, dazu kann ich vielleicht später etwas sagen.