monitor 1.9.0 - aber richtig :)

[DocSteel]

Hallo

Es wäre schön wenn mal einer der Entwickler im ersten Beitrag dieses Themas einen aktuellen Link zu einem funktionierenden svn posten könnte (bzw. den vorhandenen anpassen)

Bei jhr-online.de/monitor und bei monitord.de kommen beim Versuch dort svn's auszuchecken Fehlermeldungen bzw. es gibt die Domain im ersten Fall gar nicht mehr.

Das macht es Interssierten schwer an die Quellen zu kommen. Trotzdem ein tolles Projekt.

Gruß

Doc - Der sich über einen Link zu den aktuellen Dev-Quellen freuen würde (gerne auch Vers. 1.9, muss ja nicht 2.0 Beta sein, hauptsache es läuft)

[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