Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 19

Thema: Freeze zum ersten Release

  1. #1
    Registriert seit
    11.12.2001
    Beiträge
    1.008

    Freeze zum ersten Release

    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 !

  2. #2
    Registriert seit
    23.12.2005
    Beiträge
    452

    Problem

    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???
    ...ist meine Meinung

  3. #3
    Registriert seit
    11.12.2001
    Beiträge
    1.008
    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.

  4. #4
    Registriert seit
    23.12.2005
    Beiträge
    452

    Großbuchstaben...

    ....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 !!!
    ...ist meine Meinung

  5. #5
    Registriert seit
    15.04.2009
    Beiträge
    29
    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
    Geändert von cwh (14.09.2009 um 18:08 Uhr)

  6. #6
    Registriert seit
    24.07.2007
    Beiträge
    40
    Tag,

    Zitat Zitat von cwh Beitrag anzeigen
    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?

    Zitat Zitat von cwh Beitrag anzeigen
    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?

    Zitat Zitat von cwh Beitrag anzeigen
    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)

    Zitat Zitat von cwh Beitrag anzeigen
    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.

    Zitat Zitat von cwh Beitrag anzeigen
    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

  7. #7
    Registriert seit
    15.04.2009
    Beiträge
    29
    Hallo,

    Zitat Zitat von dekarl Beitrag anzeigen
    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.

    Zitat Zitat von dekarl Beitrag anzeigen
    Könnte man machen, der Keepalive oder Capabilities Aufruf erledigt das allerdings auch. Erfasst Du das als Verbesserungswunsch im bts?
    Mach ich.

    Zitat Zitat von dekarl Beitrag anzeigen
    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?

    Zitat Zitat von dekarl Beitrag anzeigen
    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:
    Code:
    #> 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 
    
    
    
    Bug http://bts.monitord.de/index.php?do=details&task_id=38

    In MonitorLogging.h die std::sprintf Aufrufe durch sprintf ersetzen, dann kompiliert es.

    Bug http://bts.monitord.de/index.php?do=...status%5B0%5D=

    configure.ac:

    AC_ARG_ENABLE(plugins,
    AC_HELP_STRING([--enable-plugins],
    [enable experimental plugin support (default is no)])],
    [use_plugins=$enableval
    plugins=true],
    [use_plugins=no])

    Damit gehts.

    Hätte mich gerne am bugtracker angemeldet, aber es geht nicht, Fehlermeldung, dass das PHP-Skript nicht nach /tmp schreiben kann und das PHP-Caching nicht geht.

Aktive Benutzer

Aktive Benutzer

Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •