monitor 1.9.0 - aber richtig :)

Zitat:

---

Zitat von nepomuck

Wäre möglich, aber macht das Sinn? Der Client hat ja die Zeit selbst vorgegeben und erwartet einen "Aufnahme beendet". Er braucht die "Zischenzeit"-Angabe vom Server nicht auszuwerten.

---

Der Gedanke ist, daß der Client dem User anzeigen kann,wie lange er noch auf die Datei warten muss bis sie fertig ist. Wenn zwei Benutzer eine Aufnahme mit unterschiedlichen Aufnahemdauern auslösen kann sich die anfängliche Aufnahmedauer verändern. Das weiss der erste Client aber dann nicht und versucht die Datei zu öffnen, obwohl sie noch im Zugriff ist.

Zitat:

---

Zitat von nepomuck

Ich move das Executable monitord nach erfolgreichem make in ein anderes Verzeichnis, in dem sonst nur die .xml drin steht. Da kann er die Module nicht finden.
Wie heissen die Moduldateien? Kann man einen Failsafe einbauen, so dass monitord eine klingende Fehlermeldung ausgibt wie "Module nicht gefunden"?

---

Ist schon in Arbeit. Bisher war der Pfad fest auf die SVN Ordner verknüpft, da es auch noch kein Install dazu gibt.

Zitat:

---

Zitat von nepomuck

Um Fehler zu vermeiden, sollte monitord.xml dann gar keine Nummern sondern nur Namen deklarieren. Die Nummerierung erledigt monitord dann intern gemäß der Reihenfolge der Kanäle in der Config.

---

Hmm. Dann müßte ich unter Windows die Kartennummer anders hinterlegen (Windows nutzt primär die Gerätenummer, nicht seinen Namen. Würde aber gehen. Werde ich mal Testweise umbauen.

Zitat:

---

Zitat von nepomuck

OK. Dan bekommt der 300 ein Textfeld am Ende. Was machen wir, wenn es keinen Text zu übermitteln gibt? Lassen wir das Feld weg oder sendet der 300 in dem Fall ein einzelnes ":" am Ende?

---

Ich sende dann ein ":" ohne nachfolgenden Text.

Zitat:

---

Zitat von Buebchen

Wenn zwei Benutzer eine Aufnahme mit unterschiedlichen Aufnahemdauern auslösen kann sich die anfängliche Aufnahmedauer verändern. Das weiss der erste Client aber dann nicht und versucht die Datei zu öffnen, obwohl sie noch im Zugriff ist.

---

Hä?
Wenn zwei getrennte Clients ein REC-Kommando absetzen, erstellt der monitord auch zwei getrennte Files. Wenn also Client 1 die Aufzeichnung verlängert, betrifft das nicht die Aufzeichnung von Client 2.
Jeder Client weiss daher, dass die Aufzeichnung nach Ablauf seiner Zeitvorgabe zzgl. Zeit für die Umwandlung von raw nach wav oder mp3 fertig sein muss. Eine Zwischenzeitangabe nützt dem Client nichts, da der monitord die Umwandlungszeit von sox/lame nicht vorhersagen kann. Damit wäre die Zeitangabe auch nur eine bessere Schätzung.

Warum sollte der Client ausserdem versuchen, auf die Datei zuzugreifen, bevor er den passenden 104 erhalten hat? Ich würde im Client eine Eventsteuerung einbauen, die den 104 abwartet und dann die REC-Datei per FTP/NFS/CIFS auf den Client holt.

Zitat:

---

Zitat von Buebchen

Ich sende dann ein ":" ohne nachfolgenden Text.

---

So im Protokoll vermerkt.

viele Grüße,
Andreas

Mit dem 104:0 Status macht natürlich Sinn. Erst ab dann ist die Aufnahme verfügbar. Jetzt aber zum Haken an der Sache. Pro Kanal wird im Moment nur eine Aufnahme laufen. Diese wird mit einem 104:2: Kommando nach Angabe des letzten Clients verlängert. Das teilt monitord dann auch per 104:2 Kommando allen zur Zeit aufnehmenden Clients mit.

Dann habe ich den Parameter 104:2 falsch interpretiert. Werde mal sehen, ob sich das auch mit einzelnen Aufnahmen realisieren läßt.

Zitat:

---

Zitat von Buebchen

Das teilt monitord dann auch per 104:2 Kommando allen zur Zeit aufnehmenden Clients mit.

---

Es macht wenig Sinn, wenn ein Client erfährt, dass ein anderer was aufnimmt. Im Zweifelsfalle geht den Client der betreffende Kanal nicht einmal etwas an. In kommenden Versionen könnte (sollte) es auch eine User-Policy per Kanal geben, so dass nicht jeder Benutzer auch jeden verfügbaren Kanal abhören und auswerten darf.

Ich dachte, der monitord reicht kontinuierlich Datenblöcke von der Soundkarte durch einen Puffer, so dass sich mehrere REC-Tasks simultan daraus bedienen und daher völlig unabhängig voneinander aufnehmen können. Schliesslich greifen ja auch mehrere Auswerter simultan auf den Datenbestand zu.

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Es macht wenig Sinn, wenn ein Client erfährt, dass ein anderer was aufnimmt. Im Zweifelsfalle geht den Client der betreffende Kanal nicht einmal etwas an. In kommenden Versionen könnte (sollte) es auch eine User-Policy per Kanal geben, so dass nicht jeder Benutzer auch jeden verfügbaren Kanal abhören und auswerten darf.

Ich dachte, der monitord reicht kontinuierlich Datenblöcke von der Soundkarte durch einen Puffer, so dass sich mehrere REC-Tasks simultan daraus bedienen und daher völlig unabhängig voneinander aufnehmen können. Schliesslich greifen ja auch mehrere Auswerter simultan auf den Datenbestand zu.

viele Grüße,
Andreas

---

Es ist schon so, daß pro Kanal aufgezeichnet wird (also Mono). Auch getrennte Kanäle in Unterschiedliche Dateien. Pro Kanal ist zur Zeit aber immer nur exakt eine Aufnahme aktiv. Der Hintergrund ist einfach der, daß sonst noch massiver Multitasking nötig wird.

Wenn also ein Client A den Kanal 3 aufzeichnet hat das nichts damit zu tun (und er wird darüber auch nicht in Kenntnis gesetzt) wenn ein Client B den Kanal 1 aufzeichnet.

Kommt aber nun Client C und will den Kanal 3 aufzeichnen erhält er den gleichen Dateinamen wir Client A. Die Aufnahme wird ggf. entsprechend verlängert, wenn A's Aufnahme zu kurz wäre. Dann erhalten beide die Info 104:2 und auch 104:0. Das meinte ich mit alle. Nicht unbeteiligte Clients.

Disk I/O ist relativ langsam. Ich wollte das nicht zu weit ausbreiten. Einige wollen den monitord auf leistungsschwachen Maschinen einsetzen. Grundsätzlich könnte ich aber sicherlich auch mehrere Dateien innerhalb eines Kanals aufzeichnen. Muss ich aber schreiben. Da Weihnachten naht ist meine Zeit etwas knapp ...

Strukturell gibt es nicht pro Auswerter einen Thread - Nur pro Karte. Die Daten werden nacheinander an die Auswerter vergeben. Danach gehen die Daten dann an die AudioPlugins. Aber alles von einem Thread aus bedient. Ja, ich weiss. Man könnte da ganz toll was mit ThreadPools und WorkerThreads machen ... Wäre was für die Version 2.2 oder so :-)

Zitat:

---

Zitat von Buebchen

Kommt aber nun Client C und will den Kanal 3 aufzeichnen erhält er den gleichen Dateinamen wir Client A. Die Aufnahme wird ggf. entsprechend verlängert, wenn A's Aufnahme zu kurz wäre. Dann erhalten beide die Info 104:2 und auch 104:0. Das meinte ich mit alle. Nicht unbeteiligte Clients.

---

Kapiert!
Das kann aber dazu führen, dass ein Client zur Not Minuten oder gar Stundenlang auf seine Aufzeichnung warten muss und dann ein Monster-File erhält.
(Der Kyrill-Tag war ein solcher Extremfall, da ging alle paar Minuten ein Alarm raus)

Vorschlag:
Wir belassen es bei einem Thread pro Kanal für die Aufzeichnung. Der Segmentiert dafür die Aufzeichnung in Blöcke (pro 10 Sekunden ein RAW-File). Vor der Auslieferung an den Client übergibt monitord die Liste der Blöcke an sox, das daraus ein .wav- oder .mp3-File zusammenbaut.
Will ein weiterer Client während einer laufenden Aufzeichnung REC auslösen, läuft der Aufzeichnungs-Thread einfach weiter, monitord merkt sich die Nummern der RAW-Blöcke und denkt sich schon mal einen neuen Namen für den anderen Client aus..
Damit erzeugen wir eine Art pseude Multithread-Aufzeichnung ohne dabei aber die Systemlast zu steigern.
Theoretisch können dutzende verschiedener Clients simultan aufzeichnen so dass jeder seine eigene Datei erhält aber nur ein REC-Thread pro Kanal läuft.

Läßt sich das ohne große Probleme im Code umsetzen?

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Will ein weiterer Client während einer laufenden Aufzeichnung REC auslösen, läuft der Aufzeichnungs-Thread einfach weiter, monitord merkt sich die Nummern der RAW-Blöcke und denkt sich schon mal einen neuen Namen für den anderen Client aus..
Damit erzeugen wir eine Art pseude Multithread-Aufzeichnung ohne dabei aber die Systemlast zu steigern.
Theoretisch können dutzende verschiedener Clients simultan aufzeichnen so dass jeder seine eigene Datei erhält aber nur ein REC-Thread pro Kanal läuft.

Läßt sich das ohne große Probleme im Code umsetzen?

viele Grüße,
Andreas

---

Ööööh ... Nö :-)

Ich denke, ich werde pro REC Modul eine Liste von Dateien pflegen, die parallel geschrieben werden. Dann braucht der Datenblock nur einmal aufbereitet zu werden und wird dann in die einzelnen Dateien geschrieben. Muss nur angepasst werden, daß Client und Datei nicht verwechselt werden :-)

Ich habe nur Sorge, daß die Bearbeitungszeit für einen Datenblock länger ist, als es dauert der nächste Datenblock von der Soundkarte kommt. Dann müßte ich doch noch eine Queue für die Datenpakete machen. Sonst gehen Daten verloren und die Auswerter und/oder Datei bekommt unvollständige Tondaten (Nicht umsonst hat FMS32 diesen Soundkartenreset drin. Ich vermute, genau wegen solcher Probleme)

[Edit]:
Funktion ist jetzt geändert. In der nächsten Version sollte man das nochmal überarbeiten. Nicht alles so richtig hübsch. Aber egal. Die Funktion macht bei ersten Test zumindest keinen Absturz.

Die Dateinamen sehen jetzt so aus:
{Datum-Uhrzeit}_{Kanalnummer}_{jobID}.raw

Bsp:
20071217230000_0_2.raw

Alles ganz frisch. Bei mir klappt es soweit schon. Wer mag kann ja mal rev.230 austesten. Der Pfad zum Plugin kann jetzt auch im monitord.xml definiert werden. Siehe Datei im SVN.

Hat jemand mehr als eine Soundkarte ? Insbesonder unter Windows würde es mich interessieren , ob das in der Auswertung fehlerfrei läuft. Die SocketThreads kriegen davon noch nicht so viel mit, der Client dementsprechend auch noch nicht.

Windows interpretiert die Device Defintion von Linux in der monitord.xml nun als Gerätenummer. Also

/dev/dsp0 = Erste Soundkarte
/dev/dsp1 = Zweite Soundkarte
/dev/dsp2 = Dritte Soundkarte
/dev/dsp3 = Vierte Soundkarte

Ich habe ausserdem noch einen Support für lame implementiert. Damit kann man direkt in mp3 aufzeichnen. Das geht zwar, ist aber etwas kniffelig zu installieren. Das muss ich mal in einer ruhigen Minuten dokumentieren, bzw. mal als Beispiel darstellen.

Zumindest die configure Option gibt es schon. Muss mich aber mal mit autoconf befassen, wie nun automatisch den Pfad zu den DLLs, bzw. .so's finde (oder deren Existenz abklären kann).

[Edit]
Nachtrag: rev. 233 im SVN ist gemeint.

Zitat:

---

Zitat von Buebchen

Nachtrag: rev. 233 im SVN ist gemeint.

---

Upgedated; make clean; chmod +x config*; ./configure --enable-plugins; make

passiert folgendes:

Code:

---

...
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'virtual void MonitorAudioPlugInRecorder::ProcessAudio(float*, int)':
monitord/plugins/libmplugin_audiorecorder.cpp:211: warning: comparison between signed and unsigned integer expressions
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'void MonitorAudioPlugInRecorder::StartRecording(int, std::string, int)':
monitord/plugins/libmplugin_audiorecorder.cpp:275: error: cast from 'MonitorAudioPlugInRecorder*' to 'int' loses precision
monitord/plugins/libmplugin_audiorecorder.cpp:293: warning: converting to non-pointer type 'long int' from NULL
monitord/plugins/libmplugin_audiorecorder.cpp: In member function 'virtual std::string MonitorAudioPlugInRecorder::DoCommand(std::string, SocketThread*)':
monitord/plugins/libmplugin_audiorecorder.cpp:354: warning: comparison between signed and unsigned integer expressions
monitord/plugins/libmplugin_audiorecorder.cpp:359: warning: converting to non-pointer type 'long int' from NULL
make[1]: *** [monitord/plugins/monitord_plugins_libmplugin_audiorecorder_la-libmplugin_audiorecorder.lo] Fehler 1
make[1]: Verlasse Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
make: *** [all] Fehler 2

---

2. Versuch ohne Plugins:
make clean; ./configure; make

Code:

---

make  all-am
make[1]: Betrete Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
g++ -DHAVE_CONFIG_H -I.  -Ijthread-1.2.1/src -D_DEBUG -Wall -pedantic        -g -O2 -MT monitord/monitord_monitord-Monitor.o -MD -MP -MF monitord/.deps/monitord_monitord-Monitor.Tpo -c -o monitord/monitord_monitord-Monitor.o `test -f 'monitord/Monitor.cpp' || echo './'`monitord/Monitor.cpp
monitord/Monitor.cpp: In member function »void Monitor::InitSndCard()«:
monitord/Monitor.cpp:203: Fehler: »class CSndPipe« hat kein Element namens »loadPlugins«
make[1]: *** [monitord/monitord_monitord-Monitor.o] Fehler 1
make[1]: Verlasse Verzeichnis '/home/ast/monitorsvn/monitor/trunk'
make: *** [all] Fehler 2

---

Plattform: Athlon X2 mit Ubuntu 7.10 64-Bit.

any Ideas ?

Andreas

Hmm. Im oberen build sehe ich nur warnings. Die sind soweit auch ok.

Den Fehler im untern Build habe ich vermutlich schon behoben. Fehlte ein #define.
-> Rev.234 (#define in Monitor.cpp)
-> Rev.235 (#define in CSndPipe.cpp)

Den oberen Teil schau ich mir noch mal an.

[Edit]
Ah. War Blind. Habe den error jetzt gesehen. Schau mich mir an.
[Edit2]
Fehler im ersten Build liegt vermutlich am 64Bit System. Die Zeile kann ich aber bedenkenlos streichen, da sie nur für die ersten Debug Aufnahmen wichtig war.

-> Rev. 236 (pointer cast nach int geht unter 64Bit nicht)

Zitat:

---

Zitat von Buebchen

Rev. 236

---

Läuft mit Plugin.
Anmerkung:

Code:

---

104:0:1:rec/20071220001130_0_0.raw

---

Soll 104 den Dateinamen mit oder ohne Pfad zurückliefern?
Eigentlich ist der Dateiname ein Textfeld und somit in HEX zu codieren.

Edit!
Noch ein großes Problem:
Wenn ich über den Client (telnet localhost 9333) ein paar verschachtelte 204 absetze, bleibt der Client hängen. Die Debug-Anzeige des monitord zeigt an, dass der weiter auswertet, aber beim Client kommt nichts mehr an. Der monitord nimmt auch über die Client-Sitzung keine Kommandos mehr an.
Den 104 übermittelt er aber und dann kann es sein, dass alles wieder geht, oder das nichts geht oder dass Kommandos wie 299 angemommen werden aber die Alarmierungen nicht durchkommen.

viele Grüße,
Andreas

Hex kommt. Die Verschachtelung wird tatsächlich noch nicht laufen. Da ist das alte Konzept noch nicht umgestellt (Alle Clients machen nur eine Aufnahme).

Die verschachtelten Kommandos gehen nun. Tatsächlich stürzte nichts ab. Er wartete aber bis die erste Aufnahme zu Ende war, um die nächste dann zu starten :-)

Die Pfadangabe wird nun in Hexadezimaler Schreibweise ausgegeben. Ich würde sagen, daß wir den Pfad mit angeben. Man den Pfad pro Kanal einstellen (monitord.xml).

Im neuen SVN rev.237

Damit der mp3 Support auch schon mal vorsichtig gestestet werden kann habe lame-3.97 dem Repository hinzugefügt. Bleibt am Ende nur noch folgendes zu tun:

lame erstellen (configure im lame-3.97 Ordner)

monitor: configure --enable-plugins --enable-lame

Windows:
Die libmp3lame-0.dll in den monitord Ordner kopieren

Linux:
den LD_LIBRARY_PATH so anpassen, daß die libmp3lame.so gefunden und geladen werden kann.

Zusätzlich noch den Pfad zum plugin (libmplugin_audiorecorder-0.dll, bzw. libmplugin_audiorecorder.so.0.0.0 )in der monitord.xml prüfen.

Danach sollte er beim Start des monitord die Version der LAME Library ausgeben. In dem Fall dann 3.97:

Code:

---

Start Karte 0
DFromSoundIn ist: 4354368
Links
---------
Plugin-File:0=plugins/.libs/libmplugin_audiorecorder-0.dll
Plugin# 0: lade dll (Audio) aus Datei: plugins/.libs/libmplugin_audiorecorder-0.dll
done
PlugIn Audiorecorder created
enabling lame mp3 support
LAME Library imported
Using LAME Version: 3.97

Rechts
---------
Geraetenummer: 0

---

Zitat:

---

Zitat von Buebchen

den LD_LIBRARY_PATH so anpassen, daß die libmp3lame.so gefunden und geladen werden kann.

---

Ich habe auf meinem Testsystem bereits lame installiert. Ich habe in /usr/lib eine libmp3lame.so.0.0.0 und einen symbolischen Link darauf namens libmp3lame.so.0.

Eigentlich sollte ich die nutzen können, oder? Ich habe einen link angelegt:

Code:

---

ln -s /usr/lib/libmp3lame.so.0.0.0 /home/ast/monitorsvn/trunk/monitord/libmp3lame.so

---

Aber das funzt nicht.

Irgendwelche Vorschläge?

weihnachtliche Grüße vom frischen Papa.
Andreas

Ich würde das vorläufig erstmal auf Eis legen. Ich überarbeite den Teil, wie externe DLLs gelinkt werden. Die Autotools sind da nicht so trivial, wie ich das erwartet hatte. Inzwischen kann ich nachgeordnete DLLs automatisch nachladen lassen (early binding). Muss das ganze aber noch abrunden.

Ausserdem haben frische Papas ja auch noch andere Aufgaben ;-)

Ich hätte doch nochmal ne ganz andere Frage zum monitord:

Unter welcher Lizenz werden wir den denn eigentlich fortführen ? GPLv2 oder GPLv3 ? Ich würde die GPL v3 vorschlagen.

Ich schreibe gerade ein kleines Nullsoft Installer File. Da würde ich dann auch gerne schonmal eine Lizenz hinzufügen.

Wie wäre denn dieser Kopf:

Code:

---


The monitord program is released under the GPL v3

 * monitord is based on monitor by Markus Grohmann (GPL v2)
        http://www.monitor.mgrohmann.de
        (C) 1998-2002 (markus_grohmann@gmx.de)
 * monitor is based on multimon by Thomas Sailer (GPL v2)
        http://www.baycom.org/~tom/ham/linux/multimon.html
        (C) 1996,Thomas Sailer (sailer@ife.ee.ethz.ch, hb9jnx@hb9w.che.eu)

 the monitord development team
    http://www.monitord.de, (C)2007


                    GNU GENERAL PUBLIC LICENSE
                      Version 3, 29 June 2007

---

Das klingt für mich grundsätzlich gut. Wir sollten dann aber, wenn wir die Domain schon einbauen, bald auch da was stehen haben. :)
Ich bin mit GPLv3 aber sehr einverstanden.

jhr

Moin,

nachdem nun der Weihnachtsstress und die darauf folgende ziemlich eklige Erkältung (blöder Mist) so halbwegs erledigt sind, melde ich mich auch mal wieder zu Wort: Ich bin noch da ;D.

Nein, Scherz bei Seite; neben dem Neujahrswunsch an alle möchte ich loswerden, dass ich mittlerweile so weit mit meinem CMS bin, dass (z.Zt. MySQL-basierter) Login/Sessions komplett funktional sind (ja, man bekommt eine Login-Seite, wenn man den direkten URL zu einem gesicherten Inhalt einträgt, und auch die Navigation zu "sicheren" Seiten wird nicht angezeigt, wenn man nicht eingeloggt ist), Inhalte allerdings noch immer per FTP gepflegt werden müssen.
Das wird sich noch ändern, allerdings scheint mir nach den Postings hier vorrangig, die Inhalte zu erstellen. Entsprechend werde ich mich in der nächsten Zeit ersteinmal damit befassen, so dass ich hoffentlich hm... sagen wir Mitte Januar (10. wäre früh, ich halte den 15. für realistisch, da ich noch einen kirchlichen Neujahrsempfang, ein Homepage-Projekt für einen Verein und ein Jahresabschluss-Treffen für einen anderen Verein zu beharken habe) mal was zum Zeigen anbieten kann. Ich halte (leider) relativ wenig von Previews dahingehend, aber sollte jemand nicht mit dem zufrieden sein, was ich dann verbastelt habe, ist fundierte Kritik kein Problem und meine Arbeit am CMS nicht umsonst :)!

Viele Grüße
Martin

@mdi:
Schön zu hören, daß das CMS vielleicht schon in wenigen Tagen an den Start gehen könnte.

@nepomuck:
Du hast geschrieben, daß Du schon lame installiert hast. Wo liegen dann dann bei Dir die lame.h ? /usr/include/lame/lame.h ? Mir geht es darum, ob ich im Programm nur "lame.h" includen soll oder besser "lame/lame.h".

Ansonsten steht eine neue Version im SVN bereit. Die autotools und einige andere Feinheiten wollten noch "besiegt" werden. Die jetzige Version sollte nun gegen die Standardblibiotheken linken.

Die monitord.xml aus dem Unterordner monitord habe ich aus dem SVN genommen. Stattdessen habe ich einen Ordner sample-config erstellt.

Ausserdem habe ich die lbtool.m4 aus dem Unterordner m4 wieder gelöscht. Das bitte auch machen, sofern ihr die autotools mal starten solltet.

Von meiner Seite aus würde ich nun auch sagen, sind die Features, die ich brauche und komplettieren möchte im Grunde alle angelegt. Aus purem Eigennutz habe ich auch ein mySQL Plugin erstellt, daß ich auch noch in die 2.0er Version packen möchte.

Die nun vorhandenen Features würde ich dann in den nächsten Tagen noch vervollständigen und grundtesten. Danach kann dann eingentlich ein erster beta test starten, der dann die ganzen "kleinen" Fehler offenlegen wird. Eine fertige monitord Version 2.0 könnte ich mir so ab März vorstellen. Ggf auch schon im Februar. Hängt davon ab wie viele kleine Fehler noch auftreten.

Wie sieht es einer Entwicklung im Bereich Frontend aus ? Einige Ansätze habe ich schon gesehen, gelesen oder gehört. Gibt es da noch Aktivitäten ?

Bei linken fällt mir was ein, wovon ich keine Ahnung hab...
Es wird doch einige libs geben, die für den monitord nötig sind, richtig? Werden die von euch immer mitgeliefert, also irgendwie verbaut? Oder greift ihr auf libs zurück, die das System schon liefert. Ich hab da echt keine Ahnung von, bin ja kein Programmierer in dem Bereich... :)
Ich frage, weil ich eben drüber nachdachte, daraus auch ein Debian-Paket zu bauen, wenn ich Zeit habe. Dafür müsste ich dann ja Abhängigkeiten definieren...

Die Antwort hierauf darf sehr kurz sein. Wer Lust hat, kann mir aber gerne ein paar Zeilen für's Verständnis schreiben, oder ein (guten) Link geben, der mir erklärt, was ich für einen Unsinn gerade rede :)

jhr
...der sich gerade seiner Unwissenheit bewusst ist und ihrer schämt.

der "pure" monitord braucht keine besonderen Libraries. Mal abgesehen von den üblichen Verdächtigen, die der Compiler und das Betriebssystem schon mitliefert.

Anders bei der libmysqlclient und libmp3lame. Die werden beim Start des monitord (bzw. des plugins) vom system automatisch hinzugeladen.
Für Windows habe ich die ins Installerpaket hinzugefügt. Für linux nicht. Da kenne ich mich mit RPMs und .deb's auch nicht wirklich gut aus. Man könnte aber sicherlich eine Abhängigkeit zu den benötigten Paketen hinterlegen.

Wenn ich alles richtig gemacht habe wird das configure script auch meckern, wenn kein mysql und/oder lame support vom system gegeben ist.

Wichtig: lame heisst in dem Fall, daß die libmp3lame.(so|dll) gebraucht wird.

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)

Aktuelles SVN:

http://svn.monitord.de

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

Ah danke! :)

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 ?

Zitat:

---

Zitat von Buebchen

Du hast geschrieben, daß Du schon lame installiert hast. Wo liegen dann dann bei Dir die lame.h ?

---

Ich habe die Sourcen von Lame gar nicht auf der Maschine. Nur die fertige Library in /usr/lib.

Andreas

Zitat:

---

Zitat von nepomuck

Ich habe die Sourcen von Lame gar nicht auf der Maschine. Nur die fertige Library in /usr/lib.

Andreas

---

Die lib heist aber libmp3lame.so, richtig ?

Dann versuch vor dem configure ein

Code:

---

export CPPFLAGS="-Ilame-3.97/include"

---

Dann sollte er die lame.h aus dem svn nehmen. Lame erstellen brauchst du dafür nicht.

Moin,

ich habe mal eine Frage zu der MySQL-Plugin-Geschichte:

Legt das Plugin selber Tabellen an wenn die nicht da sind? Wenn nein - wie sollen die denn aussehen bzw. ist es möglich, die notwendigen Table-Definitionen hier als SQL-Queries abzulegen um sie generieren zu können ohne dass ich mir die Infos aus dem Code klauben muss? Würd das auch gern mal ausprobieren und entsprechend auch als Info auf die Webseite bappen :).

Viele Grüße
Martin

Die Tabelle wird nicht erstellt. Ebensowenig wie die Datenbank. Das würde ich auch eher als Aufgabe des Frontends sehen.

das plugin ist variabel gehalten. Es liest seine Konfig aus der monitord.xml.

Pro Meldungstyp (pocsag,zvei,fms) gibt es einen mapping Bereich, der Tabelle und Feldzuordnungen definiert. Das posten von XML Dateien ist ja nicht so toll. Deswegen schau mal in den Ordner sample-config rein. Da kann man das einsehen.

Felder sehen so aus:

a) <field name="..feldname-sql"> ..feldname-resultset <field>
b) <field name="..feldname-sql" source="mysql" "> NOW() <field>

a) Weist dem mysql-Feld den Inhalt des Resultset-Felds zu
b) Würde dem mysql-Feld den Funktionswert NOW() zuweisen.

Eine Konstante würde so gehen:

c) <field name="..feldname-sql" source="mysql" "> "FIXWERT" <field>

Hallo,

OK; das habe ich dann doch so weit verstanden, scheint mir :).

Nach entsprechendem Bau von Tabelle und Mapping stoße ich jetzt jedoch darauf, dass ich zwar korrekte Login-Daten in der monitord.xml angebe, der monitord aber weiterhin versucht, als root zu connecten.

Der Fehler ist in der monitord.xml zu finden; das Feld heißt nicht "login" sondern "username". Ich habe die sample-config-Dateien angepasst.

Martin

Ups :-)

Stimmt. Ich hatte zuerst login angedacht. Fand ich dann aber ungeeignet und habs geändert. Hatte gedacht, ich hätte die samples auch angepasst. Nun ja. So kann man sich irren *schäm*

Hallo Zusammen,

Die Version 0.3 des Monitor-Protokolls ist fertig. Das PDF mit der aktuellen Dokumentation liegt auf:

ftp://andi.rw-labs.de/pub/Monitor%20Protokoll%2003.pdf

Änderungen:

OK: 100/200
Nur noch wenige Kommandos werden per OK bestätigt (@Buebchen)

Inquiry: 111/211
Liefert nun eine mehrzeilige Antwort und kann somit mehrere Paramter wie z.B. mehrere zur Verfügung stehende Protokollversionen angeben (@Buebchen).
Liefert zudem eine Liste der aktiven Module auf dem Server/Client (@Nepomuck)

Login: 220
Braucht nun als dritten Paramter eine vom Client gewünschte Protokollversion (@Nepomuck). Ohne diese Erweiterung macht der erweiterte Inquiry keinen Sinn.

Recording: 104
Liefert Dateinamen *MIT* Pfadangabe (@Buebchen)

ZVEI-Alarm: 300
Übermittelt am Ende ein Textfeld (@Buebchen)

Pocsac: 320
Datenfelder definiert 320:{Zeit}:Kanalnummer:RIC:Subadresse:Text (@Buebchen)

Falls ihr Fehler findet oder weitere Änderungen braucht, lasst es mich wissen.

Andreas
PS: Wie sieht's eigentlich mit einer Dokumentation zum Format der monitord.xml aus?

Moin,

Zitat:

---

Zitat von nepomuck

PS: Wie sieht's eigentlich mit einer Dokumentation zum Format der monitord.xml aus?

---

der Versuch einer Anleitung:
http://www.monitord.de/index.php?article=3 (noch nicht offiziell, aber ich denke, hier im Forum kann mans schon mal zeigen).

Martin

Also mir gefällt das Ergebnis vom CMS schon !

Für die XML-Dateien habe ich auch ein hübsches Tool, um das farbig zu machen: Hightlight Code Converter von www.andre-simon.de

Nehme gerne für Dokumentationen :-)

Hallo nochmal,

Auf meinem FTP-Server liegt ein Testfile für ZVEI- und FMS-Funktionen zum Download:

ftp://andi.rw-labs.de/pub/fmszveitest.mp3

Das Ganze wurde mit dem BOS-Tool erstellt und besteht aus zwei Komponenten:

ZVEI: Die Testserie beginnt mit einer Reihe von Schleifen mit allen möglichen Sirenentönen. Stand heute dekodiert Monitor die verschiedenen DTFM-Töne noch nicht korrekt.
Anschliessend folgt eine Reihe einzelner Schleifen ohne Wiederholung. Nach den Ziffern 1-9 enthalten diese Schleifen auch die Sonderzeichen A, J, F und U. Diese Schleifen kann der monitor aktuell auch noch nicht dekodieren. Es folgt eine Serie nummerischer Schleifen mit Wiederholung. Die ZVEI-Testserie beendet eine 00000 mit Entwarnungston.

FMS: Am Angang gehen zwei Textmeldungen raus, dann folgen alle Statusmeldungen vom umd zum Fahrzeug. Und am Ende kommen zwei Meldungen mit einem fünfstelligen Folgetelegramm. Die letzten Telegramme dekodiert Monitor noch nicht korrekt.

Das Test-MP3 ist Stereo. Am Anfang kommt der ZVEI-Test rechts und FMS links, später wiederholen sich beide Test auf den jeweils anderen Kanälen.

viel Spass beim Testen,
Andreas

Was genau sollte denn rauskommen ?

Er wertet bei mir haufenweise ZVEI und FMS aus. Da ich das Soll nicht kenne, kann ich das Ist nicht bewerten :-(

Was sind z.B. bei FMS die letzten Telegramme, die er nicht erkennt. Die würde ich sonst selbst im BOS-Tool nachbauen.

Zitat:

---

Zitat von Buebchen

Was genau sollte denn rauskommen ?

---

Hier der "Bauplan" der Testdatei.

ZVEI:
00000 ohne Folgeton, 00000 Melderton 1, 00111 Feuer, 00112 Test, 00113 Zivilschutzalarm, 00114 Zivilschutzwarnung, 00115 Zivilschutzentwarnung, 00222 Melderton 2
bis hierhin alle Schleifen doppelt. Dann einzeln:
00123, 00234, 00345, 00456, 00567, 00678, 00789, 00890, dann einige Schleifen mit den Sonderzeichen A, C, H, U, L und J, gefolgt von 00111 Test. (MDI erwähnte mal, er wolle die Sondertöne dekodieren und nutzt einzelne Schleifen oder Wiederholung, daher habe ich sie in die Testalarmierung eingebaut)

Dann wieder doppelt: 00111, 00122 bis 00199 ohne Melderton und 00000 Zivilschutzentwarnung als Abschluss.

FMS:
Zwei Mal FMS-Kurztest "Franz jagt im verwahrlosten Taxi quer durch Bayern" an Fahrzeug: 63915401 mit Erreichbarkeitsanfrage, Quittung etc.
Dann FMS-Staus 1 bis 15 zur Leitstelle von Fahrzeug 63915401 mit Quittung und Wiederholung mit Baustufe 2 und TKI I.
Dann FMS-Status A bis u zum Fahrzeug ebenfalls mit Quittung und Wiederholung, Baustufe 2 TKI I.
Das BOS-Tool wiederholt bei einigen Statusmedlungen das Telegramm nicht -- keine Ahnung warum.
Abschliessend mehrfach FMS-Folgetelegramme mit ABCDEF oder 12345 als Folge (werden nicht dekodiert).

Andreas

Ah. Also ZVEI lass ich für mich mal aussen vor. Ich würde dann bei FMS schauen. Da geht alles bis auf die Folgetelegramm Fzg->Lst ?

hihi das finde ich ja mal ganz interessant. Das gleiche würde mich mal für Pocsag interessieren. Ich würd sagen bei mir hat so zu 90 % alles richtig decodiert. :-)

Hallo Andreas,

Zitat:

---

Zitat von nepomuck

ZVEI: Die Testserie beginnt mit einer Reihe von Schleifen mit allen möglichen Sirenentönen. Stand heute dekodiert Monitor die verschiedenen DTFM-Töne noch nicht korrekt.

---

vorweg: Cooles Testfile, gut gemacht :)!

Die Sirenentöne werden nun korrekt erkannt (Rev. 279/SVN).

Die Sonderzeichen sind aber noch immer nicht implementiert :´(.
Ich habe mich eben damit befassen wollen - allerdings stoße ich auf das Problem, sie hinterher auszugeben. Die ZVEI-Folge ist als "text5" im Protokoll spezifiziert, erlaubte Zeichen sind aber nur A-F, womit J, U und so weiter rausfallen würden. Was tun? Möglich wäre ein "Mapping" (A=A, B=H, C=C, D=J, E=L, F=U - wobei das P wegfallen würde), was haltet Ihr davon? Oder kann man in dem Feld direkt das Zeichen angeben (z.B. 8A0J6)?

Letzte Änderung:
Ich hatte ab und an Probleme mit der Stereo-Auswertung der ZVEI-Tonfolgen. Warum auch immer. Vielleicht war ich doch nur zu blöd, das Mikro abzuschalten.

Martin
PS: Und nochwas, ich kriege bei der Ausgabe nicht mehr "Kanal 2", wie in der monitord.xml eingetragen, sondern "1" als Kanalbezeichnung.

Zitat:

---

Zitat von Buebchen

Ich würde dann bei FMS schauen. Da geht alles bis auf die Folgetelegramm Fzg->Lst ?

---

Korrekt. Da wir hier noch kein FMS verwenden kann ich dir aber nicht sagen, ob diese Funktion in der Praxis überhaupt genutzt wird.

Zitat:

---

Zitat von stadel21

Das gleiche würde mich mal für Pocsag interessieren.

---

Läßt sich einfach realisieren (zumindest mit meinem Setup):
Linux-Box mit VMWare. Unter VMWare läuft Windows mit BOS-Tool. Der Linux Mixer stellt den REC-Eingang auf Volume, folglich nimmt der Audiorecoder das auf, was die Soundkarte ausgibt :-)
Unter Linux Audiorecorder starten und Aufnehmen, in der Windows-VM mit dem BOS-Tool die Test-Sounds generieren. Die Demo des BOS-Tools steigt zwar immer wieder aus, aber das macht nichts. Die fertige Aufzeichnung des Audiorecorders läßt sich später mit Audacity oder anderen Tools zusammenschneiden.

Auf die Tour liesse sich auch ein Pocsac-Testfile generieren. Sagt mir Bescheid, wenn ihr sowas braucht und was drin sein soll.

Zitat:

---

Zitat von mdi

Die Sirenentöne werden nun korrekt erkannt (Rev. 279/SVN).

---

Das ging ja Superflott! Ich werde es gleich testen.

Zitat:

---

Zitat von mdi

erlaubte Zeichen sind aber nur A-F, womit J, U und so weiter rausfallen würden. Was tun?

---

Ich habe im Netz gesucht und das hier gefunden:

Code:

---

ton ZVEI1    ZVEI2
1  1060 Hz  1060 Hz
2  1160 Hz  1160 Hz
3  1270 Hz  1270 Hz
4  1400 Hz  1400 Hz
5  1530 Hz  1530 Hz
6  1670 Hz  1670 Hz
7  1830 Hz  1830 Hz
8  2000 Hz  2000 Hz
9  2200 Hz  2200 Hz
0  2400 Hz  2400 Hz
E/W 2600 Hz  970 Hz
A/N 2800 Hz  885 Hz
C  810 Hz  810 Hz
H  885 Hz  2800 Hz
U  1750 Hz  1750 Hz
L  1860 Hz  1860 Hz
J  2135 Hz  2135 Hz
P  2280 Hz  2280 Hz

---

Du könntest den Dekoder so programmieren, dass er sowohl 2600 als auch 970 Hz als W(iederholungston) akzeptiert und die Buchstaben "A" als 2800 Hz und "H" als 885 Hz dekodiert. Dann beherrscht Monitor sowohl ZVEI-1 als auch ZVEI-2, wobei ein ZVEI-2-Anwender wissen muss, dass unser Programm dabei A und H vertauscht.

Oder wir setzen es "Super Korrekt" um und führen einen Switch in der monitord.xml ein:

für ZVEI-1 wie gehabt

Code:

---

(module type="zvei")
(/module)

---

und für ZVEI-2

Code:

---

(module type="zvei2")
(/module)

---

Wobei fraglich ist, ob das in der Praxis überhaupt irgendjemand braucht.

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Oder wir setzen es "Super Korrekt" um und führen einen Switch in der monitord.xml ein:

für ZVEI-1 wie gehabt

Code:

---

(module type="zvei")
(/module)

---

und für ZVEI-2

Code:

---

(module type="zvei2")
(module)

---

Wobei fraglich ist, ob das in der Praxis überhaupt irgendjemand braucht.

viele Grüße,
Andreas

---

oder vielleicht noch eleganter:

Code:

---

(module type="zvei")
(zveitype) 2 (zveitype)
(/module)

---

Denn der Rest vom Modul ist doch m.E. identisch. Ändert sich nicht nur die Frequenztabelle ?

Heyho,

das hier genannte "Problem" ist sicherlich auch ein interessantes, aber es geht erstmal um die Ausgabe der erkannten Zeichenfolge...

Bisher waren das nur Zahlen, so isses auch im monitord-Protokoll problemlos integrierbar. Nun kommen aber Buchstaben "größer als" F hinzu, die angezeigt werden müssten. Das hat mit ZVEI-1 oder ZVEI-2 erstmal nix zu tun. Die Frage ist, ob ich die Zeichenkette "8AJHP" so am Socket ausgeben kann oder ob das codiert werden muss, was dann natürlich mehr Zeichen draus machen würde. Oder bin ich auch dem falschen Dampfer und es wird eh alles codiert und decodiert?

Weiterhin muss ich feststellen, dass das mit den Zeichen noch ein wenig dauern wird, da dafür ein Umsetzen der Frequenz zum auszugebenden Zeichen notwendig wird, das muss ich mir aber in Ruhe überlegen, wie das am sinnvollsten/optimalsten zu implementieren ist.

Martin

Zitat:

---

Zitat von Buebchen

oder vielleicht noch eleganter:
(zveitype) 2 (zveitype)

---

Auch gut. Wenn der Paramter zveitype fehlt, sollte monitord automatisch zvei-1 dekodieren.

Zitat:

---

Zitat von mdi

Nun kommen aber Buchstaben "größer als" F hinzu, die angezeigt werden müssten.

---

Kapiert. Da es sich aber nur um ein paar wenige Sonderzeichen handelt, würde ich die im Klartext (Großbuchstaben) ausgeben.
Also Ja: Gib "8AJHP" am Socket aus und ich ändere dir Protokolldoku für 0.4 dementsprechend ab.

Zitat:

---

Zitat von mdi

Weiterhin muss ich feststellen, dass das mit den Zeichen noch ein wenig dauern wird

---

Ich glaube, wir können dieses Feature mit geringer Priorität behandeln. Außer dir selbst hat bisher noch kein Monitor-Anwender nach den ZVEI-Sonderzeichen gefragt.
Aber wenn wir diese Funktion schon implementieren, dann halt richtig und mit allen Zeichen.

viele Grüße,
Andreas
PS: Sirenenerkennung funktioniert prima. Dazu aber noch eine aktuelle, wichtige Änderung im Protokoll:

Bisher lautete die Syntax für den Sirenen-Paremter des 300er-Codes:
0 ohne Sirene / Melderauslösung, 1 Feueralerm, 2 Probelalarm, 3 Zivilschutz, 4 Warnung, 5 Entwarnung

Da der Dekoder jetzt aber einen Unterschied zwischen Schleifen ohne und mit Weckton macht, gilt für diesen Paramter folgendes:
0 ohne Sirene, 1 Melderauslösung, 2 Feueralerm, 3 Probelalarm, 4 Zivilschutz, 5 Warnung, 6 Entwarnung.

Hallo zusammen!

Mit großen Interesse verfolge ich ja nun schon einige Zeit, was hier so passiert. Das eine oder andere sagt mir was, vieles davon leider nicht. Mag ja an meiner mangelnden Zeit liegen...

Jetzt wollte ich mal meinen Monitor eine wenig modernisieren.

Ich hab nur kein Plan was ich wie wo anstellen soll. Nun hab ich schonmal versucht rauszufinden
was SVN ist, aber so richtig schlau bin ich nun auch nicht.

Daher die Frage: Gibt es eine Anleitung wie ich mir aus eurer Arbeit einen Monitor bauen kann?
Vielleicht so eine für Noobs :-) ?
Leider hab ich noch nicht eine Idee wo ich anfangen könnte. Was ich kenne ist runterladen, auspacken, make laufen lassen und gucken wo's hängt ;-) Hab hier übrigens ein Ubuntu 7.10 jungfreulich.

Daher würde ich mich freuen wenn ihr mir vielleicht den einen oder anderen Tipp geben könnt,
wo ich am besten Anfange.

Danke!

Bubu

svn ist die Abkürzung zu subversion; das sollte dir bei der Suche weiterhelfen. :) Im Großen und Ganzen ist svn da, um Versionierung vorzunehmen. Einer lädt was hoch und anstatt das vom vorherigen zu überschreiben wird (mehr oder weniger) eine Kopie davon angelegt und dafür ein Zähler hochgezählt. Man hat also alle Entwicklungsstände (Revisionen) gespeichert und kann jederzeit zurück etc.

Aktuell entwickelt wird ein monitord. Das heißt, der "neue monitor" hat kein Frontend, sondern läuft als Deamon und gibt die Daten auf einen IP-Port aus. Neue Frontends müssen noch erstellt werden, um die Daten dann da abzugreifen. Das ermöglicht mehr Flexibilität, insbesondere, da monitord dadurch netzwerkfähig geworden ist. Ich weiß aber nicht, ob es dir gerade weiter hilft... :D

jhr

Habe im ersten Langzeitlauf noch ein Speicherleck entdeckt. (GlobalDispatcher hat die Resultsets nicht gelöscht, nur aus der Queue entfernt). Im SVN gefixt.

@mdi:
monitord-setup.exe steht auch gleich bereit.

hallo,

hab mal ne frag wie ich monitor richtig Konfiguriere. ICh möchte das bei einer bestimmten 5Tonfolge ein Programm, eine Sound Datei und das die 5 Tonfolge aufnehmen. In welche datei muss ich das genau reinschreiben?
weiß jetzt nicht ob des hier reingehört aber mit dem wiki bin ich einfach nicht weiter gekommen

mfg skyfire

Dieser Thread passt nicht ganz zu deiner Frage, da es hier um die Entwicklung des Nachfolgers geht (Version 2.0)

Die Antwort auf Deine Frage findest Du in der manpage zur monrc. Du musst die Datei .monrc bearbeiten. Eine ältere Version als PDF findest zu hier: http://www.funkmeldesystem.de/foren/...2&d=1124750750

Auf Seite 11 sind die Aktionen beschrieben (ZVNAME)

danke und viel spass noch an monitor 2