Seite 2 von 2

Verfasst: Do 03 Jul 2008, 7:09
von jmittelst
Nö, wieso auch? Fullduplex bringt zwar einen besseren Datendurchsatz für die Netzwerkschnittstelle, aber corrupt Audioframes sind eigentlich kein typisches Problem dafür. Aufnahme-Abbrüche wären es.

cu
Jens

Verfasst: So 06 Jul 2008, 13:17
von Airport1
Welches Aufnahme-Prog oder welche Aufnahme-Konstellation nutzt ihr denn? Ich nutze XMG (XMediaGrabber) und konnte im FullDuplex-Test (dbox2 direkt per Crosskabel fest auf 10MBit FullDuplex am Rechner angeschlossen) LEIDER KEINE VERBESSERUNG (hier z.B. Aufnahme von ARD) feststellen, es gibt weiterhin Aufnahmeabbrueche! Auszug aus dem XMG Log, vielleicht kann ja jemand daraus was ersehen:

17:25:37 INFO - from Box: INFO: UdpSender() - PID333 R0 W0
17:25:37 INFO - from Box: INFO: DmxTSReader() - Pid 275232 0 0
17:25:38 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 0 1
17:25:39 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 0 1
17:25:40 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 1 0
17:25:40 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 1 0
17:25:41 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 0 1
17:25:41 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 0 1
17:25:42 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 0 1
17:25:42 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 1 0
17:25:43 INFO - from Box: ERROR: DmxReader() - buffer overflow Pid 0 1
17:25:43 INFO - from Box: ERROR: DmxReader() - read: Value too large for defined data type
17:25:43 INFO - from Box: EXIT (pid 65)
17:25:43 INFO - from Box: er() - read: Value too large for defined data type
17:25:43 INFO - from Box: EXIT (pid 65)
17:25:43 INFO - from Box: er() - read: Value too large for defined data type
17:25:43 INFO - from Box: EXIT (pid 65)
17:25:43 INFO - from Box: er() - read: Value too large for defined data type
17:25:43 INFO - from Box: EXIT (pid 65)
17:25:43 INFO - from Box: er() - read: Value too large for defined data type
17:25:43 INFO - from Box: EXIT (pid 65)
17:25:43 INFO - from Box: er() - read: Value too large for defined data type
17:25:43 INFO - from Box: EXIT (pid 65)

Verfasst: Mi 16 Jul 2008, 22:43
von freestep
Halo Jens,

wofür sind denn corrupt Audioframes und resyncs typisch ? Ich hab
das des öfteren, seit die ARD die Kanäle umgestellt hat.
Hab den PC gerade frisch installiert und das Problem immer noch. Kann das am 5m Cat5 Kabel liegen ?
Sollte mir doch mal so einen passiv PC zulegen. Das basteln mit Platte in der Box ist leider nicht mein Dingen.

Verfasst: Do 17 Jul 2008, 10:49
von Pedant
Hallo Airport1,

wenn jemand fragt, könne es an diesem oder jenem liegen, dann weiß ich nicht wie man da nein sagen kann.
Jede Komponente, die man für ein System braucht damit es funktioniert, ist natürlich in der Lage dafür zu sorgen, dass es Fehlfunktionen gibt.

An der Länge des Kabels liegt es allerdings nicht. Das Kabel PC <-> Hub/Switch darf bis 100 m lang sein. Bei Direktverbindung PC <-> PC sind es immerhin noch 20 m (oder sind es dort auch 100 m, bin mir da gerade nicht sicher).

Zitiert hast Du nur einen Auszug aus dem Log.
Gab es Warnungen, dass die Datenrate 9 MBit übersteigen würde?

Die Meisten, die nicht Direktaufnahmen auf interne HDD oder NAS machen, nutzen udrec als Engine und dabei sollte es egal sein, ob die steuernde Software JtG oder XMG ist. Als Format bevorzugen viele TS.

Wie sieht es eigentlich mit der Signalqualität der aufgenommenen Sender bei Dir aus?

Gruß Frank

Verfasst: Fr 18 Jul 2008, 13:38
von Airport1
> Zitiert hast Du nur einen Auszug aus dem Log.
ich glaube du meinst mich und nicht deinen vorposter ;) ?

> Gab es Warnungen, dass die Datenrate 9 MBit übersteigen würde?
nein. wenn sowas passiert wirds aber m.E. sehr wohl im log angezeigt?

> Die Meisten, die nicht Direktaufnahmen auf interne HDD oder NAS machen, nutzen udrec als Engine
ich nicht. xmediagrabber ist ein java prog, was in meinem fall die daten von der dbox2 rueberstreamed, aufnahme engine ist dann der VLC.

Verfasst: Fr 18 Jul 2008, 15:00
von Pedant
Hallo Airport1,

ja, ich meinte Dich. Die Anrede in meinem vorhergehenden Post habe ich jetzt entsprechend geändert.

Ich bin was XMG angeht nicht auf dem Laufenden, doch soweit ich weiß, lässt sich dort auch zwischen unterschiedlichen Aufnahme-Engines auswählen: Eine interne, eigene, VLC und udrec.

Wenn dem so ist, könntest Du udrec ruhig mal ausprobieren.
Was z3r0 zur Zeit empfiehlt ist mir allerdings nicht bekannt.

Wie sieht es mit der Signalqualität aus?

Gruß Frank

Verfasst: Sa 19 Jul 2008, 8:48
von jmittelst
freestep hat geschrieben:Halo Jens,

wofür sind denn corrupt Audioframes und resyncs typisch ? Ich hab
das des öfteren, seit die ARD die Kanäle umgestellt hat.
Hab den PC gerade frisch installiert und das Problem immer noch. Kann das am 5m Cat5 Kabel liegen ?
Sollte mir doch mal so einen passiv PC zulegen. Das basteln mit Platte in der Box ist leider nicht mein Dingen.
Netzwerkstörungen gleicht Udrec normaler Weise dadurch aus, das Packete neu angefordert werden, auch dann müßte es eher "9Mbit" Hinweise oder "Buffer" Fehler geben. Empfangsstörungen oder Sende(r)probleme sind da meist eher ursächlich.

cu
Jens

Verfasst: Mo 21 Jul 2008, 11:22
von freestep
Hmm, werd das mal beobachten und dann Infos hier reinschreiben.
Ich bin mir nicht ganz sicher, aber es betrifft nur einige Sender, bei denen ich Probleme habe. Tele5 z.B. Muss mal schauen,wie das die Signal Quali ist und meld mich dann wieder. Danke aber schonmal.
Wäre ja vielleicht noch n Feature für JTG, das die Signalqualität vor Beginn der Aufzeichnung ins Log geschrieben wird.

Full Duplex unter Nokia - wie ?

Verfasst: So 09 Nov 2008, 21:10
von DP!
:?:

Hallo,

ich habe das aktuelle 2.3 JTG auf meiner Box.

Wie erhalte ich (nachdem ich die Pins auf Masse gelegt habe) den Full Duplex ?

Ich habe 3 verschieden Nokias und eine SAGEM. Bei der SAGEM funktioniert es wunderbar: ich erhalte 9.256 Mbit/s.

Nur bei Nokia sind die Datenraten mies.



Gruß, DP!

NOKIA Problem fixed

Verfasst: So 09 Nov 2008, 23:11
von DP!
Nabend,

nachdem ich etwas weiter rumspielte, fiel mir auf, dass es neben dem Einschalten des Full Duplex Modus auch noch einen FORCE Modus gibt (dbox-Taste drücken, Einstellungen, Treiber- und Bootoptionen, FullDuplex Mode). Einschalten genügt für die Sagem und Force ist dann für die Nokias (etwas schlechter als die SAGEM Werte):

Unverzichtbar für mich war einen Benchmark (s.u.) durchzuführen, um ein Gefühl für die besten Settings zu erhalten. Man sollte neben den Maximalwerten auch die Prozessorlast nicht aus den Augen lassen: wenn man parallel zum Test eine session mit 'top' laufen lässt, kann man feststellen, dass ein TCP Transfer i.d.R. 20% mehr Leistung verbrät als UDP.

Generell kann man dann für den Automounter (nach meinen Tests mit dem JTG 2.3.1 - vielleicht nicht übertragbar) sagen, dass man die höchste Packetsize und den höchsten UDP Wert nehmen sollte.

:idea: Ich kann den Aufwand nur wärmstens empfehlen - so hohe Datenraten waren bei mir bisher nicht drin. :!:

auto.net
#ro
archive -fstype=nfs,ro,soft,tcp,nolock,rsize=32768,wsize=32768 server:/mnt/md0/archive
#rw
record -fstype=nfs,rw,soft,udp,nolock,rsize=32768,wsize=32768 server:/mnt/md0/record~ >
Nokia Werte:
Results for write throughput:
8.947 Mbit/s with udp,async,wsize=32768
8.947 Mbit/s with udp,async,wsize=16384
8.659 Mbit/s with udp,async,wsize=8192
8.659 Mbit/s with tcp,async,wsize=32768
8.388 Mbit/s with tcp,async,wsize=16384
7.456 Mbit/s with tcp,async,wsize=8192
6.710 Mbit/s with tcp,async,wsize=4096
5.263 Mbit/s with udp,async,wsize=4096

Results for read throughput:
8.947 Mbit/s with tcp,async,rsize=32768
8.947 Mbit/s with tcp,async,rsize=16384
8.388 Mbit/s with tcp,async,rsize=8192
7.064 Mbit/s with tcp,async,rsize=4096
5.965 Mbit/s with udp,async,rsize=4096
1.231 Mbit/s with udp,async,rsize=8192
Failure with udp,async,rsize=32768
Failure with udp,async,rsize=16384
Sagem Werte:
Results for write throughput:
9.256 Mbit/s with udp,async,wsize=8192
9.256 Mbit/s with udp,async,wsize=32768
9.256 Mbit/s with udp,async,wsize=16384
8.947 Mbit/s with tcp,async,wsize=32768
8.947 Mbit/s with tcp,async,wsize=16384
8.659 Mbit/s with tcp,async,wsize=8192
8.134 Mbit/s with tcp,async,wsize=4096
-e 8947848 with udp,async,wsize=4096

Results for read throughput:
9.256 Mbit/s with tcp,async,rsize=8192
9.256 Mbit/s with tcp,async,rsize=32768
9.256 Mbit/s with tcp,async,rsize=16384
8.659 Mbit/s with tcp,async,rsize=4096
1.296 Mbit/s with udp,async,rsize=8192
Failure with udp,async,rsize=32768
Failure with udp,async,rsize=16384
-e 6100805 with udp,async,rsize=4096

Gruß, DP!