Sonos steuern

Begonnen von Will, 05 Januar 2013, 15:51:12

Vorheriges Thema - Nächstes Thema

strauch

Hallo Reinerlein,

bis vor kurzem hätte ich ja sagen können. Aber seit 2 Wochen läuft FHEM bei mir in einer VM auf einem MacMini (ESXi). FHEM bleibt bei 100% hängen und immer mit der Kill Meldung. Ich vermute das es Sonos mit irgendwas in Kombination ist. Aber so richtig auf eine zündende Idee was es sein könnte bin ich nicht gekommen.
Ich hab dir die Protokolle der letzten 4 Abstürze maldrangehangen, of dauert das auch keine 5min. Letzte mal lief er dann aber auch einige Zeit wie man ja am Abstand zwischen meinen Beiträgen sieht.

Kannst du in dem Kill Prozess irgendwie sonst ein Timeout einbauen das er sich da nicht aufhängen kann.... oder kann ich den Prozess forken? Das muss ich mir malanschauen.

Grüße

strauch
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Reinerlein

Hi Strauch,

das mit der Meldung bzgl. "Signal CHLD" stimmt mich skeptisch. Das könnte das eigentliche Problem sein...
Zur Erklärung:
Das verwendete UPnP-Modul meldet unter Unix (und dessen Derivaten) ab und zu einen Stream-Abbruch, wenn die Verbindung zum Client verloren geht (unter Windows nicht). Das wird über ein Signal CHLD gemacht. Das Default-Verhalten ist dann, den Prozess zu beenden (das Signal wurde für die Verarbeitung von Pipe-Ketten erdacht, damit diese auch durchgehend und komplett beendet werden können. SIGPIPE wird beim ersten Prozess aufgerufen, SIGCHLD bei allen anderen).

Hier ist das aber unerwünscht, da diese Stream-Unterbrechung normal zu sein scheint. Wenn dieses Signal jetzt nicht ignoriert werden kann, wird das Modul bei jeder Kommunikationsunterbrechung zu den Playern beendet werden (bzw. den Versuch unternehmen).
Das dürfte der Grund sein, warum überhaupt ein Prozess (oder der Thread) beendet werden soll. U.U. kommt das so schnell, dass die Threads noch gar nicht sauber eingerichtet wurden.

Was ich machen kann, ist, die Thread-Beendigung sicherer zu machen.

Dazu kannst du bei dir mal bitte die Sub-Definition für Signal 'INT' (um die Zeile 5006 herum) auf folgendes anpassen:
$SIG{'INT'} = sub {
# Hauptschleife beenden
$SONOS_Client_NormalQueueWorking = 0;
$runEndlessLoop = 0;

# Sub-Threads beenden, sofern vorhanden
if (($SONOS_Thread != -1) && defined(threads->object($SONOS_Thread))) {
threads->object($SONOS_Thread)->kill('INT')->detach();
}
if (($SONOS_Thread_IsAlive != -1) && defined(threads->object($SONOS_Thread_IsAlive))) {
threads->object($SONOS_Thread_IsAlive)->kill('INT')->detach();
}
if (($SONOS_Thread_PlayerRestore != -1) && defined(threads->object($SONOS_Thread_PlayerRestore))) {
threads->object($SONOS_Thread_PlayerRestore)->kill('INT')->detach();
}
};

Damit sollte es nicht mehr zu einem Fehler bzgl. dieses undefined Values kommen.

Die Ursache wird dadurch aber nicht behoben, die dürfte meiner Vermutung nach in dieser Signal-CHLD-Geschichte liegen. Kannst du da mal bzgl. deiner aktuellen Mac-VM-Umgebung Googeln, ob man das irgendwie konfigurieren kann, dass man dieses Sig-CHLD wieder definieren darf?

Grüße
Reiner

strauch

Hallo Reinerlein,

danke für die Infos, ich werde das mal testen und mich mal schlau machen, was das chld angeht. Wichtig ist auf dem Mac läuft keinerlei MacOS X, da läuft direkt ein ESXI Server drauf auf dem die VMs aufgesetzt sind. In der VM läuft ein Debian 7. Aber ich lese mich da mal etwas ein, bin da sehr unbescholten.

Grüße

strauch
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Reinerlein

Hi strauch,

hmmm... vielleicht liegt es auch an der verwendeten Perl-Distribution (gibt es da überhaupt verschiedene?). Debian ist ja eigentlich kein Problem. Das läuft auf den meisten Raspberries ja auch...

Leider kenne ich mich da auch wenig aus...

Grüße
Reinerlein

strauch

Also die Perl Version ist
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-gnu-thread-multi
(with 88 registered patches, see perl -V for more detail)


Ich kann auch gleich noch mal Updates einspielen. Ich teste jetzt mal deinen Vorschlag. Wobei das die aktuelle Version für Debian 7 ist wenn ich das richtig sehe.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

strauch

#1115
Puh ich finde dazu so gut wie nichts im Internet, hab nur das hier gefunden:
http://www.perlmonks.org/?node_id=1047688
http://de.comp.lang.perl.misc.narkive.com/dKswsjoa/can-t-ignore-signal-chld

Aber keine Ahnung ob das das Modul überhaupt betrifft..... aber ganz nach... denn sie wissen nicht was sie tun, teste ich einfach mal
$SIG{HUP} = 'IGNORE';... hoffentlich liest das nicht betateilchen, das gibt dann immer (zurecht) ärger.

Edit: bringt auch nichts
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Reinerlein

Hi strauch,

was hat denn das Anpassen des Signal-Handlers mit dem Codebeispiel ergeben?
Vielleicht wird dieses Ignorieren ja doch gar kein Problem...

Ich kann auch mal experimentieren, wenn ich das weglasse. Es kann nämlich sein, dass es bei den Sub-Prozessen nicht notwendig ist, sondern nur beim Hauptprozess...

Grüße
Reinerlein

strauch

Aktuell läuft alles..... aber das ist grad auch totaler Blindflug meinerseits. Ich hab
$SIG{HUP} = 'IGNORE';

eingetragen und jetzt einfach mal schauen was passiert. Die CHLD Meldung kam trotzdem aber bisher kein Absturz.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

michaelfhem

Hallo zusammen,

erstmal  Danke für dieses Megacoole Modul!!!. Damit wird fhem deutlich aufgewertet. Ich habe mir gestern den Play1 zugelegt und alles installiert. Im Prinzip funktioniert alles (Textausgabe und auch abspielen von mp3, Lautstärke einstellen, in Fhem werde alle Readings angezeigt, etc). Allerdings nur sporadisch. Nach einer unbestimmten Zeit (eher minuten) geht keine Textansagae mehr und auch das abspielen von mp3 nicht mehr. Der fhem Prozess braucht dann meist 100% CPU. fhem lässt sich dann auch nicht mit sudo kill abschiessen, es hilft nur reboot. Ich habe schon einiges gelesen hier im Thread (zuminndest bis Seite 50).

Meine Daten: Play 1, Debian Linux Server (auf einem EEE-PC), fhem 5.5 (update force), apt-get update + upgrade gemacht 
update thirdparty http://fhem.lmsoft.de/sonos_dev sonos  sagt nothing todo ? (im 00_SONOS steht Version 2.5)
Die Softwarerevission von SonosPlayer ist 5.1.

Bin ich auf der aktuellsten Version, bzw. woran kann ich es erkennen?

Grüße Michi
raspberry Pi 3 + jessie + fhem
Devices: Fritz Dect 200, Homematic (HMLan-Gateway), FS20 (CUL-Stick), Hue-Gateay, Sonos

Reinerlein

Hi Michi,

also die aktuellste Version hast du... Ich habe hier intern nur ein paar Entwicklungen, die leider (immer) noch nicht ganz fertig sind...

Bitte sende/poste mal die Logausgabe des Sub-Threads. Im Wiki gibt es dazu ein paar Sätze.
Vielleicht kann man da was erkennen, was die letzte Ausgabe ist, und an was er so hängen bleibt.

Mehrere Minuten (vielleicht genau 2?) klingt danach, dass Fhem nicht als Root läuft, und der IsAlive-Checker kein Ping absetzen kann/darf...

Zum Kill: Probier mal folgendes:

sudo kill -9 <PID>

Damit sollte auch dieser Prozess sterben. Kill ist ein Kommando, welches ein Signal an den angegebenen Prozess sendet. Dieses Signal kann ausgewertet werden, um ein saubers Beenden der Applikation zu gewährleisten.
Wenn der Prozess aber "hängt", kann das Signal vielleicht nicht mehr verarbeitet werden.
Dann hilft der Parameter "-9", der dem Vater-Prozess sagt: "Schiess das Ding jetzt einfach ab!"

Damit sollte ein Reboot verhindert werden können. Beachte aber, dass es u.U. mehrere Fhem-Perl-Prozesse gibt, da das Sonos-Modul in einem eigenen läuft, und entsprechend extra abgeschossen werden muss...

Grüße
Reiner

strauch

@michaelfhem, das klingt nach einem ähnlichen Problem wie ich das habe. Bin mal auf deine Logfiles gespannt ob die ähnliches ausspucken wie bei mir und es vielleicht wirklich das gleiche Problem sein könnte.
Aktuell läuft aber alles bei mir. Da mir gerade die Zeit fehlt hab ich bisher die Finger von FHEM gelassen. In meinem Urlaub mitte nächster Woche, werde ich mal wieder ein FHEM Update machen und schauen ob er dann wieder los spinnt oder durchläuft und dann werde ich auch eher wissen was meine Zeile da oben gebracht hat.
FHEM 5.6 VMware mit Debian. 1 CUL für FS20 und HMLAN für Homematic, HM-CC-RT-DN, HM-LC_Sw1PBU-FM, HM-LC-Bl1PBU-FM,  HM-SEC-SC, HM-SEC-SC-2, HM-LC-Sw1-Pl2, HM-Sec-RHS, ASH2200, FHT80B, S20KSE, Sonos, XBMC, FB_Callmonitor, SMLUSB, Arduino Firmata, uvm.

Laffer72

Hallo,

vielen Dank für das super-Modul. Soweit funktioniert auch alles, Textansage, Steuerung.... Allerding ahbe ich ein kleines "Schönheitsproblem": Beim Abspielen von Simfy-Titeln (also Streaming) habe ich keine Cover-Anzeige. Sonos selbst hat eine Anzeige.
Gibt es da eine Möglichkeit etwas einzustellen? Oder liefert Sonos das Cover da in einem falschen Format ab?

Danke
Reinhard
Raspberry Pi Rev.B, FB7390 (FHEM2FHEM), Sonos, Smarter Coffee
Osram Lightify:2m LED-Streifen, 5m-LED-Streifen, Gartenspot, Surface 28W, Classic E14,E27, Classic RGBW E27, PAR16 GU10, Plug
CUL868:FS20-ST, FS20-DI, FS20-FMS, FS20-ES1
HMUSB:HM-Sec-RHS,HM-Sec-MDIR2
Jeelink868:TX-29-IT, TFA30.315

Reinerlein

Hi Reinhard,

das sollte kein Problem sein. Leider liefert der SonosPlayer nicht immer einen sauberen Mimetype für die Cover mit. Diesen muss man dann fest setzen.
Kannst du mir mal bitte das komplette Reading "currentTrackURI" zusenden, und auf dem Rechner, auf dem Fhem läuft, in dem Verzeichnis "www/images/default/SONOSPLAYER/" nachschauen? Dort werden alle Cover-Bilder heruntergeladen. Dort sollte dann auch das von deiner gewünschten Zone liegen (vermutlich mit der Endung "ERROR").
Dieses bitte auch mitsenden, oder reinschauen, welcher Dateityp wirklich drinsteckt.

Dann verdrahte ich das auch fest für Simfy...

Grüße
Reiner

michaelfhem

Hi Reiner,

ich warte seit gestern auf den nächsten Absturz, aber er kommt nicht. Seit meinem Post gestern läuft alles stabil?
Ergänzung: fhem läuft nicht als root, als sync habe ich "syn" eingestellt.

Falls ich doch auf root umstelle: bei mir gibt es kein fhem-startscript unter /etc/init.d/ wo kann das noch bei debian liegen?

Grüße Michi
raspberry Pi 3 + jessie + fhem
Devices: Fritz Dect 200, Homematic (HMLan-Gateway), FS20 (CUL-Stick), Hue-Gateay, Sonos

Laffer72

Hallo Reiner,

anbei die Datei des Covers.
Die currentTrackUri ist "x-sonos-http:track%3a37359658.mp3?sid=28&amp;flags=32&amp;sn=1"

Hoffe das hilft Dir weiter.

Falls Du noch was brauchst, einfach Bescheid geben.

Danke schonmal,

Reinhard



Raspberry Pi Rev.B, FB7390 (FHEM2FHEM), Sonos, Smarter Coffee
Osram Lightify:2m LED-Streifen, 5m-LED-Streifen, Gartenspot, Surface 28W, Classic E14,E27, Classic RGBW E27, PAR16 GU10, Plug
CUL868:FS20-ST, FS20-DI, FS20-FMS, FS20-ES1
HMUSB:HM-Sec-RHS,HM-Sec-MDIR2
Jeelink868:TX-29-IT, TFA30.315