Eine .sft aufgeteilt laden --> CRC Fehler beim Entpacken

Dieses Thema im Forum "Filesharing" wurde erstellt von westside, 9. Januar 2009 .

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  1. #1 9. Januar 2009
    Hey!

    Folgende Problematik:
    Ist ein Server mal nicht ganz so fix, habe ich jetzt schon ein paar mal die gleiche .sft file mehrfach geöffnet und dann mehrere Download-Fenster offen für den gleichen Upload. Jeweils werden beispielsweise die Parts 1-10, 11-20 und 21-30 in je einem Fenster geladen. Ergebnis: Besserer Speed, da 3*Ausgangsspeed. Das Prinzip leuchtet denk ich mal ein ;)

    Alles funktioniert wunderbar bis zum Zeitpunkt des Entpackens:
    Während des Entpackens kommt mehrfach die Error-Message: Error, The Volume is corrupt [CRC irgendwas]. Wird aber bis zum Ende fertig entpackt und dann ganz zum Ende die finale Error-Message: Could not irgendwas und es folgt der Abbruch der Aktion.

    ergo sind die ganzen geladenen files für mich unbrauchbar. Meine Frage:
    Wie kann ich das Problem entweder
    a) von Anfang an durch irgendeine (CRC? was immer das sein mag) Option umgehen?
    oder aber, was besser wäre,
    b) im Nachhinein irgendetwas umstellen/Einstellung beim Entpacken verwenden, sodass dieser Fehler ignoriert wird?

    Es liegt nachweislich weder am Upload, noch an meinem Leecher (2008 RC3) oder an meinem Winrar (4.65).
     

  2. Anzeige
  3. #2 9. Januar 2009
    AW: Eine .sft aufgeteilt laden --> CRC Fehler beim Entpacken

    Theoretisch muss der Speed sogar langsamer werden bei 30 Threads anstatt 10. Immerhin gibts mehr Overhead. Und es macht nur selten einen unterschied zwischen zwischen 1 Thread oder 5. Das wäre ein Speedlimit pro Connection anstatt IP, also recht unintelligente Server.
    Naja und zum Problem: Warum liegt es nachweislich nicht am Leecher?
     
  4. #3 9. Januar 2009
    AW: Eine .sft aufgeteilt laden --> CRC Fehler beim Entpacken

    hi, wenn du den leecher mehrmals öffnest, musst du darauf achten, dass die parts nicht gleichzeitig

    von verschiedenen threads geladen werden, sprich dasss nicht ein part von 2 oder 3 threads bedient wird.

    wenn der leecher nicht übersschreibt, dann müsste lokaler dateifehler kommen. mit flash sfv kannst du sfv dateien prüfen und erstellen.

    wenn dann immer noch crc fehler ist, den beschädigten part nochmals saugen

    ansonsten wird der up defekt sein und sollte vom upper gefixed werden
     
  5. #4 9. Januar 2009
    AW: Eine .sft aufgeteilt laden --> CRC Fehler beim Entpacken

    @grafix

    Nehmen wir mal an, dass wir 3 Leecher haben.
    A, B und C.
    Das sind alles die gleichen Leecher.
    (sogar die identische exe von mir aus^^)

    A Läd eine Datei komplett alleine.
    Der CRC-Check passt und die Datei wird entpackt.
    Sprich A macht keine Fehler.

    Jedoch sind A, B und C genau gleich, d.h. wenn ich alles mit B lade funktioniert es auch und mit C ebenfalls.

    Da A, B und C identisch sind, müssten theoretisch auch die Parts Identisch sein, ob sie nun A, B oder C läd.

    D.h. man müsste theretisch die Parts von A, B und C beliebig miteinander vertauschen können, ohne das es Probleme gibt.

    Theroretisch eben ^^

    Praktisch sieht es nun offensichtlich anders aus.
    Kann es sein, dass du einen bestimmten Part bei mehr als einem Leecher angekreuzt hast?
    Sprich, dass z.B. Part nummer 4 bei beiden Leechern "geladen" wird?

    Weil das würde bedeuten, dass sie gleichzeitig versuchen die gleiche Datei aufzubauen, wodurch diese korrupiert wird und unbrauchbar wird.

    Natürlich müssen deswegen die richtigen Datein VOR dem drücken des "Download starten"-Buttons angekreuzt werden und es muss dementsprechend auch aufgepasst werden, dass keine Datei mehr als 1x ausgewählt wird.

    Der CRC-Check sollte in jedem Falle bei allen Leechern AKTIVIERT sein.

    Denn dieser überprüft, ob die Dateien auch auf den Bit genauso bei dir gelandet sind, wie sie vom Upper/Group erstellt wurden.

    Der CRC-Check kann auch versagen, falls deine Leitung zu sehr rauscht, jedoch glaube ich kaum, dass es deswegen zu den besagten Fehlern kommt.
     
  6. #5 9. Januar 2009
    AW: Eine .sft aufgeteilt laden --> CRC Fehler beim Entpacken

    (damn bedankt:eek: )

    Also wenn du auf das Archiv rechtsklickst kannst du "Dateien Entpacken..." auswählen und dann im Dialog "Defekte Dateien behalten" ankreuzen. Du solltest natürlich nur defekte Dateien behalten, wenn es nicht auf jedes Bit ankommt! Also keine ISOs oder so^^ Aber irgendnen Film, den man nur einmal schaut... naja dann gibts vielleicht nen kleinen Frameskip oder nen klicken im Sound. Zumindest VLC sollte damit klar kommen.
     
  7. #6 10. Januar 2009
    AW: Eine .sft aufgeteilt laden --> CRC Fehler beim Entpacken

    btw, crc32 is nen verfahren, um sicherzustellen, dass daten korrekt sind.
    Zitat wikipedia:
    Vor Beginn der Übertragung bzw. Kopie eines Blocks der Daten wird ein CRC-Wert berechnet. Nach Abschluss der Transaktion wird der CRC-Wert erneut berechnet. Anschließend werden diese beiden Prüfwerte verglichen. CRC ist so ausgelegt, dass Fehler bei der Übertragung der Daten, wie sie beispielsweise durch Rauschen auf der Leitung verursacht werden könnten, fast immer entdeckt werden. Zum Beispiel werden die meisten Festplatten-Übertragungen und Schreib-/Leseoperationen mit CRC-Verfahren geprüft.

    ...mfg coach
     

  8. Videos zum Thema
Die Seite wird geladen...
Similar Threads - sft aufgeteilt laden
  1. Antworten:
    3
    Aufrufe:
    1.474
  2. dlc und sft anbieten?

    meisterlich , 31. Januar 2013 , im Forum: Filesharing
    Antworten:
    5
    Aufrufe:
    2.279
  3. Problem mit sft loader

    Freakyboy , 6. Januar 2013 , im Forum: Anwendungssoftware
    Antworten:
    4
    Aufrufe:
    745
  4. Antworten:
    1
    Aufrufe:
    774
  5. Suche grössere SFT Boards

    dynamoking , 27. Dezember 2012 , im Forum: Szene News
    Antworten:
    16
    Aufrufe:
    3.384