Jack the Grabber

Hallo z3r0,

ich bin's mal wieder.
Nach längerer pause habe ich mir wieder mal einen neueren Build gegönnt, nachdem ich jetzt einige Zeit erfolgreich mit der Version 0.2.9e gearbeitet habe.

Leider ist die neue Version ein Rückschritt für mich, weil nun eine Aufnahme mit udrec.exe überhaupt nicht mehr funktioniert. Musste ich bei version 0.2.9e bereits die beiliegende udrec Version gegen eine ältere (v0.12k) austauschen, weil ansonsten immer folgender Fehler unter mono (v1.0.6 und v1.1.4) auftrat:

Unhandled Exception: System.Net.Sockets.SocketException: Not enough buffer space is available
in <0x001a4> Record:UdpReceiver ()
in <0x00070> (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()

so wird nun in XMG Version 0.3.0e selbst bei Einsatz der älteren udrec Version jeder Aufnahmeversuch mit folgender Meldung quittiert:

22:41:45:497 INFO XMediaGrabber 0.3.0e
22:41:45:539 INFO 17.03.2005
22:41:45:541 INFO User: xxxx
22:41:45:544 INFO java.version 1.4.2_05
22:41:45:555 INFO java.vendor Apple Computer, Inc.
22:41:45:559 INFO java.home /System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Home
22:41:45:567 INFO java.vm.name Java HotSpot(TM) Client VM
22:41:45:892 INFO Suche Box-Image...
22:41:46:066 INFO Neutrino-Schnittstelle geladen
22:41:46:097 INFO Warte auf Eingaben von xx.xx.xx.xx Port: 4000
22:41:46:147 INFO Sende Nachricht zur Box
22:41:53:180 INFO Anwendung gestartet
22:41:58:349 INFO ermittle Pids
22:42:00:256 INFO mono /Users/xxx/Desktop/Downloads/XMediaGrabber_030e/udrec.exe -host xx.xx.xx.xx -now -pes -o /Users/xxx/05-03-23/Sliver -buf 16 -tcp 31340 -udp 31341 -vp ff -ap 100
22:42:01:232 INFO udrec 0.12n by Harald Maiss (www.haraldmaiss.de)
22:42:01:254 INFO
22:42:01:285 INFO unknown option
22:42:01:303 INFO ------- known options: ------------------------------------------------
22:42:01:306 INFO -time 01.01.03 10:00 11:00 recording times
22:42:01:322 INFO -to udp data timeout with -time (10 sec)
22:42:01:323 INFO -tv 1 3 record tv + zapit bouquet, channel
.... usw.

Das Komische ist, dass wenn ich die Aufrufzeile 1:1 aus dem XMG Log rauskopiere, ins Terminal paste und ausführen lasse, dass es dann einwandfrei funktioniert. Aus irgendeinem Grund ist also die Parameterübergabe aus der aktuellen XMG Version heraus gestört.

Mir fiel auch auf, dass Leerzeichen, die im Ausgabepfad enthalten sind (z.B. in den Sendernamen oder im Titel oder der Pfad zu udrec.exe) nicht Plattform-konform kodiert werden, also z.B. "Wort1\ und\ Wort2" anstelle von "Wort1 und Wort2", da letzteres als drei getrennte Parameter verstanden werden würde.

Wäre toll, wenn der gestörte udrec-Aufruf und die falsch kodierten Blanks in allen Pfadangaben gefixt werden könnten. Mit einer älteren udrec Version kann ich gut leben (wenn sie denn angesteuert werden kann).

Ansonsten finde ich die Idee mit der plug-In Schnittstelle grandios. Bin schon auf die Spezifikation der Schnittstelle gespannt.

RobieZ

Hallo z3r0,

habe es eben mit der brandneuen 0.3.0f Version getestet. Genau das selbe Verhalten wie in der Vorgängerversion.

RobieZ

Hallo z3r0,

ich habe mir gerade nochmals diesen älteren Thread zum Thema XMG, Mac OS X und udrec durchgelesen:
http://www.jackthegrabber.de/viewtopic.php?t=6084

Denkst Du es wäre möglich, die von Chinaschnitte angesprochene neue udrec-Option

-urb (udp receive buffer size in bytes)

zu integrieren so dass Mac OS X Anwender auch wieder in den Genuß aktueller udrec Versionen kommen können. Da ich nicht weiß wie groß der Puffer sein darf bevor die oben aufgeführte Fehlermeldung erscheint, wäre es wohl nötig die Puffergröße als Option veränderbar zu machen.

Beim Herumspielen mit udrec im Terminal fiel mir auf, dass ungültige Aufrufparameter in der Form

"unknown option falscher_parameter"

aufgelistet werden. Da im XMG Log nichts hinter "unknown option" steht (siehe oben), vermute ich das Problem entweder in der Kodierung der Leerzeichen zwischen den einzelnen Parametern oder in einer falsch kodierten Zeilenschaltung am Ende des Aufrufs (beides wären "unsichtbare" Zeichen).

Ich hoffe, das erleichtert die Fehlereingrenzung.

Frohe Ostern,

RobieZ

Ganz so einfach ist das leider nicht, da fehlt mir ein Mac dazu. Unter Linux funktioniert es, unter einem Mac funktionierte es eigentlich auch schon mal, und es wurde an der Stelle eigentlich nichts geändert. Die Kodierung der Leerzeichen übernimmt komplett Java, bzw. das Betriebssystem. Schade das udrec hier nicht den ungültigen Parameter ausgibt. Wie sieht es aus, wenn du einen Aufruf aus XMG startest, und in diesem Aufruf keine Leerzeichen vorkommen?

Wie soll die urb-Angabe in der Gui aussehen? Was sind da für Werte möglich?

z3r0 hat geschrieben:Schade das udrec hier nicht den ungültigen Parameter ausgibt.

Und wenn es eben doch ein "unsichtbares" störendes Zeichen ist? Wie ich ja schon schrieb kann ich den gesamten Aufruf 1:1 aus dem XMG Log kopieren und ins Terminal pasten. Dann klappt es problemlos. Es kann also kein ungültiger Parameter im eigentlichen Sinne sein, sonst würde es ja im Terminal auch nicht funktionieren. Und somit kann udrec auch nichts anzeigen. Ist aber nur eine Theorie.

Wie sieht es aus, wenn du einen Aufruf aus XMG startest, und in diesem Aufruf keine Leerzeichen vorkommen?

Ist doch bereits geschehen. Wenn Du nochmal einen Blick auf das erste Posting oben wirfst, dann ist darin folgender Auszug aus dem Log zu finden:

22:42:00:256 INFO mono /Users/xxx/Desktop/Downloads/XMediaGrabber_030e/udrec.exe -host xx.xx.xx.xx -now -pes -o /Users/xxx/05-03-23/Sliver -buf 16 -tcp 31340 -udp 31341 -vp ff -ap 100

Darin kommt kein Leerzeichen vor.

z3r0 hat geschrieben:Wie soll die urb-Angabe in der Gui aussehen? Was sind da für Werte möglich?

Nun , es gibt jetzt ja schon ein paar einstellbare udrec Optionen wie z.B. -vsplit oder -asplit. Wäre es nicht möglich auch -urb als weiteren Parameter mit aufzunehmen? Der Wert "-1" würde dann wieder bedeuten, dass der Paramter deaktiviert ist und ansonsten muss ein mindestens siebenstelliger Zahlenwert eintragbar sein (wenn Byte als Einheit verwendet wird). Welche Werte unter Mac OS X und Mono 1.1.4 noch zulässig sind, werde ich mal im Terminal austesten und dann hier preisgeben.

RobieZ

So, habe es gerade mal ausprobiert. In Verbindung mit der udrec 0.12n (welche XMG 0.3.0f beiliegt), kann ich hier unter Mac OS X.3.8 und Mono 1.1.4 einen -urb Parameter mit Werten bis maximal 230000 erfolgreich einsetzen.
Wenn ich darüber gehe (z.B. 235000), dann erhalte ich wieder den gewohnten Fehler:
Unhandled Exception: System.Net.Sockets.SocketException: Not enough buffer space is available
in <0x001a4> Record:UdpReceiver ()
in <0x00070> (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()

RobieZ

Hallo z3r0,

habe eben Version 0.3.g installiert und ausprobiert. Saubere Arbeit. Der Parameter -urb taucht in den udrec Optionen auf und wird bei mir auch korrekt als Parameter an udrec übergeben. Hier der Auszug aus dem log:

14:52:09:396 INFO mono /Users/xxx/Desktop/Downloads/XMediaGrabber_030g/udrec.exe -host xx.xx.xx.xx -now -pes -o /Users/xxx/Folder/Test -urb 200000 -buf 16 -tcp 31340 -udp 31341 -vp 1ff -ap 200 -ap 201 -ap 203

Leider erhalte ich aber weiterhin die Meldung, dass eine "unknown option" im Aufruf verwendet wurde, so dass ich trotz neuer -urb Option udrec nicht nutzen kann.

Ich weiß, dass ich jetzt ziemlich wild spekuliere aber ist Dir auch aufgefallen, dass hinter dem Parameter -udp 31341 oben zwei Leerzeichen im Log erscheinen, wogegen alle anderen Parameter nur mit einem Leerzeichen voneinander getrennt sind? Kann es sein, dass sich hier der Fehler eingeschlichen hat und Du hinter dem -udp Wert ein ungültiges Zeichen mit ausgibst (ASCII 0 oder sowas)? Auch hinter dem letzten -ap Parameter steht im Log noch ein Leerzeichen. Auch hier könnte potentiell im eigentlichen Aufruf ein ungültiges Sonderzeichen stehen.
Wie gesagt reine Spekulation. Aber meistens sind es ja solche trivialen Fehler die einen Entwickler in den Wahnsinn treiben.

RobieZ

Warum eigentlich eine "alte" udrec-Version?
Hat das einen bestimmten Hintergrund?

Hallo DrRamoray,

ja, weil aktuelle udrec Versionen (wohl ab 0.12m) ohne Verkleinerung des udp-Puffers nicht unter Mac OS X und Mono 1.0.5 or 1.1.4 zum Laufen zu bringen sind. Dies ist aber nur durch Angabe des -urb Parameters möglich, der bislang aber nicht von XMG unterstützt wurde. Erst der brandneue 0.3.0g Built bietet dies.

Bist Du Mac OS X Anwender? Läuft bei Dir udrec in einer aktuellen Version unter Mac OS X und XMG? Wenn ja, dann verrate mir bitte wie Du das geschafft hast.

RobieZ

Nee, bin kein Mac-ler.

weil aktuelle udrec Versionen (wohl ab 0.12m) ohne Verkleinerung des udp-Puffers nicht unter Mac OS X und Mono 1.0.5 or 1.1.4 zum Laufen zu bringen sind

Najo, -urb ist seit der 0.12m implmentiert, aber N kommt nach M, aber soll mich als Win-ler nicht weiter stören ich kopiere dann halt immer die aktuelle udrec 0.12o rein.

14:52:09:396 INFO mono /Users/xxx/Desktop/Downloads/XMediaGrabber_030g/udrec.exe -host xx.xx.xx.xx -now -pes -o /Users/xxx/Folder/Test -urb 200000 -buf 16 -tcp 31340 -udp 31341 -vp 1ff -ap 200 -ap 201 -ap 203

Diese Ausgabe dient eigentlich nur zu Informationszwecken. Den eigentlichen Aufruf erledigt Java. Ich übergebe für den Aufruf ein String-Array von Optionen. Java kuemmert sich auch darum, das die Leerzeichen je nach Plattform richtig codiert werden, baut den Aufruf auf, und statet diesen. Ich kann also eigentlich garnicht sagen wie die Parameter rausgehen und bei udrec ankommen. Evtl. kann Harald (udrec-Entwickler) eine Debug-Version bauen. Es würde erstmal vollkommen reichen, die eingehenden Parameter auszugeben.

Hast du in letzter Zeit etwas an der Java-Installation geändert?

Hallo DrRamoray,

Nee, bin kein Mac-ler.

Das dachte ich mir

Najo, -urb ist seit der 0.12m implmentiert, aber N kommt nach M, aber soll mich als Win-ler nicht weiter stören ich kopiere dann halt immer die aktuelle udrec 0.12o rein.

Deshalb schrieb ich ja auch im ersten Posting:

Musste ich bei version 0.2.9e bereits die beiliegende udrec Version gegen eine ältere (v0.12k) austauschen,...

denn K kommt vor M

RobieZ

z3r0 hat geschrieben:Hast du in letzter Zeit etwas an der Java-Installation geändert?

Nein.
Das wäre meiner Meinung nach auch an der falschen Stelle gesucht, denn warum läuft dann eine 0.2.9e Version ohne dieses Problem trotz selber Java Version und Konfiguration? Irgendetwas muss also doch laut Code der nachvollgenden XMG Versionen anders übergeben werden. Kannst Du nicht mal einen Compare des entsprechenden Codeabschnitts der 0.2.9e Version mit der aktuellen Version durchführen?

Würdest Du Harald bzgl so einer Debug Version kontaktieren oder soll ich das tun?

RobieZ

Tjo, ich wollte ja nur wissen warum udrec-N beim aktuellen XMG mitgeliefert wird , wenn O aktuell ist ?