SONOS Player Disappeared ... immer und immer wieder

rohlande · 07 Januar 2018, 19:39:45

Hallo Reinerlein,

Das bringt also nur etwas, wenn die Auflösung von localhost auf 127.0.0.1 oder die echte lokale IP sehr lange dauert (oder gar nicht funktioniert).

Und da bin ich der Meinung das hier Debian besser als Ubuntu läuft.
Genau auf Grund der Performance hatte ich nachgeschaut und stelle fest, dass die Prozesse laut htop viel performanter laufen obwohl ich genug Leistung am Server zur Verfügung habe.
Das fiel mir auf als ich mit "disable" getestet habe.
Wenn es die Tage satbil bleibt bin ich sehr zufrieden.

Deswegen habe ich auch den Umzug von der Synology auf den Zotac Mini Server vollzogen. Das wurde zwangsweise durch die immer größer werdende Fhem Installation notwendig.

VG Denny

Ich kann ergänzen, das seit 3 Tagen das Sonos Modul nicht ausgestiegen ist und durchgänig läuft. Damit hat die Anpassung bezüglich Auflösung localhost ergo 127.0.0.1 doch etwas gebracht und die Performance ist super fix was die Ansprechzeiten aus dem Dashboard angeht. Super Modul Reinerlein. Damit werden nun weitere SONOS ins Haus folgen!!

Reinerlein · 07 Januar 2018, 20:02:22

Hi ready,

da mischt sich bei dir ein Nicht-Sonos-Player in die Erkennung mit ein. Da dieser eine Nicht-Sonos-Kompatible XML-Struktur zurückliefert (in diesem Fall JSON-Daten), knallt es beim SubProzess (bzw. in der UPnP-Library).

Setz mal das Attribut

Code Auswählen


attr Sonos ignoredIPs 192.168.62.10

@Denny: Wenn es hilft, ist das super

Es wird halt zum Socket-Öffnen mittels Systemroutinen verwendet. Alles, was das beschleunigt, ist gut...

Grüße
Reinerlein

r_e_a_d_y · 07 Januar 2018, 22:44:46

Hi Reinerlein,

großartig und danke, dass du dir die Mühe machst!!
Die IP Adresse ist mein Rechner, von dem aus ich die ganze Fhem-Konfiguration mache. Kann es sein, dass diese Log-Einträge geschrieben wurden, wenn ich z.B. im Fhem-UI > SONOSPLAYER auf den Play- oder Stopp-Button gedrückt habe? Anders kann ich mir nicht erklären, dass in den Logs plötzlich mein Rechner auftaucht.

Ich setze jetzt mal das Attribut und gebe dir Rückmeldung.

Viele Grüße, ready

Reinerlein · 07 Januar 2018, 22:47:24

Hi ready,

nein, davon kommt das nicht. Dein Computer meldet sich als UPnP-Server, und stört die Erkennungsroutinen des Moduls...

Grüße
Reinerlein

r_e_a_d_y · 07 Januar 2018, 23:49:53

Ich glaubs nicht !! ... wie von Zauberhand darf ich nun auch über das Fhem-UI > Sonosplayer auch die Box steuern

.

Reinerlein, du bist mein Held!! Das hätte ich wohl so nie herausgefunden!
Ich werde es jetzt mal beobachten, ob der Player sowie die Sonos selbst immer noch irgendwie wegfliegen. Im Moment sieht es aber sehr gut aus!

Du hast somit meine größte Hürde beseitigt ... jetzt kanns losgehen

.

Update: Also einen Tag später kann ich Erfolg vermelden: Es läuft nun stabil und die Sonos Play:1 kann problemlos angesteuert werden mit:

Code Auswählen

defmod Sonos SONOS localhost:4711 30 1 5
attr Sonos SubProcessLogfileName ./log/Sonos_SubProcess.log
attr Sonos ignoredIPs 192.168.xx.xx # störender UPnP-Server (in diesem Fall mein Rechner)
attr Sonos pingType icmp

Viele Grüße, ready

KalleBlomquist · 12 Januar 2018, 10:44:39

Hallo,

ich habe das Problem leider immer noch

Das habe ich bereits versucht:

- Update auf aktuelles SONOS-Modul
- localhost auf 127.0.0.1 geändert
- Port von 4711 auf 4721 geändert
- Aktualisierungsintervall auf 60s und auch auf 120s gesetzt
- attr usedonlyIPs gesetzt und die IP-Adressen der Sonos-Devices eingetragen
- attr pingType auf syn gesetzt

Leider kommt immer wieder "Das Lauschen auf der Schnittstelle wurde beendet. Prozess endet nun auch..."

Ich hab mal verbose auf "5" gesetzt und 2 Logfiles angehängt.
Vielleicht kann mir jemand sagen, woran es noch liegen kann.

VG
Kalle

r_e_a_d_y · 12 Januar 2018, 17:23:26

Hallo Kalle, stört bei dir auch ein UPnP-Server im Netzwerk, wie bei mir? In dem Fall: hast du statt usedonlyIPs mal ignoredIPs versucht, um den jeweiligen Server auszuschließen? Bei mir läuft die Verbindung seitdem. Grüße, ready

KalleBlomquist · 12 Januar 2018, 18:03:17

Eigentlich nicht, aber wie kann ich das herausfinden ?
In den LogFiles finde ich nichts ...

Reinerlein · 12 Januar 2018, 20:28:17

Hi Kalle,

kannst du mal in und um Zeile 9938 ein paar Ausgaben/Anpassungen einbauen?
Alt:

Code Auswählen


state $setCurrentUDN;

Neu:

Code Auswählen


SONOS_Log undef, 4, "SONOS_Client_Notifier: Before state";
state $setCurrentUDN = '';
SONOS_Log undef, 4, "SONOS_Client_Notifier: After state";

Irgendwie vermute ich dort etwas. Es wird ganz oft ein ProcessRefresh angefordert, er kommt im SubProzess auch an, und es soll auch eine Antwort erzeugt werden (mittels dieser Prozedur "SONOS_Client_Notifier"), aber es kommt nicht mehr die Log-Ausgabe aus Zeile 9948 (und natürlich auch keine Antwort im FHEM-Modul), der bleibt also vorher hängen...

Grüße
Reiner

KalleBlomquist · 12 Januar 2018, 22:47:25

Hi Reinerlein,

erstmal vielen Dank für Deine Unterstützung und Mühe !

Ich habe den Code eingebaut und FHEM neu gestartet.
Verbose habe ich mal wieder auf "5" gesetzt.
Mal seh´n was passiert

VG
Kalle

KalleBlomquist · 12 Januar 2018, 23:14:03

Hier die Logs nach dem erneuten Disconnect (s. Anhang)

VG
Kalle

Reinerlein · 13 Januar 2018, 00:13:51

Hi Kalle,

hmm... ok, dann halt keine Ausgabe im Log

Basteln wir mal weiter.

Kannst du bei Zeile 10219 mal zusätzliche Log-Ausgabe reinpacken?
Alt:

Code Auswählen


if ($SONOS_Thread != -1) {
	$SONOS_ComObjectTransportQueue->enqueue(\%data);
}

Neu:

Code Auswählen


SONOS_Log undef, 5, "Angekommen vor Thread-Prüfung...";
if ($SONOS_Thread != -1) {
	SONOS_Log undef, 5, "Angekommen vor Queue...";
	$SONOS_ComObjectTransportQueue->enqueue(\%data);
	SONOS_Log undef, 5, "Angekommen nach Queue...";
}

Der scheint wirklich früh schon nichts mehr zu machen... wir hangeln uns mal nach vorne

Sorry dafür...

Grüße
Reiner

KalleBlomquist · 13 Januar 2018, 11:23:41

Hi Reinerlein,

kein Problem, bin ja froh dass Du mal drüber schaust...

Ich habe die Code-Änderungen gemacht und anbei die neuen Logs ...

Gruß Kalle

Reinerlein · 14 Januar 2018, 13:29:17

Hi Kalle,

hmm, ok, da geht er schon mal rüber.
Also weiter

Um Zeile 2400 rum steht die Schleife für die Client-Verarbeitung:

Code Auswählen


my @sockets = $select->can_read(0.01);
for my $sock (@sockets) {
	$SONOS_Controlpoint->handleOnce($sock);
}

Dort mal das folgende hinschreiben (also ein if drum):

Code Auswählen


if (my @sockets = $select->can_read(0.01)) {
	for my $sock (@sockets) {
		$SONOS_Controlpoint->handleOnce($sock);
	}
}

Und kurz danach noch eine Log-Ausgabe einbauen.
Alt:

Code Auswählen


# Befehlsqueue abfragen...
while ($SONOS_Client_ReceiveQueue->pending()) {
	SONOS_Discover_DoQueue($SONOS_Client_ReceiveQueue->dequeue());
}

Neu:

Code Auswählen


# Befehlsqueue abfragen...
while ($SONOS_Client_ReceiveQueue->pending()) {
	SONOS_Log undef, 5, "Angekommen vor DoQueue...";
	SONOS_Discover_DoQueue($SONOS_Client_ReceiveQueue->dequeue());
	SONOS_Log undef, 5, "Angekommen nach DoQueue...";
}

Irgendwann müssen wir ja mal an das eigentliche Problem kommen... viel Platz ist zwischen unseren Ausgaben ja nicht mehr

Grüße
Reiner

KalleBlomquist · 15 Januar 2018, 11:34:35

Hi Reiner,

ich habe den Code eingebaut und schicke Dir anbei wieder die Logs.
Mal sehn ob jetzt was angekommen ist ...

Gruß
Kalle