Modul für ONKYO AV Receiver (und neuere Pioneer AV Receiver)

[urmel86]

Klasse wir heute abend gleich getestet wenn ich zu Hause bin

Gesendet von meinem HUAWEI U9508 mit Tapatalk-4

[Jaydee]

Stürzt zumindest nach einem reload nicht ab. Weitere Tests folgen...

[urmel86]

Soweit ich das jetzt testen konnte, ohne Ärger mit der Kurzen zu bekommen, funktioniert alles. 

Werde später noch die Inputs durchgehen um sicher zu sein dass alles läuft.

Edit:

So konnte jetzt ein wenig testen. Bis auf die Net Befehle die mich ins DLNA Menü bringen, funktioniert schon mal wieder alles. An den Inputs die bei meinem Gerät ins DLNA Menü verweisen verschluckt er sich bei mir wieder so dass dann FHEM komplett still steht. Schalte ich das Gerät dann mit der normalen Fernbedienung um läuft alles wieder rund.

Ich vermute dass er in dem Moment versucht die kompletten Bibliotheken meines XBMC Mediacenters einzulesen. Und das ist dann schon ne Menge

Ansonsten ist mir noch aufgefallen dass in der Raumübersicht die Mutefunktion bei mir nicht funktioniert. Also in der Leiste die den ON OFF Zustand, den Lautstärkeregler, Mute und die Auswahl der Inputs zeigt meine ich. Wenn ich das Gerät öffne klappt es.

Sonst geht alles einwandfrei ich konnte bisher keine anderen Fehler oder Ausfälle entdecken. Danke dafür!

[Jaydee]

bei mir gibt es leider noch immer unregelmäßige Abstürze. Mal nach 10 Minuten, mal nach ner Stunde.
Anbei der Log-Auszug zum Zeitpunkt des Absturzes von FHEM. Dort wo die Zeilen plötzlich länger werden, stürzt er ab und alles steht.
als ich um 21:40:00 Fhem bzw. Perl abgeschossen habe, kam dann noch der Rest ins Log nach...

Ich hoffe, dies hilft bei der Fehlersuche.

Jan

[Joachim]

Moin Jaydee,

da ich mit einer ganz anderen Konstellation auch in unregelmäßigen Abständen hänger und oder Abstürze hatte, habe ich mir einen Alivedummy gebaut

Code Auswählen Erweitern


define alive dummy
attr alive room Alive
attr alive setList 0 1
define at_alive at +*00:01:00 {if ("$value{alive}" == 0) {fhem("set alive 1")} else {fhem("set alive 0")}}
attr at_alive room Alive
define Log_alive FileLog ./log/alive-%Y-%m-%d.log alive.*
attr Log_alive room Alive
define SVG_Log_alive_1 SVG Log_alive:SVG_Log_alive_1:CURRENT
attr SVG_Log_alive_1 room Alive

vielleicht hilft er Dir beim Eingrenzen des Fehlers.
Bei mir habe ich Netzwerkprobleme in Verdacht, aber noch nicht verifiziert.
dafür hilft Dir ggf. Wireshark.

Gruß Joachim

[Jaydee]

danke Joachim, aber diese Art des Absturzes kann ich ziemlich klar auf das ONKYO_AVR-Modul zurückführen. Wenn ich das rauswerfe, habe ich keine Probleme mehr.

Jan

[Joachim]

Das dachte ich bei mir auch, allerdings nachdem ich mein gesamtes FHEM ein ein seperates Subnetz verbannt habe ist der Fehler weg.
Zumindest bei mir spielen noch andere Faktoren rein, die ich bisher noch nicht finden konnte, aber sicher ist, es hängt mit einem stark belasteten Netzwerk zusammen.

Gruß Joachim

[Loredo]

Meine Vermutung geht in eine ähnliche Richtung.


Ich kann nur nochmals betonen den ganzen DLNA Kram nicht zu benutzen
Oder alternativ muss man sich wohl einen stärkeren Server für FHEM hinstellen, der in der Lage ist die ganzen Informationen (schneller) zu verarbeiten. Ob das zielführend ist, muss jeder selbst entscheiden.


Das dem Log oben ist jedenfalls nicht ersichtlich, weshalb ein Absturz passiert.


Gruß
Julian

[Loredo]

So konnte jetzt ein wenig testen. Bis auf die Net Befehle die mich ins DLNA Menü bringen, funktioniert schon mal wieder alles. An den Inputs die bei meinem Gerät ins DLNA Menü verweisen verschluckt er sich bei mir wieder so dass dann FHEM komplett still steht. Schalte ich das Gerät dann mit der normalen Fernbedienung um läuft alles wieder rund.

Ich vermute dass er in dem Moment versucht die kompletten Bibliotheken meines XBMC Mediacenters einzulesen. Und das ist dann schon ne Menge

Sehr wahrscheinlich ist das so. Auf spezifische Anfragen sendet der Receiver erstmal gerne alle Infos zum aktuell laufenden "Programm", die man ihn gar nicht gefragt hat. Je nachdem ob er Lust hat kommt dann irgendwann mal die Antwort auf das, was man eigentlich wissen wollte. Es wird eine ganze Zeit lang gewartet und während dieser Zeit kann FHEM nichts anderes tun. Das ist allerdings dem FHEM Konzept geschuldet, dass Aktionen nicht (gut) parallelisiert werden können. Ich glaube Rudi arbeitet daran.

Ansonsten ist mir noch aufgefallen dass in der Raumübersicht die Mutefunktion bei mir nicht funktioniert. Also in der Leiste die den ON OFF Zustand, den Lautstärkeregler, Mute und die Auswahl der Inputs zeigt meine ich. Wenn ich das Gerät öffne klappt es.

Das ist ebenfalls ein FHEM Bug, den ich hier schon adressiert habe.

[Loredo]

Ich habe aktuell keine Zeit dafür, aber vielleicht jemand von euch:


Kann mal jemand den verwendeten Arbeitsspeicher über einen gewissen Zeitraum mitprotokollieren?
Ich habe den Verdacht, dass FHEM tatsächlich auch irgendwann abstürzt, weil der Arbeitsspeicher voll läuft wenn vom Receiver wiederholt so viele Informationen zurück gesendet werden. Ich bin da leider nicht der Perl Experte und weiß nicht, ob FHEM bereits Routinen zur Garbage Collection implementiert hat. Soweit ich es in 1min ergoogeln konnte ist das wohl in Perl auch relativ schwierig. Einmal zugewiesener Speicher wird wohl nicht wieder freigegeben und irgendwann haben eure Receiver so viel Daten übertragen, dass dann wohl irgendwo ein Pufferüberlauf zum Absturz führt...


Diesen Verdacht kann man vermutlich über das Beobachten des Speicherverbrauchs schonmal etwas besser nachvollziehen.

[urmel86]

Werde ich heute Abend versuchen

[urmel86]

Also ich kann bei mir keinen Speicherüberlauf feststellen. Die Anzeige für den genutzten  Speicher regt sich überhaupt nicht. Nur die Prozessorlast geht minimal hoch.

[Loredo]

Ja, hab mich auch dran erinnert "sar" installiert zu haben und mal in meine Historie geschaut - gleiches Bild.


Kann aber zumindest sagen, dass sich FHEM auch bei mir nach einigen Stunden aufhängt. Ich weiß aber leider gar nicht wo ich da ansetzen soll, es fehlt ja irgendwie mal ein Grund, warum der FHEM Prozess nicht mehr reagiert

[urmel86]

Im Moment fehlt auch mir leider etwas die Zeit um richtig zu gucken wann genau er sich weghängt. Ich glaube auch gar nicht dass FHEM sich weghängt. Meine Vermutung ist dass einfach der Netzwerkverkehr plötzlich so hoch geht dass die Befehle nicht mehr ankommen. Muss dass vielleicht mit Wireshark mal überprüfen.

[Jaydee]

Also alles andere läuft bei mir auf dem Pi fröhlich weiter - auch die Sachen, die auf die Netzwerkverbindung angewiesen sind, wie SSH-Verbindung...