[bugnotme]

Hey JDownloader-Team,

mir ist bei mehrteiligen Archiven (gerade bei Downloads von premium.to) aufgefallen, dass JDownloader bei CRC-Fehlern aktuell nur sagt: „Extraction error: dateiname.part1.rar“ – und das oft, obwohl Part1 gar nicht das Problem ist. Wenn ich das Ganze per Hand z. B. mit 7zip entpacke, zeigt sich oft, dass eigentlich ein anderer Teil wie etwa Part3 schuld ist.

Wäre klasse, wenn JDownloader:

• Klar anzeigen könnte, welches Archiv-Teil genau den CRC-Fehler verursacht.
  
• Optional das betroffene Teil automatisch erneut herunterlädt, anstatt gleich den kompletten Download neu zu starten.

Damit spart man sich das lästige manuelle Entpacken und den unnötigen Download von intakten Teilen.

Danke fürs Feedback und eure super Arbeit an JDownloader!

[Jiaz]

@bugnotme: siehe https://board.jdownloader.org/showpo...9&postcount=21

Nun zum Thema "Kann JDownloader den defekten Part kennzeichnen?"

Jaein. Der genutzte Entpacker weiß erst nach dem Entpacken ob die Prüfsumme passt oder nicht. Wenn nun eine Datei sich über mehrere Parts zieht, dann kann man somit hinterher nicht mehr feststellen in welchem Part der Fehler steckt. Wenn die entpackte Datei jedoch im selben Part begonnen und beendet wird, dann ist die Ursache ja genau in diesem Part zu finden/suchen.
Evtl kann der Entwickler der genutzten Entpacker Library hier mit der nächsten Version mehr Informationen liefern, aber aktuell geht das nicht *genauer*. Hängt natürlich sehr vom Fehler ab, weil wenn soviel kaputt ist, das der Entpacker aussteigt, dann ist natürlich auch klar in welchem Part das passiert ist.

Originally Posted by bugnotme

Optional das betroffene Teil automatisch erneut herunterlädt, anstatt gleich den kompletten Download neu zu starten.

Was meinst du damit? "den betroffenen Teil" ? JDownloader weiß ja nicht welcher *Teil* der Datei betroffen ist, sondern im Idealfall nur das dieser Teil betroffen ist.

[bugnotme]

Originally Posted by Jiaz

@bugnotme: siehe **External links are only visible to Support Staff**...



Was meinst du damit? "den betroffenen Teil" ? JDownloader weiß ja nicht welcher *Teil* der Datei betroffen ist, sondern im Idealfall nur das dieser Teil betroffen ist.

Vielen Dank für deine Rückmeldung!

Hier ein kurzes Beispiel, was ich genau meine:

Wenn ich Dateien unter Linux mit dem Unrar-Paket oder 7zip entpacke, bekomme ich immer direkt angezeigt, bei welchem Teil (z. B. „part3.rar“) der Fehler auftritt. Genau diese Info fehlt mir aktuell im JDownloader – also dass er mir konkret mitteilt, welcher Part den CRC-Fehler verursacht.

Momentan behelfe ich mir, indem ich versuche die betroffenen Archive manuell zu entpacken, so feststelle, welcher Part betroffen ist, und diesen Part dann im JDownloader resete. Danach klappt das Entpacken problemlos. Technisch scheint das also machbar zu sein, ich selbst habe davon allerdings keine Ahnung.

[pspzockerscene]

Ich denke ihr habt euch schon verstanden.
Jiaz hat das in dem verlinkten Post ganz gut beschrieben:
Zitat:

Originally Posted by Jiaz

Der genutzte Entpacker weiß erst nach dem Entpacken ob die Prüfsumme passt oder nicht. Wenn nun eine Datei sich über mehrere Parts zieht, dann kann man somit hinterher nicht mehr feststellen in welchem Part der Fehler steckt. Wenn die entpackte Datei jedoch im selben Part begonnen und beendet wird, dann ist die Ursache ja genau in diesem Part zu finden/suchen.
Evtl kann der Entwickler der genutzten Entpacker Library hier mit der nächsten Version mehr Informationen liefern, aber aktuell geht das nicht *genauer*. Hängt natürlich sehr vom Fehler ab, weil wenn soviel kaputt ist, das der Entpacker aussteigt, dann ist natürlich auch klar in welchem Part das passiert ist.

Link zu der Library:
github.com/borisbrodski/sevenzipjbinding

Dort kann jeder ein entsprechendes Ticket öffnen:
github.com/borisbrodski/sevenzipjbinding/issues

Es wäre sicherlich von Vorteil, ein kleineres defektes Teilarchiv als Beispiel im Github Ticket anzuhängen.

[pspzockerscene]

Nachtrag:

Originally Posted by bugnotme

Momentan behelfe ich mir, indem ich versuche die betroffenen Archive manuell zu entpacken, so feststelle, welcher Part betroffen ist, und diesen Part dann im JDownloader resete. Danach klappt das Entpacken problemlos. Technisch scheint das also machbar zu sein, ich selbst habe davon allerdings keine Ahnung.

Wie häufig hast du das Problem?

Falls das oft passiert:
Das sollte nicht so häufig vorkommen und deutet ggf auf ein Hardwareproblem hin.
Teste deinen RAM z.B. mit "Memtest86".

Von welchen Anbietern lädst du hauptsächlich herunter?
Du hast den Multihoster "premium.to" erwähnt, aber ich meine die echten Filehoster (z.B. "rapidgator.net").

[Jiaz]

Originally Posted by pspzockerscene

Wie häufig hast du das Problem?

Wenn das häufiger passiert, dann würde ich hier die Ursache mal erforschen, denn
1.) Übertragungsfehler sind bei HTTPs nahezu ausgeschlossen
2.) Hatte ich in den letzten 15 Jahren, wenn es hoch kommt, 1 mal einen solchen Fehler. Ich kann mich nicht wirklich daran erinnern jemals "in freier Wildbahn" einen solchen Fehler zu haben
3.) Neuladen sollte in diesen Fällen nichts helfen, wenn die Datei schon Serverseitig defekt sind.

[bugnotme]

Originally Posted by pspzockerscene

Ich denke ihr habt euch schon verstanden.

Sorry, habe das irgendwie übersehen...

Originally Posted by Jiaz

Was meinst du damit? "den betroffenen Teil" ? JDownloader weiß ja nicht welcher *Teil* der Datei betroffen ist, sondern im Idealfall nur das dieser Teil betroffen ist.

Ich musste meine eigene Nachricht jetzt auch dreimal lesen :D
Was ich meinte: Sobald die verwendete Library in der Lage wäre, die defekte Datei zu identifizieren, sollte der betroffene Part resetet werden.

Originally Posted by pspzockerscene

Wie häufig hast du das Problem?

Falls das oft passiert:
Das sollte nicht so häufig vorkommen und deutet ggf auf ein Hardwareproblem hin.
Teste deinen RAM z.B. mit "Memtest86".

Von welchen Anbietern lädst du hauptsächlich herunter?
Du hast den Multihoster "premium.to" erwähnt, aber ich meine die echten Filehoster (z.B. "rapidgator.net").

Es passiert schon recht häufig -aktuell habe ich wieder so einen Fall.
Der RAM und auch die SSD hatte ich bereits ausführlich getestet - ich sollte allerdings erwähnen, dass ich Jdownloader in einer Docker-Instanz auf einem Unraid-Server laufen habe. Vielleicht sorgt das irgendwie für Probleme.

Zu deiner zweiten Frage: Die meisten Files sind von rapidgator oder ddownload.

Originally Posted by Jiaz

Wenn das häufiger passiert, dann würde ich hier die Ursache mal erforschen, denn
1.) Übertragungsfehler sind bei HTTPs nahezu ausgeschlossen
2.) Hatte ich in den letzten 15 Jahren, wenn es hoch kommt, 1 mal einen solchen Fehler. Ich kann mich nicht wirklich daran erinnern jemals "in freier Wildbahn" einen solchen Fehler zu haben
3.) Neuladen sollte in diesen Fällen nichts helfen, wenn die Datei schon Serverseitig defekt sind.

Okay verstanden, ich werde mir auch mal ansehen, ob ich an dem Docker etwas verändern kann, um das Problem als Ursache auszuschließen.

Neuladen hat das Problem leider bisher immer gelöst - somit würde das ja aus eurer Sicht eher für ein Problem auf meiner Seite sprechen.

Ich werde mich darum kümmern, auch bei github einmal ein Issue zu eröffnen - werde mal schauen, ob ich harmlose Files zum Reproduzieren zur Verfügung stellen kann

P.S.: Vielen Dank auch nochmal für die ganzen Rückfragen - das zeigt ja, dass ihr das Anliegen ernst nehmt

[Jiaz]

@bugnotme: Wenn du das so häufig hast, vermute ich auch eher das *Drumrum* als Quell des Problems. Mögliche Herangehensweise:
1.) Außerhalb vom Docker-Container JDownloader nutzen, aber gleiches Ziel über Netzwerk/Samba/nfs nutzen
2.) Docker-Container weiterhin nutzen, aber ein anderes Ziel nutzen, zb lokale Festplatte oder nen USB oder oder.

Beim RAM empfehle ich immer memtest86, da dieses Fehler finden(kann), wo zb Windows Memtest keine findet.
Auch Unraid *Raid*?, wie genau hast du die SSD geprüft? Welches Raid Level?
Wie genau hast du das Laufwerk eingebunden? Lokal oder über Netzwerk?

Kannst du das Problem denn *triggern* ? Oder doch zufällig, aber doch zu häufig?

[pspzockerscene]

Originally Posted by bugnotme

mir ist bei mehrteiligen Archiven (gerade bei Downloads von premium.to) aufgefallen, dass JDownloader bei CRC-Fehlern aktuell nur sagt

Ich möchte hiermit noch ergänzen, dass ein Multihoster, der dazwischen ist natürlich auch der Verursacher sein kann.

Um das auszuschließen bzw besser testen zu können, bräuchtest du jetzt im Idealfall einen premium Account direkt bei einem der Hoster, bei denen du oft CRC Fehler hast z.B. rapidgator.net oder einen anderen Multihoster Account, der dieselben Hoster unterstützt.

[pspzockerscene]

Nachrtrag:
Es gibt genau einen ähnlichen Thread im Forum zum Thema Unraid und CRC Fehler - vielleicht enthält der die Lösung:
https://board.jdownloader.org/showthread.php?t=89526