mAirListScript: HTTPPost

StefanE · March 30, 2008, 10:50pm

Hi Torben und alle,

wenn ich das richtig sehe, gibt es bisher nicht die Möglichkeit, mit mAirListScript mit der HTTP-POST-Methode Argumente zu übertragen. Der HTTP-Server unseres RDS-Encoders lässt sich aber leider nur mit POST-Befehlen fernsteuern, nicht mit GET. Bisher lasse ich ein externes Programm aufrufen, das geht natürlich auch. Direkt aus dem Script wäre natürlich schöner

Meinst Du, Du könntest POST in mAirListScript ermöglichen?

Viele Grüße
Stefan

Torben · March 31, 2008, 6:06am

Klar, das geht sehr leicht. Kümmere ich mich drum.

Torben · April 7, 2008, 7:38pm

Ist inzwischen drin im aktuellen Snapshot.

    function HTTPPost(iURL: string; iData: string): string;

StefanE · April 7, 2008, 10:07pm

Hey!

Danke, Torben! Funktioniert super.

(War nur erst verwirrt, weil die GUI-Elemente weg waren, aber da bist Du wohl gerade am Basteln.)

Viele Grüße
Stefan

Torben · April 8, 2008, 6:07am

Hm? GUI-Elemente weg? Welche Version hattest du denn vorher? Guck mal ins Changelog:

Version 2.1.43 (2008-02-17)

[*] New “screen object” concept succeeding the former clock, date etc. objects.
See forum post for details.

Hier ist der erwähnte Thread: http://forum.mairlist.com/index.php/topic,2360.0.html

StefanE · April 8, 2008, 9:49pm

Mhh, eigentlich müsste ich 2.1.44 gehabt haben. Dachte ich. Na, egal.

Mir ist noch was anderes aufgefallen:

Wenn die URL nicht verfügbar ist, die in HTTPGet angegeben ist, dann bekomme ich folgendes:
[tt]
Socket Error # 10061
Connection refused.

Dienstag, 8. April 2008, 23:43:36

Program Version 2.1.44 Build 497

Call stack:

(002787CD) [006797CD]
(00275314) [00676314]
(00278172) [00679172]
(0037BD09) [0077CD09]
(0005649F) [0045749F]
(00056383) [00457383]
(0002E4D4) [0042F4D4]
(0008E9A8) [0048F9A8]
(0008E9E2) [0048F9E2]
(0008EC02) [0048FC02]
(004CCAE7) [008CDAE7] [/tt]

Beim neuen HTTPPost wird die Meldung “Socket Error # 10061” brav zurückgegeben, scheint also richtig zu funktionieren. Vielleicht muss Du da bei HTTPGet noch was abfangen oder so?

Viele Grüße
Stefan

Torben · April 9, 2008, 8:57am

Hm, eigentlich sollten alle Exceptions, die innerhalb des Scripts geworfen werden, als Fehlermeldung im System Log landen und niemals eine Fehler-Dialogbox erzeugen. Merkwürdig. Ich überprüf das mal.

StefanE · May 30, 2008, 12:37am

Hi Torben,

hab’s gerade mal gechecket, ob in der neuesten Version bzw. im neuesten Snapshot die Exception nun abgefangen wird: nein, geht noch immer nicht. Betrifft aber nur HTTPGet.

Bei der Gelegenheit: Du hast Dich im Cangelog vertan:

[+] Scripting: New function function HTTPGet(iURL: string; iData: string): string

Das muss HTTPPost heißen.

Und damit wäre ich dann auch beim eigentlichen Thema:
Könntest Du vielleicht auch HTTPPostAsync implementieren? Wenn der entfernte RDS-Server nicht erreichbar ist, friert mAirList immer ein, das ist unschön.

Warum kannst Du eigentlich die Skripte nicht generell in einem separaten Thread laufen lassen? Ebenso wie die DB-Suche (hatte ich vor geraumer Zeit mal angemerkt). Das würde doch die Betriebssicherheit erhöhen, wenn Player und Playliste nicht auf die Suche oder Skripte warten müssten.

Viele Grüße
Stefan

Torben · May 30, 2008, 6:10am

Stimmt, danke.

Könntest Du vielleicht auch HTTPPostAsync implementieren? Wenn der entfernte RDS-Server nicht erreichbar ist, friert mAirList immer ein, das ist unschön.

Ab mAirList 3.0 wird es auch HTTPPostAsync geben. (Dort war das, ander als bei v2.1, aufgrund einer veränderten Architektur leichter zu implementieren.)

Warum kannst Du eigentlich die Skripte nicht generell in einem separaten Thread laufen lassen?

Weil der Rest von mAirList (Playlisten, Kontrollklassen, …) nicht thread-safe ist. Das heißt also, wenn das Script in einem eigenen Thread läuft und auf die Playlist zugreift, dann könnte es sich mit der GUI ins Gehege kommen. Die daraus resultierenden Abstürze fördern dann eben nicht die Betriebssicherheit

So richtig zufrieden bin ich mit dem Zustand auch nicht. Kurzfristig werde ich aber nichts daran ändern können.

Torben

StefanE · June 9, 2008, 5:39pm

Hi Torben,

dann bin ich schon gespannt auf mAirList 3.0.

Dennoch: Zur Fehlerbeseitigung in 2.1.45 (habe extra den aktuellen Snapshot 512 runtergeladen):

Ich kämpfe immer noch mit einem Socket Error. Weiter oben in diesem Thread hatte ich geschrieben, dass der nur bei HTTPGet auftritt. Das stimmt gar nicht, wie ich jetzt merke. Es betrifft auch HTTPPost. Dabei verhält sich das ganze sehr merkwürdig. Das ganze ist natürlich immer nur dann ein Problem, wenn der Server, den ich ansprechen will, gerade nicht erreichbar ist.

An einer Stelle im Script sende ich per HTTPPost Daten an den Server. Falls er nicht erreichbar ist, erscheint das nur als Fehlermeldung im System Log, wird also offenbar abgefangen. (Siehe Anhang)

procedure SendeAnRdsEncoder (Befehl: String); begin Befehl := Befehl + '&_send=Send'; SystemLog('Sende -> RDS-Encoder: ' + Befehl); SystemLog(RdsStatusKlartext(HTTPPost(RdsServer,Befehl))); end;

An einer zweiten Stelle im Script (procedure OnTimer) frage ich einfach nur den Server ab und übermittle irgendwas oder einfach gar keine Parameter über HTTPPost. Hier gibt es einen Socket Error, der nicht abgefangen wird und der so lange besteht, bis der Server erreichbar ist.
(Verwende extra HTTPPost statt Get an dieser Stelle, weil ich dachte, dass nur bei HTTPGet der Fehler auftritt.)

procedure OnTimer; begin SystemLog(RdsStatusKlartext(HTTPPost(RdsServer,''))); end;

[code]Socket Error # 10061
Connection refused.

Montag, 9. Juni 2008, 19:26:03

Program Version 2.1.45 Build 512

Call stack:

[0067A235]
[00676D7C]
[00679BDA]
[0077D70D]
[0045748F]
[00457373]
[0042F4C4]
[0048F998]
[0048F9D2]
[0048FBF2]
[008CCAD3]
[/code]

Das ist extrem unschön.

Unser Anwendungsfall: Am Senderstandort läuft ein Server, der den RDS-Encoder steuert. Wenn nun nachts um 4 Uhr für eine kurze Zeit wegen der Zwangstrennung der DSL-Verbindung der Server nicht erreichbar ist, dann schmiert mAirList ab.

Könntest Du da noch mal bitte ein Auge draufwerfen?

Viele Grüße
Stefan

Torben · June 10, 2008, 6:32am

Wenn deine Programmiererseele bei diesen Sätzen weint, dann wirst du auch wissen, dass Threadprogrammierung eine anspruchsvolle Sache ist, insbesondere, wenn es darum geht, ein Programm nachträglich mit Threads zu versehen. Als ich 2000 (oder war es 2001?) mit der Programmierung von mAirList begann, habe ich mir wenig Gedanken um das Thema gemacht und hatte auch so gut wie keine Ahnung davon. Und mal ehrlich: Eigentlich funktioniert es doch zur Zeit gar nicht so schlecht. Insbesondere ist es ja so, dass die BASS.DLL von sich aus ihren eigenen Thread aufmacht. Die Audio-Wiedergabe geht also immer weiter, auch wenn mAirList selbst gerade irgendwas anderes macht.

Das Problem fängt schon damit an, dass die VCL (also die GUI-Komponenten von Delphi) nicht threadsafe ist. Die einzig sinnvolle Aufteilung wäre es also, der GUI ihren eigenen Thread zu geben (den VCL-Main-Thread, wie der Delphi-Programmierer sagt), und bestimmte Kontrollklassen oder gar die gesamte “Engine” in Nebenthread zu verschieben. Dabei entstehen aber sehr viele Synchronisierungs-Probleme. Insbesondere müssen alle Benachrichtigungen der Kontrollklassen erst in den Main-Thread übertragen werden, was bei der Vielzahl der Parameter nicht so leicht ist.

Du merkst, ich erkenne schon die Vorteile, und mir ist auch daran gelegen, das irgendwann hinzukriegen. Auf Platz 1 der Prioritätenliste stehen aber zur Zeit andere Dinge.