monitor 1.9.0 - aber richtig :)

[Buebchen]

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.

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.

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.

[nepomuck]

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

[mdi]

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

[Max K.]

Hi,

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

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

[mdi]

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

[Buebchen]

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

[mdi]

Moin,

gerade umbenannt - selber Fehler.

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

[Buebchen]

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

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.

[mdi]

Moin,

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.

[mdi]

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?

[Buebchen]

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)