monitor 1.9.0 - aber richtig :)

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

[mdi]

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

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

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

[mdi]

Hallo schon wieder ;),

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.

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

[nepomuck]

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