12299 Squeeze Baustein

[ThorstenGehrig]

Verstehe gerade nur Bahnhof.
Login? Ich habe kein Login für den LMS...
Gruß
Thorsten

[tbi]

Also bei E2 kann:

kann für Squeezeserver it Passwortschutz Userid und Passwort definiert werden (login=user passwort. BSP: login=admin 1234). Squeezeserver ohne Passwortschutz ignorieren diesen Parameter

Im Code ist das dann:

                ## Verbinden
                ###DEBUG###print "Connect to SqueezeServer "+self.boxip+":"+str(self.__config['port'])
                self.__socket.connect((self.boxip,self.__config['port']))
                self.log(self.lang['SBS_CONNECT'] % (self.boxip,self.__config['port']))

                ## hier wird logon gemacht. Wenn login leer ist wird nur lur login gesendet ansonsten userid und pw.
                ## als Antwort kommt immer "login" [COLOR=Red][B]## Das ist Zeile 342[/B][/COLOR]
                self.sendcmd('login ' + self.__config['login'])
           

                ### Evtl. Versionstring oder ähnliches abfragen
                res = self.__socket.recv(1024)

Oder er kann eben nicht ein connect aufmachen ??

Gruß Tbi

[eckerho1]

Hallo Tobias

Da die comments nicht mitkompiliert werden kann man nicht auf die Zeilennummern gehen.

@Thorsten
Während dem Init des Bausteins werden alle Player "eingesammelt". Wenn der Visu Server dann grad im Standby ist kann es sein, dass der Softsqueeze sich abgemeldet hat und nicht in die Liste mit aufgenommen wird. Wenn du dann eine Ansage auf den Softsqueeze machst, dann kann es zu diesem Fehler kommen.

Gruss, Holger

[tbi]

Da die comments nicht mitkompiliert werden kann man nicht auf die Zeilennummern gehen.

Das kann natürlich sein, wäre mal zu prüfen, wie man die Zeilen info trotzdem sinnvoll nutzen kann.

Gruß Tbi

[tbi]

Hallo,

ich habe heute eine sehr interessante Sache herausgefunden:

Wenn man die Squeezebox Receiver beim Ausschalten vom Netz trennt:

Ja, das geht ja nur bei so verrückten wie uns hier, die alle Steckdosen geschaltet haben.

Also wenn man das so aus macht und dann wieder ans Netz gibt und
"Power 1" und Play setzt.

Dann kommt es bei mir zu einem Verbindungsneuaufbau und der Receiver hängt.

Das ist 100% Prozent reproduzierbar.

Ich habe mit Telnet auf das CLI Interface "listen 1" mitlaufen lassen. Da werden dann Tonnen von irgendwelchen Display infos rausgeschrieben. Also Der SqueezeServer und der Receiver mögen das also definitiv nicht.

Wenn der Squeezebox Receiver am NETZ bleibt, kommt es nicht zu den Verbindungneuaufbau und er reagiert wie erwartet.

@Matthias: Das sieht so sehr nach deinem Fehlerbild aus. Ist es das ?

Darauf muß man erstmal kommen. Aber ich erinnere mich daran, dass im Squeeze Forum jemand das schon mal geschrieben hatte. Das der SB Receiver das nicht mag, wenn er vom Netz getrennt wird.

Gruß Tbi

[hartwigm]

Hallo tbi,

das trifft auch genau mein Problembild. Ich habe geschrieben, dass ich seit der Systemlog korrekt läuft keine Abbrüche mehr habe.

Allerdings hatte ich auch bis zu diesem Zeitpunkt mit der Schlafentaste den SqueezeReceiver wie Du beschrieben hast vom Netz genommen. Da ich an der Steckdose aber derzeit einen anderen Verbraucher habe, ist dies abgeschaltet.

Werde ich aber morgen nochmals gegenprüfen.

[MatthiasS]

Meine laufen durch, leider

[tbi]

Hallo Matthias,

zumindest bleibt ja die Erkenntnis, dass es durchaus passieren kann das sich das CLI verschluckt und deshalb die Verbindung vom Squeeze Baustein neu aufgebaut wird.

Nun solltest Du wirklich mit Telnet auf dem CLI port mal mit "listen 1" tracen.

Unter Windows: ausfuhren => cmd für ein DOS Fenster.

Dann: telnet <ip-des-Squeeze-Server> <Port-des-CLI>

Dann "listen 1" eingeben.

Nun wird nicht alles, aber sehr viel angezeigt, was über das CLI geht. Was angezeigt wird ist durch den Befehl "subscribe ..." festgelegt. Er wird immer nach dem Verbindungsaufbau vom Squeeze Baustein gesendet. Daran kannst Du auch im trace sehen, wo der Verbindungsaufbau stattfindet.

Interessant ist dann alles was davor passiert ist.

Gruß Tbi

[MatthiasS]

Die Erkenntnis des Verschluckens hatte ich ja schon länger

Der ist neu:

09.11.2011 09:24:07 (2)
File "/hs/compile/hs_logik.py", line 232, in calc
File "formula", line 0, in ?
NameError: name 'KNXUF_Squeeze' is not defined
[5012L, 12299L, 1L, 'EC[5]', 'KNXUF_Squeeze(pItem,EN[1],EN[2],EN[3])', '', 0L, 0L, 1L, 0L]

Passiert bei einem Reset an E5.

[tbi]

Der Reset ist eine (noch offene ?) Baustelle von Holger.
Von der Benutzung hat er zur Zeit abgeraten.

Würde ich also im Moment gar nicht machen !!!

Der Baustein verbindet sich ja selbst wieder.

Vielleicht ist es das, wo das Problem ist. Machst Du den Reset schon immer ?

Welchen Baustein (Version ?) hast Du gerade zu laufen ?

Gruß Tbi

[MatthiasS]

Der Baustein verbindet sich ja selbst wieder.

Ich gebe es bald auf, hört mir eigentlich einer mal zu?

Wenn der Baustein sich selbst wieder verbinden WÜRDE, könnte ich ja nwv. das SC bedienen. Fakt ist aber, dass sich die Verbindung verschluckt und nichts mehr geht. Und das passiert ohne die Anzeige irgendwelcher Reconnects oder so. Und zwar relativ kurz nach Neustart. Irgendwann ist einfach Feierabend und ohne Neustart des HS gibt es kein Verbindung mehr.

Der BS (2.20) baut die Verbindung selbst nicht neu auf, zumindest nicht als funktionierende Verbindung.

Ich mache heute abend mal die telnet-Aufzeichnung.

Den Reset habe ich nur mal probiert, wenn absolut nichts mehr ging.

[tbi]

Ich hör Dir ja zu, deshalb stelle ich ja die Fragen

Es ist eben nicht einfach, weil wir hier ein sehr komplexes System haben.

Das muß man eben einkreisen, bis man das Problem gefunden hat. Geht leider nicht anders.

Bisher sind wir ja immer davon ausgegangen, dass es nur die TCP-Verbindung ist, die wegbricht. Die alleine wird aber wieder aufgebaut und ist wieder da.

Was ich aber gestern herausgefunden habe ist, dass obwohl ja die TCP Verbindung ja neu aufgebaut wurde, der Squeeze Receiver nicht mehr über die Weboberfläche des SqueezeServers reagiert hat.

Also damit konnte ich zumindest schon mal so eine korrupte Verbindung nachstellen, wie Du sie vermutlich hast.

Und, man kann das im Telnet trace sehen, der Receiver macht selbst ein reconnect, kann sich aber anscheinend nicht mit dem SqueezeServer syncronisieren. Das heißt, obwohl ein funktionierende TCP Verbindung da ist, wird inhaltlich nicht mehr reagiert, weil der Receiver und der Server nicht mehr zueinander finden.

Das sieht schon sehr nach deinem Fehlerbild aus. Deshalb verspreche ich mir vom telnet trace einiges, weil ich es dort auch sehen konnte.

Siehst Du den Fortschritt So kommen wir der Ursache hoffentlich auf die Spur.

Gruß Tbi

[MatthiasS]

der Squeeze Receiver nicht mehr über die Weboberfläche des SqueezeServers reagiert hat.

Das ist bei mir aber nicht der Fall. Ich habe aus der alten Bedinung noch ein paar http-Aufrufe (also Webserver-Interface) zum Start von Playlisten. DAS funktioniert immer, auch die direkte Coveranzeige (ohne die URL vom 12299). Powerstatus, Lautstärke, Titel und Artist kommen eben vom Baustein, und das hängt dann urplötzlich.


P.S: War ja auch nicht bös gemeint, danke für deine Unterstützung!

[tbi]

Sehr interessant was Du schreibst.

Also der Squezzebox Baustein bekommt nur das mit, wo er sich mit Subscribe angemeldet hat.

Das Subscribe wird beim Neuaufbau der Verbindung neu vom Squeeze Baustein an den SqueezeServer geschickt.

Es könnte also gut sein, dass Du im Baustein die default Werte drin stehen hast, aber an dem Eingang ein iKO verbunden hast, was (später) leer ist. Da bist Du der HS Spezi.

Dann würde beim ersten Start des Bausteins noch das richtige "subscribe power, ..." stehen.

Wenn die Verbindung neu aufgebaut wird, ist aber das iKO leer. Dann steht da das nackerte "subscribe" und der SqueezeServer teilt nicht mehr mit was er macht.

Genau so hat sich übrigens Marlan (Marcel) auf Kreuz gelegt.

ALSO keine Verbindung mit iKO an diesem Eingang !!!!!!!!!!

PS: Was beim Subscribe gesendet wird sieht man genau im telnet trace.

Gruß Tbi

[MatthiasS]

Ich habe keine iKO, das Problem war mir bewusst.