monitor 1.9.0 - aber richtig :)

[Buebchen]

Aktuelles SVN:

http://svn.monitord.de

-> wichtig ist das http Protokoll (für WebDAV)

[DocSteel]

Ah danke! :)

[Buebchen]

Eine neue Version ist im SVN eingecheckt. Würde mich interessieren, ob die jeder compilieren kann. Einiges ist geändert. Die meisten Features sind als Kernelement (ohne grosse Tests) vorhanden.

Wichtig:
lame + mysql werden vom configure script getestet, wenn man es nutzen will. Dazu muss die libmp3lame.so und libmysqlclient.so im Linkerpfad liegen. Sonst meldet configure einen Fehler.

Ach ja. Die option --enable-lame habe ich in --with-lame umbenannt (da es auch with--mysql heisst).

Das vollständige Pluginpaket würde also mit --enable-plugins --with-mysql --with-lame erstellt werden.

Gibt es eigentlich jemanden, der rpm bauen kann ?

[nepomuck]

Moin,

Mal 'ne grundsätzliche Frage:

Das vollständige Pluginpaket würde also mit --enable-plugins --with-mysql --with-lame erstellt werden.

Braucht es diese ganzen Parameter beim Build wirklich? Geht das nicht einfacher, so dass der Anwender nur über die monitor.xml entscheidet, welche Module er starten will. Ein einfaches ./configure und make baut dann einfach alles.

lame + mysql werden vom configure script getestet, wenn man es nutzen will. Dazu muss die libmp3lame.so und libmysqlclient.so im Linkerpfad liegen

Braucht es diese Libs zum Build oder erst zur Laufzeit? Es sollte doch genügen, wenn in der monitor.xml der Pfad zu den Libs angegeben wird, falls der Anwender diese Module nützen möchte.
Das würde es erheblich vereinfachen, den monitord als Binärdatei auf einer Distribution zu installieren (per RPM oder DEB).

Liesse sich überdies eine Option einbauen, die nach einer Ausnahme die Audiodatei an ein externes Skript übergibt? Dann könnte man die Aufzeichnung beispielsweise durch einen Filter jagen, der Ruhepasen entfernt.

viele Grüße,
Andreas

[Buebchen]

Moin,

Mal 'ne grundsätzliche Frage:

Braucht es diese ganzen Parameter beim Build wirklich? Geht das nicht einfacher, so dass der Anwender nur über die monitor.xml entscheidet, welche Module er starten will. Ein einfaches ./configure und make baut dann einfach alles.

Im Moment - solange die Module nicht als Default=yes eingetragen sind braucht es die Optionen. Da alles noch kein "stable" Status hat ist es m.E. richtig die Module erstmal nicht automatisch zu bauen.

Braucht es diese Libs zum Build oder erst zur Laufzeit? Es sollte doch genügen, wenn in der monitor.xml der Pfad zu den Libs angegeben wird, falls der Anwender diese Module nützen möchte.
Das würde es erheblich vereinfachen, den monitord als Binärdatei auf einer Distribution zu installieren (per RPM oder DEB).

Die Libs braucht es beim schon beim Bauen, da die Plugins gegen die Bibliotheken gelinkt werden (vereinfacht gesagt). Im Grunde braucht er nicht die komplette DLL/Lib. Aber das macht an der Stelle keinen Unterscheid.

Liesse sich überdies eine Option einbauen, die nach einer Ausnahme die Audiodatei an ein externes Skript übergibt? Dann könnte man die Aufzeichnung beispielsweise durch einen Filter jagen, der Ruhepasen entfernt.

viele Grüße,
Andreas

Das läßt sich mit Sicherheit einbauen. Sollten wir im BTS eintragen.

[mdi]

Moin mal wieder von mir,

ich habe mich nach einigen Problemen mit der Erkennung der von unseren Handfunkgeräten ausgesandten ZVEI-Fünftonfolgen nocheinmal daran gemacht, die Logik zu verbessern. So weit ist mir das auch gelungen; es wird jetzt immer über einen Block von sieben Sound-Puffern nach einem "klaren" Ton gesucht. Wird dieser eindeutig (>50% entsprechend 4 Blöcken) gefunden, wird der Ton als erkannt weitergereicht und in der Fünftonfolge abgelegt. Der 7er-Puffer arbeitet als Ring, erkannte Blöcke werden markiert, so dass Töne nur selten doppelt erkannt werden können - wenn das passiert, werden die Dopplungen vor der Eintragung in die Tonfolge erschlagen (zweimal dieselbe Frequenz darf nicht erkannt werden - müsste dann der Wiederholton sein). Umgesetzt wird die "korrekte" Ausgabe der wiederholten Ziffern erst bei der Ausgabe, solange liegen die Daten in Rohform (Array-Index der erkannten Frequenz vor).

Die bisherigen Versuche laufen gut und bis auf tatsächlich ernsthaft gestörte Signale sehr gut (was soll man in Müll auch erkennen...), allerdings fehlt die Sirenentonerkennung noch komplett.

Vor allem habe ich diesbezüglich eine Frage an Buebchen: Ich würde das Binary/den Installer gern selber bauen können, damit ich das Komplettpaket testen kann; kannst Du hier veröffentlichen, wie Du das gemacht hast und was für die Kompilierung einschließlich der Pugins noch benötigt wird?

Viele Grüße
Martin

[Buebchen]

Vor allem habe ich diesbezüglich eine Frage an Buebchen: Ich würde das Binary/den Installer gern selber bauen können, damit ich das Komplettpaket testen kann; kannst Du hier veröffentlichen, wie Du das gemacht hast und was für die Kompilierung einschließlich der Pugins noch benötigt wird?

Viele Grüße
Martin

Mal so aus dem Kopf (da ich gerade nicht nachgucken kann):

a) Du brauchst die Nullsoftinstaller: nsis.sf.net
b) Im SVN gilt es nen order der auch irgendwas mit nsis heisst. Da ist die "Quelldatei" für den Installer drin. Ich meine ich habe alles relativ zu diesem Ordner adressiert. Also solltest Du dann direkt dieses Skript mit dem nsis kompilieren können. Raus kommt dann ein fertiges Installationspaket. Die Datei nimmt er dazu aus dem Ordner, wo diese nach einem Build fertig liegen. Die muss man nicht weiter verschieben o.ä.

c) Falls Du das Binary selbst nicht bauen kannst ist das dann doch etwas umständlicher, da man die MySQL DLLs für den gcc unter MSYS/MinGW ein wenig anpassen muss. Das muss ich dann nochmal zusammenstellen.
d) Ausserdem muss ich seltsamerweise für das configure Skript die libmysql.a bei mir umbenennen, damit das configure Skript MySQL-Support erkennt. Später beim build brauch die aber gerade (was m.E. auch so richtig ist).

Aber auch das muss ich nochmal zusammensuchen. Da wir uns den närrischen Tagen nähern bin ich nur gerade etwas mit Arbeit überhäuft. Denn die nächsten Einsätze stehen schon an ... :-)