Freeze zum ersten Release

[Buebchen]

Hallo zusammen,

ich wollte nur kurz nochmal bestätigen, daß ich nun gerne einen ersten Release des monitord 2.0 fertigstellen möchte.

Basierend auf der monitord-webseite sind das die für 2.0 vorgesehen Funktionen:

* Hohe Stabilität des Programms auch bei langer Laufzeit [fertig]
* Sicher und fehlertolerant funktionierende Auswerter [fertig - aber verbesserungsfähig]
* Ausgabe der empfangenen Daten auf Sockets in drei Protokollen [fertig]
* Speicherung der Daten in einer MySQL-Datenbank (via Plugin) [fertig]
* Kurzzeitige Funkaufzeichnung durch den Server als MP3-Datei auf Anforderung des Clients (via Plugin, nur im monitord-Protokoll enthalten) [fertig]

Diese Elemente sind soweit alle drin. Handlungsbedarf ist m.E. jetzt erstmal

a) die Buildumgebung nun "hoffähig" zu machen (cwh hat mir da z.T. schon patches zugesendet)
b) die Sichere und fehlertolerante Auswertung nochmal zu überarbeiten (wobei das sicherlich ein weiter fortlaufender Prozeß ist)
c) die MP3 Aufnahme möchte ich durch sox ergänzen. Zumindest unter linux um Probleme mit dem MP3 Patent zu umgehen.
d) Die fehlenden Dateien wie "Readme, Install, Authors, ..." ergänzen
e) Eine Dokumentation zur Erstellung und Konfiguration

Das bts werde ich nochmal überarbeiten und ggf. Wünsche etc. auf Version 2.1 stellen.

Wer also noch Fehler/Beträge etc hat bitte hier posten !

[Omega1977]

Ich nutze Monitord in Verbindung mit FMS32Pro, soweit klappt alles wunderbar, aber ich habe das Problem wenn Buchstaben in der FMS-Kennung enthalten sind werden diese vom Monitord oft als kleine Buchstaben an FMS32 weitergegeben, was dies natürlich dann nicht korrekt zuordnen kann.

Beispiel: Fahrzeug mit Kennung 123491A4 ist im FMS32 als 91-01 XY-Dorf hinterlegt, Monitord wertet die Kennung als 123491a4 aus und damit erscheint ein unbekanntes Fahrzeug.

Gibts dazu eine Lösung???

[Buebchen]

Das ist natürlich lösbar. Ich muss jetzt nur noch schauen, ob wir das in der Protokolldefinition schon irgendwo festgelegt haben. Wenn es bisher nicht definiert war kann ich das im Auswertermodul selbst schon in Großbuchstaben umwandeln. Dann bekommen alle Clients die Kennung in Großbuchstaben (den Status würde ich dann auch direkt mitändern).

Muss nur jemand testen, ob der crusader damit klar kommt. Sonst muss ich das umwandeln im fms32 Socket machen. Wäre genauso möglich.

[Omega1977]

....wäre natürlich super wenn man es direkt in Monitord-Programm integrieren könnte, denn ich bin sicher nicht der einzige mit diesem Problem...

Danke !!!

[cwh]

Hi.

Hätte da noch ein paar kosmetische Änderungsvorschläge:

libjthread:
Dessen Soucecode aus dem monitord-SVN und damit dem Sourcetarball rausnehmen. Stattdessen die im System vorhandene libjthread verwenden.
Ich hab das bei mir lokal schon gemacht, ich müßte es nur noch committen. Ich weiß nicht ob Dir das aber evtl. Probleme beim bauen unter Deiner Windowsinstallation bringt.
Für openSUSE hab ich schon ein libjthread RPM gebaut.

Logging:
Die ersten paar Zeilen Log gehen immer nach STDERR und nicht ins Logfile. Das ist manchmal etwas nervig, insbesondere wenn man es beim booten mit init startet. Sollte alles ins konfigurierte Logfile gehen.

[Nachträgliche Ergänzung meines Posts:]
Protokoll:
Um rauszufinden, ob man sich mein Client einloggen muß setze ich bisher einen Keepalive ab. Evtl wäre es aber schick, wenn der Server nach dem Verbindungsaufbau einfach mal einen "Not logged in" error schicken würde, wenn er einen Login benötigt.
Bei mir, übrigens, liefert ein Inquiry eine leere Liste geladener Plugins obwohl audiorecorder und mysql geladen sind. Könnt ein Bug sein.

Die Protokolldokumentation könnte der Besitzer man übrigens vielleicht mal ins SVN einchecken.

Ich finde das Kommunikationsprotokoll übrigens ein bisschen eigenartig, aber dazu starte ich vielleicht mal später einen eigenen Thread.

Config:
Die Beispielconfig ist kein valides XML, fixe ich gerne, wird aber einen dicken diff geben.
Die Plugins sollte man einfacher Einbinden können. Anstatt des vollen Dateinamens mit Pfad vielleicht nur den Namen - Pfad und Dateiendung könnte man beim Laden ergänzen.

Grüße,
Christopher

[dekarl]

Tag,

libjthread:
Dessen Soucecode aus dem monitord-SVN und damit dem Sourcetarball rausnehmen. Stattdessen die im System vorhandene libjthread verwenden.
Ich hab das bei mir lokal schon gemacht, ich müßte es nur noch committen. Ich weiß nicht ob Dir das aber evtl. Probleme beim bauen unter Deiner Windowsinstallation bringt.
Für openSUSE hab ich schon ein libjthread RPM gebaut.

Bitte nicht.
Beim lame (zumindest meine ich das mal für die liblame gebaut zu haben) schauen wir unter Un*x ob schon ein lame auf dem System ist und nehmen dann die. Findet das configure keine wird die eigene genommen, genauso unter Windows. Für die jthread würde ich das dann genauso machen wollen.

Kannst Du den Patch so anpassen?

Protokoll:
Um rauszufinden, ob man sich mein Client einloggen muß setze ich bisher einen Keepalive ab. Evtl wäre es aber schick, wenn der Server nach dem Verbindungsaufbau einfach mal einen "Not logged in" error schicken würde, wenn er einen Login benötigt.

Könnte man machen, der Keepalive oder Capabilities Aufruf erledigt das allerdings auch. Erfasst Du das als Verbesserungswunsch im bts?

Bei mir, übrigens, liefert ein Inquiry eine leere Liste geladener Plugins obwohl audiorecorder und mysql geladen sind. Könnt ein Bug sein.

Dafür wurde kein Code geschrieben. Beim MySQL wüsste ich auch spontan nicht wozu das gut ist, da über das Monitor Protokol nichts bzgl. MySQL gemacht wird. (beim audiorecorder kann man ja die Aufnahme starten, da macht das Sinn)

Config:
Die Beispielconfig ist kein valides XML, fixe ich gerne, wird aber einen dicken diff geben.

Was ist denn an dem XML nicht valide? Ich habe eben nochmal ins SVN geschaut, sieht gut aus.

Die Plugins sollte man einfacher Einbinden können. Anstatt des vollen Dateinamens mit Pfad vielleicht nur den Namen - Pfad und Dateiendung könnte man beim Laden ergänzen.

Halte ich für Kosmetik da es primär die Paketierer und nicht die Anwender betrifft. Erfasst Du das als Erweiterungswunsch im bts?

Gruß,
Karl

[cwh]

Hallo,

Beim lame (zumindest meine ich das mal für die liblame gebaut zu haben) schauen wir unter Un*x ob schon ein lame auf dem System ist und nehmen dann die. Findet das configure keine wird die eigene genommen, genauso unter Windows. Für die jthread würde ich das dann genauso machen wollen.

Kannst Du den Patch so anpassen?

Wenn ich das bei Lame abkupfere, dann bekomm ich das hin.

Warum brauchst Du das? Finde ich nämlich ehrlichgesagt etwas ... äh ... improvisiert.

Könnte man machen, der Keepalive oder Capabilities Aufruf erledigt das allerdings auch. Erfasst Du das als Verbesserungswunsch im bts?

Mach ich.

Dafür wurde kein Code geschrieben. Beim MySQL wüsste ich auch spontan nicht wozu das gut ist, da über das Monitor Protokol nichts bzgl. MySQL gemacht wird. (beim audiorecorder kann man ja die Aufnahme starten, da macht das Sinn)

Eigentlich beim Inquiry auch nicht sinnvoll, da der Audiorecorder ja an einem Kanal hängt. Demnach würde es nur in die Channel Info passen, was aber eine Protokollanpassung mit sich brächte.
Kurz gesagt: Die Pluginsausgabe beim Inquiry kann man einfach streichen.

Ich finde übrigens auch das Kommando 110 überflüssig. Wann und wozu sollte der monitord sich nach dem Client erkundigen?

Was ist denn an dem XML nicht valide? Ich habe eben nochmal ins SVN geschaut, sieht gut aus.

Ok, dick ist mein diff nur, weil ich auch noch die Einrückung korrigiert hab - das sollte ich weglassen. Aber xmllint und mein emacs sind sich über folgende Problemchen einig, die ich einfach mal fixen werde:

#> xmllint monitord.xml.win32
monitord.xml.win32:4: parser error : Comment not terminated

                                                      ^
monitord.xml.win32:17: parser error : Comment must not contain '--' (double-hyphen)
        
            ^
monitord.xml.win32:20: parser error : AttValue: " or ' expected
        192.168.0.1