Freeze zum ersten Release

Druckbare Version

11.09.2009, 13:19
Buebchen

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 !
13.09.2009, 09:03
Omega1977

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???
13.09.2009, 14:50
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.
13.09.2009, 14:52
Omega1977

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 !!!
14.09.2009, 15:25
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
15.09.2009, 16:06
dekarl

Tag,

Zitat:

Zitat von cwh

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

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

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

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

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
16.09.2009, 11:39
cwh

Hallo,

Zitat:

Zitat von dekarl

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

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

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

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 <ip action=allow>192.168.0.1</ip> <!-- Diese IPs muessen sich nicht einloggen - ^ monitord.xml.win32:20: parser error : attributes construct error <ip action=allow>192.168.0.1</ip> <!-- Diese IPs muessen sich nicht einloggen - ^ monitord.xml.win32:20: parser error : Couldn't find end of Start Tag ip line 20 <ip action=allow>192.168.0.1</ip> <!-- Diese IPs muessen sich nicht einloggen - ^ monitord.xml.win32:20: parser error : Opening and ending tag mismatch: monitordconfig line 2 and ip <ip action=allow>192.168.0.1</ip> <!-- Diese IPs muessen sich nicht einloggen - ^ monitord.xml.win32:21: parser error : Extra content at the end of the document <ip action=allow>192.168.0.2</ip> <!-- Diese IPs muessen sich nicht einloggen - ^

Zitat:

Zitat von dekarl

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

Betrifft auch Anwender, da es nicht immer möglich ist, ein Configfile zwischen zwei Systemen auszutauschen, je nach dem, wo man den Kram hininstalliert hat. Die Beispielconfig funktioniert auch nur selten out of the box, bevor man nicht den Pfad angepasst hat. Auch die Notwendigkeit für Windows und Linux unterschiedliche sample-configs zu haben würde damit entfallen.

Und was einen Packager betrifft, betrifft auch den Anwender, denn was ich im Paket schon erledige, muß der Anwender nach der Installation nicht mehr machen.

Grüße,
Christopher
16.09.2009, 13:34
Buebchen

Zitat:

Zitat von cwh

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

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

Warum man ggf. das mitgelieferter jthread nutzen sollte / können sollte ? Naja. Weil es unter Windows kein vorinstalliertes gibt ... :)

Ich denke die lame Quelltexte werde ich demnächst mal aus dem Repository rausnehmen und stattdessen den leeren Ordner als Platzhalter drin lassen. Damit sollte man die lizenzrechtlichen Probleme umgehen können.

Zitat:

Zitat von cwh

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.

Oder man ergänzt die Plugininfo noch mit dem verbundenen Kanal. Dann würde es wieder Sinn machen. Da bisher nur der Audiorekorder interessant ist kann man auch einfach nur eine Aufnahme versuchen. Wenn der monitord dann meckert ist kein audioplugin installiert.

Ich bin mir nicht sicher, ob im Moment noch jemand am Protokoll weiterarbeitet. Ein neuer Thread dazu würde Sinn machen, um für die nächste Version dann den unnützen oder überholten Kram loswerden zu können. Für 2.0 würde ich das erstmal so lassen. Höchstens in Pflicht- und Optionalparameter einteilen.

Zitat:

Zitat von cwh

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

Das kann schon Sinn machen. Wenn der Client sich intern in einer Schleife verrennt würde er den TCP-Socket nicht automatisch schließen. Solche Clients kann man dann mit einer "echo"-Check ausfindig machen. Genutzt wird es im Moment nicht. Höchstens zum testen/debuggen mal. Da es kein besonders grosser Programmieraufwand ist kann man das m.E. erstmal drin lassen.

Zitat:

Zitat von cwh

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:

Die Korrektur ist bestimmt sinnvoll. Wobei ich bei einer config datei die man wohl eher nie mit einer DCD segnen oder auch mal transformieren will das nicht so dramatisch sehe :) Dennoch sollte man da natürlich auch versuchen sich an die Standards zu halten.

[/Quote]

Zitat:

Zitat von cwh

Betrifft auch Anwender, da es nicht immer möglich ist, ein Configfile zwischen zwei Systemen auszutauschen, je nach dem, wo man den Kram hininstalliert hat. Die Beispielconfig funktioniert auch nur selten out of the box, bevor man nicht den Pfad angepasst hat. Auch die Notwendigkeit für Windows und Linux unterschiedliche sample-configs zu haben würde damit entfallen.

Und was einen Packager betrifft, betrifft auch den Anwender, denn was ich im Paket schon erledige, muß der Anwender nach der Installation nicht mehr machen.

Grüße,
Christopher

Die Pfade relativ anzugeben halte ich auch für sinnvoll. Ich könnte mir da z.B. auch einfach einen PluginOrdner Parameter vorstellen (Entweder absolut oder relativ zum aktuellen Verzeichnis). Zum Thema Endungen: Da würde ich einfach erst dem Dateinamen als solches Versuchen und dann unter win32 ein .dll ergänzen. Unter linux ein .so . Damit wäre das Ziel der Portabilität der config files in Deinem Sinne erreicht, oder ?

Ich merke, daß cwh das ganze unter linux anwendet. Somit sieht er es natürlich mehr die Bedürfnisse, die da vorherrschen. Meistens ist das deckungsgleich oder unabhängig zum win32 System. Sollte dem nicht so sein sollten wir immer versuchen - so wie bisher auch - eine Lösung zu finden, die auf beiden Systeme arbeitet. Ich nutze msys ja nicht, weil es so besonders komfortabel ist sondern um möglichst wenig Einzelanpassungen pro System machen zu müssen.

Zum thema libtool könnte ich inzwischen vermutlich Bücher schreiben. Nicht, weil ich sie verstanden habe sondern weil es einfach ständig was zu meckern hat. Wer Zeit hat kann ja mal versuchen das sox v14 mit dem plugins unter msys zu kompilieren. Und dann auch noch zu seinem Programm zu linken ...

Ich werde irgendwann nochmal Visual C installieren und dann da die dll erstellen. Alles andere ist furchtbar.
16.09.2009, 14:39
cwh

Hi,

Zitat:

Zitat von Buebchen

Warum man ggf. das mitgelieferter jthread nutzen sollte / können sollte ? Naja. Weil es unter Windows kein vorinstalliertes gibt ... :)

Öhm, man bekommt die libs da nicht irgendwie als dlls hin?

Zitat:

Zitat von Buebchen

Ich denke die lame Quelltexte werde ich demnächst mal aus dem Repository rausnehmen und stattdessen den leeren Ordner als Platzhalter drin lassen. Damit sollte man die lizenzrechtlichen Probleme umgehen können.

Die Probleme hat man eigentlich nur als Distributor. Damit verhindert man also nur, daß man mal auf einer Distri landet bzw. in meinem konkreten Fall, daß man es im openSUSE Buildservice bauen kann. Und letzteres ist zur Bereitstellung von Binärpaketen für die gängigen Distributionen eine sagenhafte Arbeitserleichterung.

Zitat:

Zitat von Buebchen

Oder man ergänzt die Plugininfo noch mit dem verbundenen Kanal. Dann würde es wieder Sinn machen. Da bisher nur der Audiorekorder interessant ist kann man auch einfach nur eine Aufnahme versuchen. Wenn der monitord dann meckert ist kein audioplugin installiert.

So mach ich das bisher auch und damit komm ich auch zurecht. Allerdings wäre die Info schon besser in der Kanalinfo afgehoben, denke ich.

Zitat:

Zitat von Buebchen

Die Korrektur ist bestimmt sinnvoll. Wobei ich bei einer config datei die man wohl eher nie mit einer DCD segnen oder auch mal transformieren will das nicht so dramatisch sehe :) Dennoch sollte man da natürlich auch versuchen sich an die Standards zu halten.

Ist schon behoben. Ich würde die Linux Beispielconfig übrigens auch noch gerne mit Unix statt DOS Lineendings ausstatten. Das gibt aber dann einen 100%-diff.

Zitat:

Zitat von Buebchen

Die Pfade relativ anzugeben halte ich auch für sinnvoll. Ich könnte mir da z.B. auch einfach einen PluginOrdner Parameter vorstellen (Entweder absolut oder relativ zum aktuellen Verzeichnis). Zum Thema Endungen: Da würde ich einfach erst dem Dateinamen als solches Versuchen und dann unter win32 ein .dll ergänzen. Unter linux ein .so . Damit wäre das Ziel der Portabilität der config files in Deinem Sinne erreicht, oder ?

Ich würde Pfade und Endung mit Präprozessorkommandos zur compiletime festlegen. Configure weiß alles, was man dazu braucht, heißt: den libpath und die Plattform.

Wenn <file> konfiguriert ist, dann sollte erst geguckt werden, ob das geladen werden kann, wenn <file> fehlt, dann würde einfach wie folgt ein Filename zusammenstöpselt werden:

LIBPATH/libmplugin_PLUGINNAME.SUFFIX

Ich würde das mal versuchen einzubauen, wenn keiner was dagegen hat.

Zitat:

Zitat von Buebchen

Ich merke, daß cwh das ganze unter linux anwendet. Somit sieht er es natürlich mehr die Bedürfnisse, die da vorherrschen. Meistens ist das deckungsgleich oder unabhängig zum win32 System. Sollte dem nicht so sein sollten wir immer versuchen - so wie bisher auch - eine Lösung zu finden, die auf beiden Systeme arbeitet. Ich nutze msys ja nicht, weil es so besonders komfortabel ist sondern um möglichst wenig Einzelanpassungen pro System machen zu müssen.

Zum thema libtool könnte ich inzwischen vermutlich Bücher schreiben. Nicht, weil ich sie verstanden habe sondern weil es einfach ständig was zu meckern hat. Wer Zeit hat kann ja mal versuchen das sox v14 mit dem plugins unter msys zu kompilieren. Und dann auch noch zu seinem Programm zu linken ...

Ich werde irgendwann nochmal Visual C installieren und dann da die dll erstellen. Alles andere ist furchtbar.

Ja, ich verwende monitord ausschließlich unter Linux, daher weiß ich auch nicht um die Fallstricke, die man hat, wenn man das ganze versucht unter Windows zu bauen. Gibt es sox etc. nicht evtl einfach fertig gebaut für mingw?

Unter Linux baut monitord inzwischen ja einfach und problemlos durch.

Grüße,
Christopher
16.09.2009, 17:21
dekarl

Tag,

für einen Prerelease sehe ich primär die Themen
* mp3/ogg
* QuellcodeLizenz
* Installationsanleitung
* Beispielclient (k.A. ob es schon irgendwo kleine Java Applets für FMS32/Crusader gibt, dann müsste man nichts eigenes schreiben) damit man nach dem entpacken "irgendwas" sieht

Das ganze würde ich als ersten Stand den man Paketieren / Verteilen kann ansehen.

Für unser erstes "richtiges" Release stelle ich mir jedoch etwas mehr vor, ich fasse mal ein wenig meine Gedanken zusammen:

* Netzprotokolle fixieren bzgl. Zeitzonen... intern nur UTC, nach außen vmtl. Lokale Zeit in fms32/crusader und UTC im Monitorprotokoll. Umwandlung dann nur zur Anzeige im Client
* man kann den monitor auch unter linux für windows bauen... einfach mal ./configure -host=mingw32 laufen lassen... Geht natürlich nicht mit MySQL :( (für SQLite muß ich das mal prüfen, ist ein Grund das ich das möchte)
* wegen mir brauchen wir gar kein .mp3 unterstützen, Ogg Vorbis erfüllt den gleichen Zweck ohne die daran hängenden rechtlichen Fallsticke (Manches Linux spielt per default kein mp3, Windows kein Vorbis. Aber das kann man ja mit dem cortado applet umgehen)
* ich sehe auch noch nicht wirklich den Zweck von Plugins. diese sind ja primär interessant um Funktionen komplett ins Programm rein/raus zu bekommen ohne neu zu kompilieren. Wir haben weder so viele Plugins wie z.B. der Apache Webserver noch das Problem das keiner unseren Quellcode sehen darf ;) Damit wäre das ganze Pluginconfig Thema auch vom Tisch
* die LUA Filterfunktion finde ich gut, dort sollte allerdings noch das eigentliche Ereignis verändert werden könnten. (z.B. per Skript die default Funkrufnamen als Text ans FMS dranhängen, etc.)
* es fehlt noch eine fest integrierte (also nicht optionale) Historie inkl. Statusspeicher (aktueller Status) mit Anbindung an alle drei Protokolle
* darauf aufbauend Unterdrückung redundanter Status und ggf. Generierung fehlender Status. ("gehen Sie über die 1 in die 3"... Piep "3 ohne 1"...) das ganze je nach Geschmack im LUA damit es jeder an seine Bedürfnisse anpassen kann.
* Steuerung der Aufnahme per LUA Filter auf der Eingangsseite (z.B. bei Alarmierung 120 Sekunden aufnehmen, bei FMS Status 15 nur 60 Sekunden)
* Clientbibliothek in Java mit Beispielclients 1) "Batch" z.B. für SMS Versand und 2) ein Applet als Einsatzdisplay

spätestens ab hier sehe ganz klar die 2.1 als Ziel ;)

* Die Eingangsseite würde ich gerne mal Anpassen so das man auch andere Datenquellen als Soundkarten nutzen kann. (z.B. FMS32/Crusader/POC32 Server, oder auch POCSAG-Modems)
* integrierter HTTP Server mit ereignisgesteuertem Client (Stufe 1, einfach ein Protokollfenster das ohne reload alles eingehende zeigt)
* Verlagerung der Stammdaten in den Server (ggf. mit Im-/Export für die üblichen fremden Clients) und Erweiterung des Webclient zur Konfiguration
* Erweiterung Webclient um Kartendarstellung (siehe Openlayers) inkl. der Infrastruktur in den Auswertern/Protokollen dazu
16.09.2009, 19:38
Buebchen

Zitat:

Zitat von dekarl

Tag,

für einen Prerelease sehe ich primär die Themen
* mp3/ogg
* QuellcodeLizenz
* Installationsanleitung
* Beispielclient (k.A. ob es schon irgendwo kleine Java Applets für FMS32/Crusader gibt, dann müsste man nichts eigenes schreiben) damit man nach dem entpacken "irgendwas" sieht

Das ganze würde ich als ersten Stand den man Paketieren / Verteilen kann ansehen.

Um diesen Stand geht es mir erstmal. Ob man beim monitord zur 2.0 schon nen Client braucht (es gibt ja AllFMS, FMS32Pro Demo und Crusader Demo) kann man sicherlich kontrovers betrachten. Wenn jemand einen hat/macht ist das umso besser.

Ich möchte einfach das Thema zur einem Stand bringen wo ein Client-Entwickler sicher sein kann, was der monitord bietet (oder auch nicht). Könnte ja durchaus sein, daß deswegen noch kein Client exisitiert: Viele warten auf den ersten Release.

mp3/ogg (ich würde das unter sox zusammenfassen) halte ich auch für die 2.0 sinnvoll. Wenn die dann soweit fertig ist. Von mir aus nennen wir diesen Stand auch erstmal einen Milestone, wenn 2.0 quasi der grosse Knaller werden soll :)
17.09.2009, 10:18
dekarl

Zitat:

Zitat von cwh

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.

Ich habe mir das mal angeschaut und ins bts gepackt, ist nicht so ganz trivial und damit nichts für während des Freeze.
http://bts.monitord.de/?do=details&task_id=36
21.09.2009, 17:06
cwh

Hi.

Idealerweise würde man auch meine Standardsprache für das Projekt festlegen, in der dann die Doku, die Kommentare im Quellcode und README und dergleichen verfasst werden. Eine Mixtur aus Englisch und Deutsch sollte man vermeiden.

Englisch wäre natürlich eigentlich Standard, allerdings halte ich es für ziemlich wahrscheinlich, daß die überweigende Mehrheit der Nutzer im deutschsprachigen Raum zu finden sein wird und möglicherweise Probleme mit Englisch haben wird.

Meinungen?

Christopher
21.09.2009, 17:58
Buebchen

Inzwischen bin ich eher für deutsch. Zwischenzeitlich hatte ich mal überlegt es in englisch zu verfassen. Aber ich denke es werden nur wenige nicht deutschsprachige im Quelltext tauchen. Solange wir nicht anfangen wie man erste Prof. selbst die Endung Ptr (Pointer) in Zgr (Zeiger) umzuändern kann ich damit leben :)
06.12.2009, 12:29
Thorongil

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.
10.02.2010, 20:50
dekarl

Zitat:

Zitat von cwh

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.

FS#36 ist seit eben im trunk umgesetzt, bitte testen.
10.02.2010, 23:55
mdi

Mahlzeit,

eben ausgecheckt - Fehler:

Code:

monitord/SndPipe.cpp: In member function `bool CSndPipe::loadPlugin(std::string, XMLNode, MonitorAudioPlugIn**, int)': monitord/SndPipe.cpp:322: error: `m_monitor' was not declared in this scope monitord/SndPipe.cpp:322: warning: unused variable 'm_monitor' make[1]: *** [monitord/monitord_monitord-SndPipe.o] Error 1 make[1]: Leaving directory `/i/workspace/monitord' make: *** [all] Error 2

Nur hier rein gedumpt, ich bin grad zu müde zum Suchen... :7.
Martin
11.02.2010, 09:16
dekarl

Zitat:

Zitat von mdi

Nur hier rein gedumpt, ich bin grad zu müde zum Suchen...

Ohh, nach einer morgendlichen Indoorschneeballschlacht sollte es jetzt besser funktionieren.
Vielleicht sollten wir die Plugins mal per default einschalten :-)
11.02.2010, 12:18
mdi

Moinmoin,

*lachen muss* - Indoorschneeballschlacht hatte ich heute Morgen; es fauchte ganz guter Wind die Nacht. Dieser war mit feinen Eiskristallen durchsetzt, und da der Wind diese ganz nett durch mein angekipptes Fenster blies... naja.

Zurück zum monitord ;). Ich habe nachdem ich alle <logfile>-Tags mit einem Dateinamen gefüllt habe nur noch eine Zeile im Fenster:
"(... Zeit ...) INFO: monitord/PluginThread.cpp(149) PluginManager erstellt"

In der Zeile im Code finde ich aber " FILE_LOG(logINFO) << "PluginManager erstellt" ;" - das sollte doch an sich ins File gehen...

Sonst schön geworden; ich denke, ich werde "mein" ZVEI-Modul nochmal insofern sinnvoll anpassen die Tage als es ja quasi keine sinnvoll verwertbaren Informationen in auch nur irgendein Log schreibt ;).

Danke :)
Martin