monitor 1.9.0 - aber richtig :)

[Buebchen]

Bei mir arbeitet die Version ohne Plugin (auf dem Thinkpan mit Ubuntu 7.10 32Bit). Mit Plugin stürzt Monitord mit einem Segmentation Fault ab. Ich probiere das gleich noch auf der 64-Bit-Plattform.

Poste da bitte mal die letzten Ausgaben vor dem SegFault. Unter meinem Ubuntu 6.06 (32Bit) klappt das Probleme. Vermutlich kann er die Plugins nicht laden (Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

Der 203 liefert aktuell immer 8 Kanäle zurück, auch wenn nur zwei in der Config stehen.

Oh. da war die Debugeinstellung noch nicht wieder raus. Jetzt werden wieder nur aktive Karten angezeigt. Was später noch in der Doku aufgeführt werden muss: Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht. Dann würde das herunterzählen nicht funktionieren. Die Kanale 2 und 3 würden fehlen.

Die Zvei-Alarme kommen mit einem 320. Der sollte aber für Pocsac zuständig sein (und wir haben noch keine Syntax dafür). Zvei sollte aber einen 300 auslösen.
Der 300er (momentan 320) gibt noch Text als Sirenencode zurück, das Protokoll sieht eine nummerische Ausgabe vor.

Die 320 ist jetzt in 300 geändert (jaja, cut & paste :-) ). Der Weckton ist numerisch vorhanden. Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen. Der Grund ist ganz einfach: Ein ggf. irgendwann zentral verfügbares Modul kann da auch noch den Namen des Empfängers oder sonstiges hinzufügen. Generell bin ich in fast allen Produkten die ich betreue der Meinung, daß ein Freitext Feld immer vorhanden sein sollte. Man kann sich zu Beginn oft nicht vorstellen, was der Benutzer später gerne noch als kleinen Hinweis hinterlegen möchte (und was tatsächlich sinnvoll ist).

Für POCSAG wäre die Struktur:

320:{Zeitangabe}:{RIC}:{Subadresse}:{Text}

Die Unterscheidung Nur-Ton, Numerisch und Alphanumerisch ist auf der Empfängerseite relevant, wie er die Daten anzeigt. Im POCSAG Code unterscheiden sie sich nur darin, ob nach dem Adresswort noch Datenworte folgen oder nicht. Hier würde es sich für den monitord Client also daran unterscheiden, ob der Text leer ist oder nicht.

Wir sollten uns noch ein Paar xml-Paramter für die Config ausdenken, mit der wir Pfad und Dateinamen für die Aufnahme steuern.

Bis auf Kleinigkeiten (z.B. ein Präfix) würde ich den Dateinamen in der Version 2.0 so lassen.

In der Version 2.1 kann man dann z.B. noch eine zweite Datei schreiben, die die Daten zur Aufnahme enthält (Welcher Client hat es angefordert, ggf. ein Freitext vom Client, Dauer, Start, Ende , ...).

Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

[nepomuck]

Noch ein Beitrag zum Kommunikationsprotokoll:
Bei der Channel-Info (Kommando 203) sollte noch ein Bit 2^3 eingefügt werden. Damit man 2^2 für 512Baud POCSAG und 2^3 für 1200 Baud POCSAG nehmen kann.

Übernehme ich in das Protokoll wie vorgeschlagen

Inquiry (Kommando 210,110):
Macht es Sinn die Antworten zu "quittieren" ?

Das ist tatsächlich nicht nötig. Ich ändere Die Dokumentation entsprechend und streiche die Quittung bei den Kommandos, die darauf verzichten können.

Bei den Aufnahmekommando könnte man ggf. bei einer Antwort, daß die Aufnahme schon läuft, bzw. die Aufnahme beendet ist, noch die geplante (gesamte) Aufnahmedauer mitgeben.

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.

(Die Plugins sind als eigene Dateien ausgelagert und werden zur Laufzeit dazugeladen).

OK. Da liegt wahrscheinlich der Fehler. 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"?

Man darf niemals eine Karte "überspringen". Also nicht die erste und dritte aktiv schalten, die zweite aber nicht.

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.

Die 320 ist jetzt in 320 geändert

das ändert alles :-)

Danach habe ich einen Text ergänzt. Den bitte zum Protokoll hinzufügen.

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?
Die Pocsac-Struktur übernehme ich ins Protokoll wie vorgeschlagen.

... würde ich den Dateinamen in der Version 2.0 so lassen ...
Pfadangabe ist selbstredend notwendig. Werde ich einpflegen.

Damit können alle gut leben.

Das überarbeitete Protokoll poste ich im Laufe der nächsten Tage,
Grüße,
Andreas

[Buebchen]

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.

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.

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.

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.

[nepomuck]

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.

Ich sende dann ein ":" ohne nachfolgenden Text.

So im Protokoll vermerkt.

viele Grüße,
Andreas

[Buebchen]

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.

[nepomuck]

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

[Buebchen]

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