Jack the Grabber

Nachdem das bisherige udrec unter .Net 2.0 und höher eine Systemauslastung von 100% erzeugt hat, habe ich mir mal die Mühe gemacht das Ganze auf den neusten Stand (d.h. .Net 3.5) zu bringen:

http://www.haraldmaiss.de/udrec0.13rc11.zip

Wer ohnehin das .Net-Framework 1.1 installiert hat, kann weiterhin die alte Version verwenden:

http://www.haraldmaiss.de/udrec0.13beta.zip

tonsel

Thx! Schade, das ich meine Dbox noch nicht im Netzwerk habe, sonst würde ich direkt mal testen.

cu
Jens

Hallo tonsel,

erstmal vielen Dank und dann gleich zwei Fragen dazu:

Das dotNet 3.5 ist bisher nur in englisch erschienen.
Verträgt sich das mit in deutsch installierten, kleineren Versionen?

Ist dotNet 3.5 zwingende Voraussetzung für udrec0.13rc11?

.NET Framework 3.5 - Full Redistributable Package:
http://download.microsoft.com/download/ ... etfx35.exe

Gruß Frank

Hallo tonsel,

vielen Dank für die neue Version.
Du hattest mal geschrieben, das Du eine Version für .NET 2 ebenfalls schon kompiliert hattest.
Könntest Du diese auch zur Verfügung stellen?

saggi

*edit*
Oder besser erst mal die aktuelle unter NET 2 testen

Hallo,

hier rennt die
udrec 0.13rc11

unter Windows XP mit den folgenden installierte .Net-Versionen:

.NET-Version: v1.1.4322
.NET-Version: v2.0.50727

bis jetzt fehlerlos.

Gruß

Hallo,

bestätigt auch von mir:

.NET-Version: v1.1.4322
.NET-Version: v2.0.50727

udrec-CPU-Last: 0,8% - 2% während der Aufnahme.

Super!

saggi

Mich würde interessieren, ob es unter einem taufrischen Vista OHNE .Net 1.1 jetzt geht. Das kann ich leider nicht testen.

tonsel

Hallo,ich habe zwar kein Vista, aber ich hab gerade den RC1 von W2008Server in einer VM-Ware laufen. Da bringt Udrec immer den u.a. Fehler. Er kommt auch wenn man UDREC als Administrator ausführt. Die Firewall und IPV6 ist abgeschaltet. Virenscanner ist auch keiner drauf.

Ich weiss ein RC1 und und eine VM-Ware sind nicht gerade DIE Testumgebung, aber vielleicht hilft es weiter.

JTG-Info sagt folgendes über die Umgebung:

Code: Alles auswählen

Betriebssystem: Microsoft Windows NT 6.0.6001 Service Pack 1, v.667
Installierte .Net-Versionen:
	.NET-Version: v2.0.50727
Installierte Jet-Versionen:
	Jet-Version: 4.0

Und hier die Udrec-meldung beim Start einer Aufnahme.

Code: Alles auswählen

C:\Users\jeppdot\Downloads>udrec -ss -host 192.168.10.25
17:53:02 listening to any host on port 4000
17:53:30 Record.Start: can't establish network connection
System.Net.Sockets.SocketException: Es konnte keine Verbindung hergestellt werde
n, da der Zielcomputer die Verbindung verweigerte ::1:31340
   bei System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddr
ess socketAddress)
   bei System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   bei Record.Start()
17:53:30 listening to any host on port 4000

Gruß

Dieses Problem kann eigentlich nur an der Netzwerkonfiguration liegen, denn an der betreffenden Stelle habe ich im Code nichts geändert. Warum die DBox auf den Tcp-Verbindungsversuch auf Port 31340 verweigert, weiß ich im Augenblick allerdings nicht.

Bitte ausprobieren:
- Was passiert mit der alten Version von udrec für .Net 1.1?

- Wenn Du udrec ohne "-host" startest müsste der gleiche Fehler kommen?

tonsel

Hallo,

- Was passiert mit der alten Version von udrec für .Net 1.1?

Die verhält sich genau gleich zu rc11.

- Wenn Du udrec ohne "-host" startest müsste der gleiche Fehler kommen?

Ohne den Schalter "-host" funktioniert es einwandfrei. Bei beiden Versionen.

Ich installiere das OS nochmal komplett neu, und versuche direkt wie von dir gewünscht nur Net 3.5 draufzupacken.

Das Ergebnis melde ich dann.

Gruß

ich installiere das OS nochmal komplett neu, und versuche direkt wie von dir gewünscht nur Net 3.5 draufzupacken.

Nicht notwendig - ich wollte ja wissen ob's in der Standardkonfiguration funktioniert, d.h. nur mit .Net 2.0.

Ohne den Schalter "-host" funktioniert es einwandfrei. Bei beiden Versionen.

Der Schalter -host sollt in diesem Fall eigentlich keine Wirkung haben, da immer die IP genommen wird, von der das Startkommando kommt. An der Stelle ist anscheinend noch ein Programmfehler.

EDIT:

Ich hab es bei mir nochmal ausprobiert: Die obige Fehlermeldung kommt bei mir, wenn die IP-Adresse unter -host falsch ist. Bei Angabe der korrekten IP gehts bei mir.

tonsel

Also ich denk mal das dies ein Problem der VM-Ware Bridge ist.

Die IP-Adresse ist definitiv richtig.

Einen schönen Rest vom Jahr

Verfasst: **Di 15 Jan 2008, 9:36**

Hi Tonsel,

ich wollte nur vielen Dank sagen, dass Du eine neue udrec Version erstellt hast

)

Ich werde gleich mal testen, ob sie evtl. auch gegen mein "SPkt buffer overflow" Problem hilft.

cu, Relaff

Verfasst: **Di 15 Jan 2008, 11:13**

Hi nochmal,

so, jetzt habe ich das neue udrec mal ausprobiert ... es liefert mir allerdings etliche Fehlermeldungen vom Typ "sync block too long ":

Code: Alles auswählen

C:\Programme\XMediaGrabber\tools\udrec.exe -host 192.168.1.200 -udp 31341 -tcp 31340 -now -es -o E:\08-01-15 10_25 PREMIERE 3 test\test -buf 16 -idd -rm -vp 8ff -ap 900 -ap 901 -ap 903
10:25:06 INFO - 10:25:06 to DBox: VIDEO 31341 16 0 1 vaaa 8ff 900 901 903
10:25:07 INFO - 10:25:07 from DBox: INFO: IP c0a8011f Port 31341
10:25:07 INFO - 10:25:07 from DBox: PID vaaa 4 8ff 900 901 903
10:25:07 INFO - 10:25:07 to DBox: START
10:25:07 INFO - 10:25:07 from DBox: INFO: UdpSender() - PID573 R0 W0
10:25:07 INFO - 10:25:07 from DBox: INFO: DmxReader() - Pid 8ff 204960 0 0
10:25:07 INFO - 10:25:07 from DBox: INFO: DmxReader() - Pid 900 29280 0 0
10:25:07 INFO - 10:25:07 from DBox: INFO: DmxReader() - Pid 901 29280 0 0
10:25:07 INFO - 10:25:07 from DBox: INFO: DmxReader() - Pid 903 29280 0 0
10:25:37 INFO - 10:25:37 found video stream (e0)
10:25:37 INFO - 10:25:37 found mp2 stream (c0)
10:25:37 INFO - 10:25:37 found mp2 stream (c0)
10:25:37 INFO - 10:25:37 MP2 PES: sync block too long (473960 bytes)

Dann folgen noch ein Haufen "sync block too long" und irgendwann kommt dann das Ende der Aufnahme und das Log zeigt folgendes:

Code: Alles auswählen

10:28:00 INFO - 10:28:00 to DBox: STOP
10:28:00 INFO - 10:28:00 network statistics:
10:28:00 INFO - max:      4,9 Mbit/s total data rate
10:28:00 INFO - average:  3,8 Mbit/s total data rate
10:28:00 INFO - no resends
10:28:00 INFO - 10:28:00 TcpSender stopped
10:28:00 INFO - 10:28:00 from DBox: EXIT
10:28:00 INFO - 10:28:00 UdpReceiver stopped
10:28:00 INFO - 10:28:00 TcpReceiver stopped
10:28:07 INFO - 10:28:07 MP2 PES: sync block too long (603281 bytes)
10:28:07 INFO - 10:28:07 MP2 PES: sync block too long (294560 bytes)
10:28:07 INFO - 10:28:07 found mp2 stream (dd)
10:28:07 INFO - 10:28:07 24:58:17.66: video resync
10:28:10 INFO - 10:28:10 KeyboardRecordControl stopped
10:28:10 INFO - 10:28:10 ESSync stopped - no stream errors

Der AC3-Ton wurde nicht erkannt, statt dessen habe ich insgesamt 3 MP2-Dateien, wovon eine 0 Byte hat, da sie erst nach Ende der Aufnahme angelegt wurde.

Ich denke mal, der AC3-Ton wird hier nicht korrekt erkannt. Deshalb sind dann die sync block zu lang für ein MP2-File. Aber wie kann ich den Fehler beheben?

Nur zur Info: der Fehler trat auf sowohl vor der Installation von .NET 3.5 als auch nach der Installation. Das aktuelle Log stammt von nach der Installation von .NET 3.5.

Als Image verwende ich das aktuelle JtG-Image 2.2.6 in der Version vom 21.12.07, d.h. ohne neuere Snapshots.

Ach ja, vorher hatte ich nur wenig Probleme mit udrec 0.13beta, aber manchmal zerschossene Aufnahmen mit "SPkt buffer overflow". Den hier beschriebenen Fehler hatte ich vorher nie.

cu, relaff

Verfasst: **Di 15 Jan 2008, 16:26**

"PMT-Update" in der Box auf an?
Und du möchtest in PES (nicht SPTS) aufnehmen richtig?

Gruß

Jack the Grabber

udrec für .Net 3.5

udrec für .Net 3.5