udrec Resend packets schlecht ?

[ProjektC]

Hallo,

habe mal einige Filme auf Premiere 1 und 2 aufgenommen und lief super und er hat auch schöne die File so gesplittet das nur der Hauptfilm in einem file ist.

Nun Streame ich Premiere Serie und sehe bei Matlock was ca 1 Stunde läuft 10 Resend und frage mich ob das auch so übel ist wie Resynchs bei Winggrab oder GGRAB oder ob das irgendwie normale Informationen sind.

[leth]

Solange die Meldung nur 'x Packets RESEND' heißt, ist überhaupt nichts passiert. Tragisch ist es erst bei 'Packet LOST'.

Cu leth

[ProjektC]

@00:00:26: Beginne Aufnahme: "Matlock.mpg" nach: E:\Dbox-Aufnahme\2004-01-05-Matlock
@00:12:10: 18:46:20 RESEND 8 packets
@00:14:06: 18:48:16 RESEND 7 packets
@00:14:52: 18:49:02 RESEND 17 packets
@00:16:31: 18:50:42 RESEND 5 packets
@00:18:34: 18:52:45 RESEND 26 packets
@00:20:23: 18:54:34 RESEND 2 packets
@00:21:06: 18:55:17 RESEND 1 packets
@00:21:55: 18:56:06 RESEND 1 packets
@00:28:33: 19:02:45 RESEND 34 packets
@00:35:30: 19:09:42 RESEND 1 packets
@00:50:56: Ende Aufnahme

Das macht dann nichts aus ?
Weiter oben habe ich gelesen das es neue udrec gibt.
Ist das schon in der letzten JtG 0.7.0 enthalten oder muss ich das einfach nur in den JtG Ordner reinkopieren, wenn ja muss ich den Reg Eintrag auch machen ?

[torre]

Solange die Meldung nur 'x Packets RESEND' heißt, ist überhaupt nichts passiert. Tragisch ist es erst bei 'Packet LOST'.
Cu leth

Dem ist wirklich nichts hinzuzufügen.
Und in Jack 0.70 ist bereits die neueste udrec drin.

[911]

Hast du ein Glück. Bei mir sieht es so aus -->

@00:13:11: 01:57:00 RESEND 13 packets
@00:13:11: 01:57:01 RESEND 2 packets
@00:13:13: 01:57:02 RESEND 3 packets
@00:13:14: 01:57:03 RESEND 5 packets
@00:13:17: 01:57:06 RESEND 2 packets
@00:13:18: 01:57:07 RESEND 1 packets
@00:13:22: 01:57:11 RESEND 15 packets
@00:13:23: 01:57:12 RESEND 3 packets
@00:13:24: 01:57:13 RESEND 3 packets
@00:13:25: 01:57:15 RESEND 3 packets
@00:13:27: 01:57:16 RESEND 6 packets
@00:13:28: 01:57:17 RESEND 159 packets
@00:13:28: 01:57:17 RESEND 94 packets
@00:13:30: 01:57:19 RESEND 5 packets
@00:13:32: 01:57:22 RESEND 2 packets
@00:13:35: 01:57:24 RESEND 48 packets
@00:13:35: 01:57:25 RESEND 1 packets
@00:13:36: 01:57:25 RESEND 5 packets
@00:13:37: 01:57:27 RESEND 4 packets
@00:13:38: 01:57:27 RESEND 9 packets
@00:13:39: 01:57:29 RESEND 16 packets
@00:13:40: 01:57:30 RESEND 5 packets

Und das waren nur 30 sekunden.

[Pedant]

Hallo 911,

dann hast Du auch Glück, da kein Packet lost dabei ist.
Resends sind völlig unerheblich für die Qualität einer Aufnahme.

Gruß Frank

[911]

.. ja bin ja nicht Abmahnerfalle ... zwischendurch hab ich manchmal Buffer Overflow und Dann auch Paketloss. Ich denke mal es liegt an meinem blöden HUB. Das kommt irgendwann nicht merh klar, wenn ich nebenher noch was d/l oder so.

[ProjektC]

So wie ich es mitbekommen habe sind Resend ungefährlich ? "eg"

[Pedant]

Hallo 911,

ein Hub ist, wenn Du beim Streamen zusätzlichen Netztraffic generierst, eine schlechte Wahl.
Der Hub schickt immer Alles überall hin auf allen Anschlüssen und wer's im Netzwerk brauchen kann, der behält's.
Ein Switch merkt sich wer im Netzwerk gerade mit wem redet und leitet alle entsprechenden Packete nur noch an diese Anschlüsse.
Dadurch wird die Verbindung box zu PC weitgehend für die Streamingdaten frei gehalten.
Solange Du nur einen Hub benutzt, solltest Du die Finger vom Rechner lassen.

Gruß Frank

[leth]

Auch ich habe teilweise sehr, sehr viele Resends, allerdings liegt das daran, dass ich einfach nicht mehr aufpasse wenn ich am PC arbeite, ob gerade eine Aufnahme läuft oder nicht. Dank udrec kann ich während einer Aufnahme zB mit Project-X arbeiten, oder von DVD-Lab eine DVD authoren lassen. Das sind Prozesse, die die CPU meist zwischen 80 und 95 % auslasten. Trotzdem sind die erhaltenen Dateien ohne Fehler

Cu leth

[911]

Yup kann ich bestätigen. Meine Roland Kaiser Konzert Aufnahme ist wunderbar *megafreu*

Jetzt glaub ich euch auch, dass Resends nix schlimmes sind. haha