[gelöst][XBMC] Potenzieller Fehler im Attribut 'fork'

[gelb]

In Bezug auf http://forum.fhem.de/index.php/topic,18915.0.html hier der extra Thread dazu.

Kurze Zusammenfassung: Es steht die Frage im Raum, warum mein FHEM Server stoppt, wenn ich im XBMC Device das Attribut 'fork' auf 'enabled' setze und dann meine fhem.cfg über das Webinterface speichere.


Mein XBMC Device:

Code Auswählen Erweitern


#######################################################################
######################## XBMC #########################################
#######################################################################

define HTPC XBMC 192.168.0.34 tcp
attr HTPC devStateIcon opened:rc_GREEN:on disconnected:rc_RED:off Initialized:message_socket_disabled
attr HTPC fp_Wohnung 524,1015,1,
attr HTPC group Ping
attr HTPC icon it_pc
attr HTPC offMode shutdown
attr HTPC room 1.4_Wohnzimmer
#attr HTPC fork enable


[justme1968]

wenn du mit speichern ein editieren des config files und anschliessendem rereadcfg meinst dann liegt es daran das der geforkte prozess beim neustarten unter anderem den telnet port blockiert und fhem deswegen nicht startet.

ein einfaches fork verträgt sich nicht mit rereadcfg. da rereadcfg noch mehr nachteile hat und keinen wirklichen vorteil sollte man es nicht benutzen. es ist besser die devices einzeln zu modifzierien und nur per 'save' zu speichern. vergiss einfach das es ein config file gibt das man editieren kann.

wenn möglich sollte statt fork BlockingCall verwendet werden. das vermeidet die meisten nachteile und es sollten un der UndefFn die gestarteten prozesse beendet werden.

gruss
  andre

[dennisb]

Moin zusammen,

also ich konnte den Fehler reproduzieren und hab andres Rat direkt mal befolgt und den gestarteten Prozess in der UndefFn gekillt. Danach ist FHEM bei mir nicht mehr abgestürzt.

@gelb: die angepasste 70_XBMC.pm ist im Anhang. Bitte teste mal, ob's auch bei dir damit funktioniert.

@andre: danke, dass du den Fehler direkt lokalisiert hast. Mein bisheriger Ansatz war es, dass der neue Prozess Selbstmord begeht, wenn der Hauptprozess nicht mehr erreichbar ist. Im Falle das rereadcfg hat das natürlich nicht funktioniert... Ist mir allerdings nie aufgefallen. Werde auf Blocking.pm umstellen, alleine schon um HTTP-Polling vernünftig umsetzen zu können. Als ich damals das Modul geschrieben hab, hab ich die Blocking.pm übersehen oder sie existierte in der bisherigen Form noch nicht (zumindest nicht was die Doku angeht). Daher hatte ich mir meinen eigenen Ansatz gebaut, der eigentlich auch ganz brauchbar funktioniert hat (abgesehen von dem Fehler jetzt )

[gelb]

Funktioniert leider nicht. Im Logfile steht:

Code Auswählen Erweitern


2014.01.19 14:19:48 1: telnetPort: Can't open server port at 7072: Die Adresse wird bereits verwendet. Exiting.


Könnte das damit zu tun haben?

[dennisb]

Argh... bin aber auch ein Held. Hab die falsche Version hochgeladen...
bitte nochmal mit der angehangenen Datei testen. Sorry...

[gelb]

Super! Klappt 

[dennisb]

Wunderbar. Wäre das auch geklärt. Committe gleich das angepasste Modul.

[justme1968]

@dennis: für das http pollen ist vielleicht auch das hier eine option: http://forum.fhem.de/index.php/topic,17804.msg119720.html#msg119720.

gruss
  andre

[dennisb]

Hi,

danke für den Hinweis! Schaut gut aus. Als ich mit dem Modul angefangen hab, musste ich eine angepasste Version der CustomGetFileFromURL erstellen, weil ich einen anderen MimeType und HTTP-Auth brauchte. Mittlerweile is das ja alles vorhanden. Werde mal umstellen
Dann is HTTP-Polling nur noch einen Timer entfernt

Gruß
Dennis