monitor 1.9.0 - aber richtig :)

Moin,

ich habe mal ein minimales Frontend gebaut, das die monitord-Ausgaben in Klartext umbastelt (mit der convert-Klasse von Buebchen aus den monitord-Sourcen) und sortiert auf Tabs ausgibt. Es bietet nicht viel, aber das sollte hoffentlich reichen um die Ausgaben nicht mehr im telnet enträtseln zu müssen ;).

Sourcecode und Binary mit wxWidgets-DLLs liegen zum Download bereit unter http://www.monitord.de/index.php?article=5 - die Web-Präsenz braucht noch ein bisschen Feinschliff und kann dann hoffentlich bald "öffentlich" online gehen.

@Buebchen:
Der neue Installer liegt da auch schon.

Martin

Moin,

leider produziert der Aufruf des exe nur die Fehlermeldung mit dem Ruf nach der mingwm10.dll

Gruß,
Funkwart

Zitat:

---

Zitat von funkwart

Moin,

leider produziert der Aufruf des exe nur die Fehlermeldung mit dem Ruf nach der mingwm10.dll

Gruß,
Funkwart

---

der monitord.exe ?

Moin,

nein, sicher mein Frontend.

Fix ist hochgeladen, neues Zip-Archiv online.

Martin

Jipp, danke funktioniert!

Hi,

wollte eben mal monitor installieren!
Klappt auch, bis ich es starten will:

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.


In der /proc/asound/cards sagt er:

0 [A5451 ]: ALI5451 - ALI 5451
ALI 5451 at 0x8400, irq 5

Also Soundkarte ist vorhanden (und hat mit dem "alten" monitor ja auch funktioniert.)

Ne Idee?

Ich würde mal so starten:

hast du nen Ordner /dev/snd mit Devices drin ? Dann ist also ja korrekt installiert.
Dann fehlt nach meiner Einschätzung die OSS Unterstützung.

Entweder Du installierst diese für deine Distro nach oder aber ändert /dev/dsp0 man zum testen in /dev/snd/pcmC0D0c in der monitord.xml. Könnte dann auch gehen.

Zitat:

---

Zitat von mdi

ich habe mal ein minimales Frontend gebaut

---

Da geht bei mir gar nix. Ich starte das Frondend, gebe die Server-IP an und sehe in "Other" die OK-Meldung des Servers -- das wars.
Auch wenn ich den monitord mit Alarmierungen bombardiere, das Frontend zeigt nichts an, eine Telnet-Verbindung zum Server auf Port 9333 hingegen listet alles auf.

Ich hab es auf einer VM mit XP Prof. und einer physischen Maschine mit XP MCE probiert.

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Da geht bei mir gar nix. Ich starte das Frondend, gebe die Server-IP an und sehe in "Other" die OK-Meldung des Servers -- das wars.
Auch wenn ich den monitord mit Alarmierungen bombardiere, das Frontend zeigt nichts an, eine Telnet-Verbindung zum Server auf Port 9333 hingegen listet alles auf.

Ich hab es auf einer VM mit XP Prof. und einer physischen Maschine mit XP MCE probiert.

viele Grüße,
Andreas

---

Das telnet machst Du vom gleichen Client aus ? Ansonsten wartet der monitord auf einen Login. Das kannst Du in der monitord.xml anpassen.

Moin,

dass da die OK-Zeile kommt heißt ja (genau wie Buebchen vermutet hat), dass die Verbindung grundsätzlich steht aber man nix zu sehen kriegt, weil kein Login erfolgt (das kann das Ding nicht).

Also sehe ich als sinnvoll an, folgende ToDos zu erkennen:
a) Das Mini-Frontend muss Username und Passwort abfragen und sich entsprechend am monitord anmelden können.
b) Der monitord muss zum Login auffordern.

a) baue ich ein, wie wäre b)? Ich selber bin auch schon mehrmals an der Sache gescheitert, dass ich eine IP-Einstellung falsch gesetzt habe und mir der monitord nicht kund tut, dass ein Login notwendig wäre, von daher hielte ich den Hinweis durch den monitord für eine gute Sache, was meint Ihr dazu?

Martin

Zitat:

---

Zitat von mdi

dass da die OK-Zeile kommt heißt ja (genau wie Buebchen vermutet hat), dass die Verbindung grundsätzlich steht aber man nix zu sehen kriegt, weil kein Login erfolgt

---

Korrekt, das war mein Fehler

Zitat:

---

Zitat von mdi

Der monitord muss zum Login auffordern.

---

Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Korrekt, das war mein Fehler


Das Protokoll sieht hier nichts vor. Ich habe den Sonderfall, dass sich Clients ohne Login verbinden dürfen nicht berücksichtigt.

Ich würde das folgendermassen umsetzen. Wenn die Verbindung steht sendet dein Client ein "202" (Keepalive) an den Server. Wenn ein 100 (OK) als Antwort zurückkommt, darf der Client ohne Login eine Verbindung aufnehmen (Infobox: Verbindung steht). Bekommt er hingegen ein 101:001 zurück (Fehler: Not logged in), dann muss dein Programm ein Fenster öffnen und Benutzernamen und Passwort abfragen.

@Buebchen: Wie weit sind hier die Protokolländerungen von 0.3 umgesetzt? Kennt der monitord schon den Login mit Protokollversionsparamter? Ist 202 komplett implementiert?

viele Grüße,
Andreas

---

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

So, jetzt habe ich auch mal ein paar Zeilen Code geschrieben!
Der ist zwar nicht besonders toll, sollte uns aber beim Entwickeln etwas helfen.

ftp://andi.rw-labs.de/pub/bosix/poni.pl

"Poni", das Perl Monitor Frontend, stellt eine Verbindung zu einem Monitor-Server her und gibt die ankommenden Alarme in lesbarer Form auf der Kommandozeile aus -- mehr macht das Tool im Moment nicht.

Bei den Tests mit Poni (und dem BOS-Tool auf der Gegenseite) ist mir was aufgefallen:

Pocsac geht hier nur mit 512 Baud, 1200 Baud-Alarme werden nicht angezeigt.
Bei nummerischen Pocsac-Alarmen übermittelt Monitor die Ziffern im Klartext und nicht Hex-Kodiert. Der Client kann aber nicht wissen, ob was Alphanummerisches (Hex-codiert) oder was nummerisches (nicht HEX-codiert) ankommt.
Hier sollte Monitor auch die nummerische Ausgabe HEX-Kodieren, dann können die Clients das Text-Feld pauschal durch den HEX-Dekodierer jagen.
Oder wir müssen ein zusätzliches Feld "Alarmtype" beim Kommando 320 einführen, so dass der Client weiss was ihn erwartet.

viele Grüße,
Andreas

Schlechten Perl-Code schreiben macht Spass!

Ich habe gleich noch was nachgelegt: einen Mini-Client der Alarme im CSV-Format in separate Dateien schreibt und eine kompakte Darstellung auf dem Schirm ausgibt.

Das Perl-Programm ponilog.pl wertet die poni.cfg-Datei aus, um die Infos zum Server, Port etc. zu erhalten. Tool und Demo-Config liegen auf
ftp://andi.rw-labs.de/pub/bosix/

viele Grüße,
Andreas

Hi,

zuerst mal danke für die Antwort!

Zitat:

---

Zitat von Buebchen

Ich würde mal so starten:

hast du nen Ordner /dev/snd mit Devices drin ? Dann ist also ja korrekt installiert.

---

Ja, existiert.

Zitat:

---

Dann fehlt nach meiner Einschätzung die OSS Unterstützung.

---

Kann eigentlich auch nicht sein, ein "cat /proc/asound/oss/sndstat" bringt:

Code:

---

Installed drivers:
Type 10: ALSA emulation

Card config:
ALI 5451 at 0x8400, irq 5

Audio devices:
0: ALI 5451 (DUPLEX)

Synth devices: NOT ENABLED IN CONFIG

Midi devices: NOT ENABLED IN CONFIG

Timers:
7: system timer

Mixers:
0: Conexant Cx20468 rev 1,Conexant

---

Zitat:

---

Entweder Du installierst diese für deine Distro nach oder aber ändert /dev/dsp0 man zum testen in /dev/snd/pcmC0D0c in der monitord.xml. Könnte dann auch gehen.

---

Selber Fehler leider. :(

Code:

---

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

---

Zitat:

---

Zitat von Max K.

Hi,

Code:

---

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

---

---

Müßte da jetzt nicht /dev/snd/pcmC0D0c stehen ? Muss mir mal den Linux Alsa Teil angucken ... Da scheint die Konfig nicht zu funktionieren.

Hi,

klar, stehts auch. ;-) Habe nur die Fehlermeldung ausm 1. Beitrag kopiert, damit der Bezug schnell ersichtlich ist.

Zitat:

---

Zitat von Buebchen

Bisher habe ich am neuen Protokoll noch nichts umgesetzt :-( Ich hab's aber auch noch nicht komplett gegengelesen...

---

So. Versuche da jetzt mal beim Login weiter zu kommen. Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

Ich könnte jetzt zwei Wege gehen:

a) Im configure.ac werden nur noch Zahlen mit einer Nachkommastelle als Programmversion genutzt
b) Wir lassen als Programmversion auch Text zu und können auch wie bisher svn / stable / dev / beta / sonstige Text als Version im configure.ac eintragen.

Spontan halte ich sowas für einen reinen Infotext. Oder wird der Client jemals mit dem "Versionswert" rechnen ? Interessant ist doch die Protokollversion für ihn. Ob das nun ein 2.1a oder 2.2svn monitord ist ist doch eher uninteressant und mehr etwas als Information für den Benutzer, oder ?

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ? Denn das ist im Moment noch nicht weiter definiert und ich möchte mich noch nicht festlegen, wie und wo die Modulnamen festgelegt sind.

Wenn nicht, ist die Antwort vorläufig:

Code:

---

111:5:"[leer]"

---

Kleiner Fehler in der Protokollversion 0.3 (Seite 3, Beispiel für Logins):

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

Zitat:

---

Zitat von Buebchen

Was mir noch nicht gefällt ist die Geschichte mit der Programmversion. Die würde ich eigentlch am liebsten aus dem configure.ac ziehen. Da steht zur Zeit 2.0svn drin. Das wiederum passt natürlich nicht zum definierten Protokoll.

---

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

Zitat:

---

Zitat von Buebchen

Kann die Antwort 111:5:"[Module]" auch vorläufig entfallen ?

---

So hatte ich das gedacht. 111:5 kann entfallen oder mehrfach vorkommen. Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

Zitat:

---

Zitat von Buebchen

Ein Login mit unbekannter Version sollte m.E. nicht mit 101:004 (Protokollfehler, nicht verstanden) beantwortet werden, sondern mit 101:008 (Versionsfehler)

---

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

Der Parameter ist -- wie du schon sagst -- reiner Infotext, da können wir eigentlich machen, was wir wollen. Ich ändere die Protokolldefinition für 0.4 ab, so dass der Paramter Programmversion ein Textfeld wird.

Bei der Protokollversion möchte ich allerdings das vierstellige nummeriesche Feld lassen, wenn's dir recht ist.

---

das vierstellige Protokollfeld finde ich so prima. Das sollte ruhig bleiben.

Zitat:

---

Zitat von nepomuck

Da wir 111:0 als Ende-Kommando festgelegt haben, weiss der Client wann die Inquiry-Antwort fertig ist und wird nicht vergeblich auf ein 111:5 warten.

---

Prima. So hatte ich mir das auch vorgestellt. Dann lass ich das vorläufg erstmal weg.

Zitat:

---

Zitat von nepomuck

Ich hatte 008 als Fehler der Programmversion und 004 als Fehler der Protokollversion gedacht. Ein Login mit falschem Protokoll ist demnach ein Protokollfehler und kein Problem der Softwareversion. Oder ist das unlogisch?

viele Grüße,
Andreas

---

Ich, glaube dann stehe ich auf dem Schlauch :-)

Ein Login mit falschem Format (kein Protokollwunsch oder fehlendem Passwortfeld, oder nur "220:" ) wird jetzt doch mit 101:004 (nicht verstanden) beantwortet - richtig ?

Ein Login mit passender Protokollversion aber falschem Benutzernamen oder Password mit 101:003 (incorrect login)

Aber wie beantworten wir einen Login mit richtigen Benutzerdaten und nicht passender Protokollversion ? Bei 101:004 könnte man vom 1. Fall nicht unterscheiden.

Deswegen hätte ich dann intuitiv 101:008 genommen. Dann kann dem User als Meldung gesagt werden, daß die Protokollversion geändert werden muss. Die Anmeldedaten sind zu dem Zeitpunkt ja noch ungeprüft.

Die eigentliche Programmversion sollte m.E. für die Kommunikation unerheblich sein. Da ist aus meiner Sicht nur die Protokollversion entscheidend.

Zitat:

---

Zitat von Buebchen

Ein Login mit falschem Format (kein Protokollwunsch oder fehlendem Passwortfeld, oder nur "220:" ) wird jetzt doch mit 101:004 (nicht verstanden) beantwortet - richtig ?

---

Wir können für so etwas ja auch einen "Client-Software-Programmierer-unfähig"-Fehler einführen :-)

Scherz beiseite: du hast recht, es gibt keine Unterscheidung zwischen Protokoll fehlerhaft verwendet und Protokollversion falsch. Also nehmen wir wie vorgeschlagen den 008 als Protokollversionsfehler und den 004 als Protkollbenutzungsfehler, ok?

Falls wir im weiteren Verlauf noch einen eigenen Fehlercode für den Server an sich benötigen, erweitern wir einfah die Protokolldefinition.
Andreas

Moinmoin,

ich wollte nur mal ein kurzes Lebenszeichen von mir geben: Ich habe zur Zeit Prüfungen und dem entsprechend deutlich weniger Zeit, mich um die monitord-Sache zu kümmern. Ist nicht vergessen und ich bin noch da! :).

Martin

Zitat:

---

Zitat von Max K.

Hi,

Code:

---

ALSA lib pcm.c:2102:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
monitord: pcm.c:663: snd_pcm_close: Assertion `pcm` failed.
Aborted.

---

---

Das Problem existiert leider nach wie vor.

-ALSA-Soundkarte ist korrekt eingerichtet
-Soundausgabe auf /dev/dsp funktioniert

Jemand ne Idee? Weil alle anderen Programme haben keinerlei Probleme..

Moin,

Mal 'ne grundsätzliche Frage:

Zitat:

---

Zitat von Buebchen

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.

Zitat:

---

Zitat von Buebchen

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

Zitat:

---

Zitat von nepomuck

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.

Zitat:

---

Zitat von nepomuck

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.

Zitat:

---

Zitat von nepomuck

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.

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

Zitat:

---

Zitat von mdi

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 ... :-)

Moin,

a) und b) sind klar :).

Bei c) ist aber das Problem - in MSYS kriege ich den MySQL-Raffel nicht gebaut und wäre da für einen Hinweis sehr dankbar. Versucht habe ich auch cross compiling von meinem Ubuntu aus... da aber MySQL auch nach Konsultation von Foren und Bugtrackern augenscheinlich nicht cross compilierbar ist, starb auch dieser Weg.

Ich habe einen neuen Branch angelegt (/branches/2.0-ZVEIrewritten-mdi), der meine Änderungen enthält. Die Sirenentonerkennung ist da noch nicht vorhanden. Da ich annehme, dass es weniger Zeit kostet, diesen Branch einmal auszuchecken und einen Installer daraus zu bauen (sofern man das passende Environment erstmal hat) als herauszusuchen und zu veröffentlichen, was alles zu ändern ist, möchte ich Dich genau darum bitten: Checkst Dus einmal aus, kompilierst es mit mysql und lame und lässt mir den Installer zukommen? Wär mir wichtig, da bald weiterzukommen, weil ich den mysql-Support durchaus auch nutzen möchte und sehr angetan bin davon - da ist es echt nervig, wenn mans nicht selber kompilieren kann weil $Ding fehlt aber man nicht herausfindet, welches ;).

Ansonsten kurz was ich eben noch gemacht habe:
1. Installation der Libraries aus dem aktuellen Installer von mysql.
2. reimp -d libmysql.lib
3. dlltool -k --input-def libmysql.def --dllname libmysql.dll --output-lib libmysql.a

Fehler ist:
checking for mysql_init in -lmysql... no
configure: error: --with-mysql was given, but test for mysql failed

Ich würd mich da sehr über einen Hinweis freuen, denn irgendwie ist das "bisschen" unbefriedigend so :7.

Viele Grüße
Martin

Zitat:

---

Zitat von mdi

Fehler ist:
checking for mysql_init in -lmysql... no
configure: error: --with-mysql was given, but test for mysql failed

Ich würd mich da sehr über einen Hinweis freuen, denn irgendwie ist das "bisschen" unbefriedigend so :7.

Viele Grüße
Martin

---

Benenn mal während des configure die libmysql.a um, daß sie nicht gefunden wird. Seltsamerweise klappt sonst der Test vom configure nicht ... k.A. warum. Aber auch im Moment nicht so wichtig. Das configure braucht man ja nicht so oft.

[Edit]
ich gehe mal davon aus, daß LDFLAGS richtig gesetzt ist :-)

Moin,

gerade umbenannt - selber Fehler.

Zitat:

---

Zitat von Buebchen

ich gehe mal davon aus, daß LDFLAGS richtig gesetzt ist :-)

---

Hm, was ist "richtig"? Ich habe mich bisher zwar nicht von C/C++ und dem Drumherum fern gehalten, aber da fehlts mir echt noch an Wissen :7.

Martin

Um bei einem configure Lauf die -L Parameter des gcc zu setzen nutzt man die Umgebungsvariable LDFLAGS

Code:

---

z.B. LDFLAGS="-L/lib -L/igendwo/lib"

---

Wenn da die libmysql.dll nicht drin ist wird es vermutlich fehlschlagen. Ich werde heute abend aber vielleicht wieder Zeit finden mein MSYS anzuwerfen. Dann kann ich mal meine Parameter "mitschreiben", die ich für den Build nutze.

Moin,

Zitat:

---

Zitat von Buebchen

Wenn da die libmysql.dll nicht drin ist wird es vermutlich fehlschlagen.

---

*mich in die Ecke stell und schäm*.

Martin

PS: Danke! Manchmal sieht man den Wald vor lauter Bäumen nicht :7.

Moin,

ich habe ja neulich geschrieben, dass ich den ZVEI-Decoder nochmal überarbeitet hätte. Das ist mittlerweile so weit durch und im SVN (Rev. 293). Proben haben gut funktioniert; die Erkennung sollte jetzt bisschen sicherer laufen (weil ich in einem sieben Buckets breiten Puffer 4x dieselbe Frequenz in Folge erkennen will um das codierte Zeichen zu erkennen).

Viele Grüße
Martin
PS: @Stefan, ich habe gesehen, dass die Lame-Sourcen komplett mit im SVN zu liegen scheinen, ist das a) eine wahre Aussage und soll das b) so sein?

Zitat:

---

Zitat von mdi

Viele Grüße
Martin
PS: @Stefan, ich habe gesehen, dass die Lame-Sourcen komplett mit im SVN zu liegen scheinen, ist das a) eine wahre Aussage und soll das b) so sein?

---

a) Ja
b) Vorläufig ja (insbesondere unter Windows gibt es kein lame-devel Paket, da müßte das makefile sonst einen sinnvollen Hinweis geben, wie man an die richtigen Sources kommt)

Moinmoin,

da ich die Sourcen erst später "entdeckt" (naja, realisiert) habe, bin ich folgenden Weg gegangen für den Lame:

a) Download der Sourcen von http://lame.sourceforge.net/download.php
b) Entpacken in ein beliebiges Verzeichnis
c) in MSYS: ./configure im entsprechenden Verzeichnis
d) in MSYS: make
e) in MSYS: make install

Tat problemlos.

Viele Grüße
Martin

Ist schon klar, daß das geht. ich denke halt, daß ein Entwickler sowas hin bekommt. Der "normale User" wird da schon schwierigkeiten bekommen. Insbesondere da eben noch kein Hinweis auf Notwendigkeit des zusätzlichen Downloads vorhanden ist. Ansonsten würde auch die lame.h fehlen. Und die braucht man natürlich auf jeden Fall :-)

Ich befasse mich gerade damit wie man automake dazu bewegt rekursiv zu arbeiten. Dann könnte man im configure prüfen, ob der lame sources ordner gefüllt ist und da zusätzlich das configure ausführen. Ebenso könnte man sonst einen Hinweise bringen.

Deswegen meinte ich ja auch, daß es vorläufig erstmal so bleiben sollte. Weniger für die Unix, aber mehr für die Windows User :-)

Hallo schon wieder ;),

Zitat:

---

Zitat von Buebchen

Ist schon klar, daß das geht. ich denke halt, daß ein Entwickler sowas hin bekommt. Der "normale User" wird da schon schwierigkeiten bekommen. Insbesondere da eben noch kein Hinweis auf Notwendigkeit des zusätzlichen Downloads vorhanden ist. Ansonsten würde auch die lame.h fehlen. Und die braucht man natürlich auf jeden Fall :-)

---

das stimmt, die ist allerdings auch mit im lame-src-Paket enthalten. Bisschen fummelig ist das Ganze eh, spätestens wenn man sich MySQL-Support bauen möchte. Aber ich muss insofern zustimmen als das bisher nirgendwo erwähnt ist.

Zitat:

---

Zitat von Buebchen

Deswegen meinte ich ja auch, daß es vorläufig erstmal so bleiben sollte. Weniger für die Unix, aber mehr für die Windows User :-)

---

*g* - ja, ok; mir fiel eben gerade ein, ob es denn überhaupt User gibt, die sich den Kram selber kompilieren, wenn sie den Aufwand scheuen, sich ein entsprechendes Build-Environment zu bauen. Da wäre ich mittelfristig dafür, nur noch die monitord-Sourcen in /trunk zu haben und entsprechende Hinweise anzubringen, dass für die Plugins etwas fehlt. Für Entwickler sollten wir dann dann eine Anleitung (vorläufig in http://www.funkmeldesystem.de/foren/...ad.php?t=35783) und für die User zum Download fertige Binaries/Installer im Komplettpaket einschließlich Plugins bereitstellen.

Ist das mehrheitsfähig? :D

Martin

Es herrscht mal wieder gespenstische Stille im Forum.
Seid ihr alle noch da? Geht was vorwärts oder droht das Projekt Monitord 2.0 einzuschlafen?

viele Grüße,
Andreas

Moin,

ich bin noch da, ab und an ;).

Martin

...das ist sehr schön.
Interessanter wäre natürlich eine Antwort auf die Frage, ob noch jemand aktiv an dem Projekt arbeitet?
Es ging ja sehr schnell mit sehr vielen Dingen los, aber ganz plötzlich tut sich (nach außen) so gut wie nichts mehr.
Entwickelt Ihr alle fleißig oder habt Ihr aufgegeben?

Gruß,
Funkwart

Also ich für meinen Teil habe im Moment recht viel auf der Arbeit zu tun. Da leidet dann doch die Motivation auch noch in der Freizeit zu programmieren. Ausserdem habe ich die wxWidgets entdeckt (da das einige hier auch verwenden) - da hatte ich dann auch noch Zeit investiert (wie ich denke war das keine so schlechte Idee :-) ).

Ich lade dann doch immer wieder mal den Source. Aber wirklich viel daran arbeiten tue ich zur Zeit ehrlich gesagt nicht. Aber da mir das ganze sehr am Herzen liegt wird das bei mir nicht sterben, sondern liegt nur eine Zeit lang auf Eis.

Als ruhig weiter Ideen posten. Wird dann irgendwann umgesetzt werden :-)

PS: Und zu guter letzt hat mich ein Freund auch noch auf World of Warcraft aufmerksam gemacht. Was man da an Zeit verbringen kann ... Ne Ne Ne ...

Ich seh's den Tag kommen... Die Software ist perfekt; jede Kleinigkeit ist durchdacht; es gibt kein Klicken mehr auf dem BOS-Funk, das nicht entschlüsselt und sachgemäß verarbeitet wird... und dann ruft der Ortsbrandmeister an und meldet sich mit den Worten: "Endlich ist es soweit: der Digitalfunk wird morgen aktiviert - nie wieder Scannerkids!" ;-)

jhr

Zitat:

---

Zitat von jhr-online

und dann ruft der Ortsbrandmeister an und meldet sich mit den Worten: "Endlich ist es soweit: der Digitalfunk wird morgen aktiviert

---

Ich glaube, das dauert noch ein paar Jahre. In unserer Region soll Tetra zwischen 2011 und 2014 kommen. Theoretisch könnten dann alle drei Dienste POL, RD und FW sofort umstellen.
Ich zweifle daran aber stark. Die Grundausbaustufe Tetra sieht vor, dass der Funkverkehr nur außerhalb von Gebäuden funktioniert. Somit läßt sich über Tetra nicht zuverlässig alarmieren (das geht nach meinem Wissensstand erst ab der zweiten Stufe mit mehr Funkmasten). Zudem werden die Landkreise nicht auf einmal hunderte Piepser und dutzende Sirenensteuerungen austauschen.
Also selbst wenn Tetra schon 2011 kommt, werden wir ein paar Jahre das 4m-Netz zumindest für die Alarmierung weiter betreiben.
Bei uns kommt 2009 erst einmal FMS und bis dahin sollte der Monitor 2.x hoffentlich zuverlässig arbeiten :-)

Andreas

Moinmoin,

ich formuliere es von meiner Seite einmal so: "Meine" ZVEI-Komponente scheint relativ zuverlässig ihren Dienst zu tun (jedenfalls tut sie das bei meiner Installation hier seit mehr als 50 Tagen im Dauerbetrieb mit Datenbankanbindung durch das MySQL-Plugin). Entsprechend habe ich jetzt keinen großen Einsatz mehr gezeigt, daran noch etwas zu ändern, sofern nicht gravierende Bugs gemeldet werden.

Ich habe mich ein wenig damit befasst, einen minimalistischen Client zu bauen (da ist noch offen, wie und ob der im SVN erscheinen soll oder ob nicht) und bin langsam nebenbei dabei, für "meinen Verein" ein Modell einer GUI basierend auf wxWidgets zu entwickeln. Das geht aber recht langsam zur Zeit, weil andere Dinge einfach Vorrang haben (die Einsatz-Saison mit Laufveranstaltungen und dergleichen hat begonnen).

Es wäre schön, wenn wir nochmal darstellen würden, was jetzt eigentlich direkt noch fehlt (ich erinnere mich dunkel an ein nicht vollständig implementiertes Protokoll auf Serverseite, ist das noch richtig?) für die 2.0 - allerdings nehme ich recht stark an, dass wohl vor allem ein Client sowie die History-Funktion am wesentlichsten sind, richtig?

Viele Grüße
Martin

Zitat:

---

Zitat von mdi

"Meine" ZVEI-Komponente scheint relativ zuverlässig ihren Dienst zu tun

---

Mal abgesehen von einer meiner Testmaschinen (Thinkpad T43p mit Ubuntu 7.10 x86) wo die ZVEI-Komponente nach wie vor Zahlendreher liefert, während 1.8.1 auf der selben Kiste funktioniert. Aber so lange der Fehler nirgendwo anders auftritt, kann man das wahrscheinlich nicht nachvollziehen.

Zitat:

---

Ich habe mich ein wenig damit befasst, einen minimalistischen Client zu bauen

---

Da sehe ich aktuell den größten Bedarf. Hier müßte es doch möglich sein, das bestehende, altmodische aber zuverlässige Text-Frondend der 1.8.1 zu übernehmen. Vieleicht sogar so, das die bestehende .monrc mit minimalen Änderungen weiter funktioniert.

Zitat:

---

die Einsatz-Saison mit Laufveranstaltungen und dergleichen hat begonnen).

---

RD? Kardia 1-4?
Irgend eine Saison ist doch immer. Bei uns (FW) beginnt in Kürze die "Sommerreifen-anständig-Probefahren"-Saison, die nahtlos an die Kaminbrand-Saison anschließt.

Zitat:

---

Es wäre schön, wenn wir nochmal darstellen würden, was jetzt eigentlich direkt noch fehlt

---

- Frontend
da wäre es schön, wenn einer was systemunabhängiges in Java schreiben könnte. Ein netter Display-Client mit Logbuch und Event-Triggeriung.
- Pocsac (hat noch keiner richtig getestet, speziell 1200er)
- History-Funktion im Server
- Vollständige Protokoll-Implementierung (mit Inquiry, Versionsverhandlung und rec-Funktion)
- Vereinfachte Installation (ohne ./configure --with dies --ohne jenes --modulesoderauchnicht)
- evtl. sogar mit Binary Installer (win) oder Packetmanager (linux deb, rpm)
- Das Ganze auf einer direkt startfähigen Live-CD (Bosix 0.2)

viele Grüße,
Andreas

Zitat:

---

Zitat von nepomuck

- Pocsac (hat noch keiner richtig getestet, speziell 1200er)

---

Läuft hier seit mehreren Wochen problemlos im Dauerbetrieb mit der aktuellen SVN Version als Testobjekt.

Zitat:

---

Zitat von DocSteel

Läuft hier seit mehreren Wochen problemlos im Dauerbetrieb mit der aktuellen SVN Version als Testobjekt.

---

Toll. Ein Punkt weniger auf der Liste. Danke für die Info.
Was nimmst du als Frontend?

Andreas

Also POCSAG mit 512 Baud läuft hier auch schon seit vielen Wochen ohne zu murren (SVN, Windows 2k3 Server als Dienst). Frontend ist selbstgehäkelt und extrem minimalisitisch ( aber immerhin web-basiert :-) ). Selbst kurzfristige Verbindungsunterbrechung zum MySQL Server machten ihm nichts mehr aus.

Zitat:

---

Zitat von nepomuck

Toll. Ein Punkt weniger auf der Liste. Danke für die Info.
Was nimmst du als Frontend?

Andreas

---

Ein minimales PHP Frontend was die SQL DB abfragt und das ganze dann farbig unterlegt und ausgibt mit Auto Refresh und lauffähig auf iPhone und Nokia Handys.

Eine kleine Sache stört aber noch: da ich hier 2 Digis höre (einen schwach einen sehr klar) wird manchmal der schwache ausgewertet und dann der starke nicht mehr so das die Meldungen ab und an mit abgeschnittenem Text in der DB stehen. Wäre schön wenn sich dafür eine Lösung finden würde.