[mmh] Applescript Schnittstelle fällt aus

[spookyt.]

Hallo,

mir ist jetzt schon zum 2. mal passiert, dass mmh nichts mehr über die applescript schnittstelle (tell application "myhgui"....) entgegen nimmt. Ziemlich blöd. Im Logging monitor läuft noch was (knx logs), also tot ist mmh nicht. Einmal stop und start und es läuft wieder.
Ich nutze 10.6.3 und mmh RC7 .

Debugging Tipps? Kann ich was machen, falls es wieder auftritt?

[meudenbach]

tritt das evtl. nach einem wakeUp auf??

Bitte auch die aktuelle Version 1.1 verwenden. Findest Du auf mremote.de unter downloads.

LG

[spookyt.]

nein, mein mac läuft durch.

Werde jetzt mal auf 1.1 updaten, aber wenn ihr seit RC7 da nichts verändert habt, dürfte sich das Problem dadurch ja nicht lösen.

[meudenbach]

natürlich lösen sich Probleme nach einem Update nicht von selbst. Ist bei der Recherche aber ungemein einfacher, wenn unser Versionsstand einheitlich ist.

Wenn der Zustand mal wieder eintritt wäre es evtl möglich, mir einen Zutritt zu den Mac herzustellen. Im Zweifel reicht auch ein Teamviewer...

m..myhome hat ansich nichts mit der AS Schnittstelle am Hut. Es wird lediglich der Aufruf initiert...

LG

[spookyt.]

Hi Mike,
ich habe gestern meinen Mini auf V1.1 und dann auch auf 10.6.3 geupdated. Heute morgen hab ich festgestellt, dass das Problem wieder aufgetreten ist (applescripts über myhgui werden nicht ausgeführt).

Andere AppleScripts auf dem Rechner laufen.
Was auch weiterhin vollständig funktioniert: über den scripting-client Befehle an mmh absetzen.

Das heißt mmh läuft also schon noch und nimmt lediglich keine AS mehr entgegen.
Die Buttonleiste ist komischerweise auch nicht da.

Der Log überden scripting client sagt:
<SYS>GETLICENSEINFO=0|10|Y|Y|Y|Y|Y|Y|OK</SYS>
(komischerweise musste ich mehrmals auf connect drücken, bis er die Verbindung gehalten hat)

Bist du heute in der Nähe eines Rechners (ansonten können wir das auch morgen machen)?

[spookyt.]

Applescript Schnittstelle fällt aus

So, ist wieder so weit. Schnittstelle hängt - aber Buttonleisten sind noch da.... Threads in myhgui = 9 im Moment. Hilft uns das jetzt weiter?

[meudenbach]

mmmh....

Das bedeutet, dass Problem liegt nicht an mmh. Meine Vermutung war ja, dass der MyHGui Deamon weg hängt. Tut er aber offensichtlich nicht.

Mail mir mal bitte Deinen gesamten Projektordner. Ich schaue mal, ob ich das nachstellen kann.

Frage: In welchen Zeitabständen greifst Du denn auf AS zu? Führen die Buttonleisten die Befehle aus?

Lg

[spookyt.]

Applescript Schnittstelle fällt aus

Hm, die buttonleisten werden angezeigt, führen aber keine Befehle mehr aus.

Ich habe in meinen macros zum teil zweimal direkt hintereinander den scriptaufruf tell app "myhgui" ... drin. Ich werde da jetzt mal eine 2 Sek. Pause zwischen legen. Könnte das helfen?
Hat der irtrans eig. ne interne Warteschleife? Wenn ich also mehrere befehle direkt hintereinander in einen befehlsaufruf stecke, werden die dann schön sequentiell abgearbeitet?

[no sleep]

Ich habe in meinen macros zum teil zweimal direkt hintereinander den scriptaufruf tell app "myhgui" ... drin. Ich werde da jetzt mal eine 2 Sek. Pause zwischen legen. Könnte das helfen?

Ja, das könnte helfen! Bitte baue mal eine Verzögerung ein, die grösser als die ungefähre "Ausführdauer" der 1. Kommandosequenz ist. Wenn das dann funktioniert weiß ich, wo ich ansetzen muß.

[spookyt.]

Applescript Schnittstelle fällt aus

Habe eben save and restart gedrückt. Da hat er dann plötzlich irtrans befehle ausgeführt, die noch irgendwo festhingen.

[no sleep]

Das passt zu meiner Vermutung...bitte mal wie oben beschrieben testen.

[spookyt.]

Wenn ich 5 mal den Befehlsaufruf direkt hintereiander packe

tell application "MyHGUI"
    Command "<IRTRANS><YAM_ON></IRTRANS>"
end tell

dann ist das Problem einigermaßen reproduzierbar. ABER nur mit dem o.g. Befehl. Nutze ich z.B. ENABLESS, dann wird sauber zwischengepuffert und abgearbeitet. Meines Erachtens hängt das also mit dem IRTRANS Commandserver zusammen. Ich habe zwischen die Befehle unterschiedliche Delays gepackt:

z.B.

ell application "MyHGUI"
    Command "<IRTRANS><YAM_ON></IRTRANS>"
end tell
delay (5)
tell application "MyHGUI"
    Command "<IRTRANS><YAM_ON></IRTRANS>"
end tell
delay (5)

Habe das ganze 100 mal untereinandergepackt und verschiedene Werte ausprobiert, aber ist auch bei 5 Sekunden Pause irgendwann hängen geblieben. Wenn man gleichzeitig die geöffneten Threads von myhgui anguckt, sieht man, dass er immer einen aufmacht für die Ausführung und den dann wieder schließt. Wenn er hängenbleibt, zählen den Threadcounter weiter hoch und dann ist Ende.
---
Nachtrag: Das Problem ist meines Erachtens geschwindigkeitsunabhängig.

Ich habe jetzt mal mit der Hand immer wieder das IRTRANS Skript angetriggert. Den Threadzähler geht dann von 2 auf 3 oder 4. ...nach ein paar Sekunden dann wieder zurück auf 2. Macht man das so 20 mal vielleicht (immer nachdem der Zähler wieder auf 2 runtergeangen ist), bleibt er bei >2 hängen (auch nach mehrsekündigem Warten) und dann kann man sicher sagen, dass der nächste Befehl nicht mehr ausgeführt wird.

Ich hoffe, das hilft beim Dubuggen.

[spookyt.]

stimmt leider nicht ganz, was ich geschrieben hab.

auch mehrfaches

tell application "MyHGUI"
    Command "<SYS><ENABLESS></SYS>"
end tell
delay (1)
tell application "MyHGUI"
    Command "<SYS><DISABLESS></SYS>"
end tell
delay (1)

führt dazu, dass er nach ein paar mal hängen bleibt...

[meudenbach]

*hochschieb*

hat sich das Thema nun eigentlich erledigt ??

[spookyt.]

Klares Jein :-)

Was schonmal positiv ist:
ich habs seit dem Update nicht mehr geschafft, die AS-Schnittstelle abzuschießen.

Was aber jetzt replizierbar gelingt:
Zuballern der Schnittstelle durch Hinternanderhängen von 20 Befehlsketten (ohne delay) mit dem o.g. IRTRANS Befehl und mehrfachem Auslösen meinerseits führen dazu, dass MYHServ bei einer hohen CPU Last hängen bleibt. Der Threadcounter von MyHServ bleibt bei 15 hängen und geht nicht auf 14 zurück.
Funktionsfähig ist mmh aber noch. Start/Stop im PrefPane löst das Problem dann wieder und setzt alles auf 0.
In wie weit das ein realistisches Anwendungsszario ist, sei mal dahin gestellt, aber auf jeden Fall ist irgendwas noch nicht ganz sauber.

Mit ENABLESS, also einem SYS Befehl, ist es mir NICHT mehr gelungen, die CPU Last dauerhaft zu erzeugen (es werden zwar mal eben 500 threads erzeugt, aber die sind dann nach ein paar Sekunden wieder "abgearbeitet" und dann offenbar auch sauber wieder weg->Threadcount: 14).


Um mal noch ein weiteres Fass aufzumachen:
Beim "schnellen" Absetzen von Befehlen über o.g. Befehlsketten (ohne delay), nur die ersten paar ausgeführt werden und der Rest verschluckt wird. Beispiel:

tell application "MyHGUI"
    Command "<SYS><ENABLESS></SYS>"
end tell
tell application "MyHGUI"
    Command "<SYS><DISABLESS></SYS>"
end tell
tell application "MyHGUI"
    Command "<SYS><ENABLESS></SYS>"
end tell
tell application "MyHGUI"
    Command "<SYS><DISABLESS></SYS>"
end tell

aktiviert den SS einmal und dann passiert nix mehr. Hänge ich noch mehr Befehle hintereinander, wird der SS manchmal auch wieder deaktiviert.

Ähnliches Verhalten übrigens bei

tell application "MyHGUI"
    Command "<SYS><ENABLESS><DISABLESS><ENABLESS><DISABLESS></SYS>"
end tell

BItte mal selbst ausprobieren.
Ich würde eigentlich erwarten, dass die Befehle solange in der Warteschlange hängen, bis sie nacheiandner ausgeführt werden können, sprich SS geht an, aus, an, aus.