[Dockel]

JD hat einige Archive ganz normal automatisch entpackt, andere auch gar nicht, bei denen steht dann "Extraction error". Dann habe ich einige Archive markiert, darunter auch die schon von JD entpackten, und auf "Entpacken" gelickt, woraufhin hinter den schon erfolgreich entpackten "Extraction error" steht.

Wie kann ich von diesen Archiven (bei denen "Extraction error" steht) die erkennen, finden, die tatsächlich erfolgreich entpackt sind?

[Jiaz]

@Dockel: Evtl sind schon Dateien vorhanden und das Archiv daher nicht "erfolgreich" entpackt? Schau doch mal ob hinter "Extraction error" noch mehr steht? zb Spalte breiter ziehen oder Tooltip. Weiß gerade nicht wie detailiert da das Fehlerhandling ist. Ansonsten kannst du im Logfile selbst mal prüfen welcher Fehler enthalten ist. Das richtige Logfile solltest du schnell finden, da "Extraction" in Namen enthalten ist

[Dockel]

Evtl sind schon Dateien vorhanden und das Archiv daher nicht "erfolgreich" entpackt?

Die, die vorhanden waren, wurde ja bereits entpackt und automatisch gelöscht. Gibt bestimmt auch welche, die noch nicht vollständig geladen waren, so dass ebenfalls diese Fehlermeldung kam.

Schau doch mal ob hinter "Extraction error" noch mehr steht?

Da steht nicht viel mehr, neben dem Dateinamen nur das:

Ansonsten kannst du im Logfile selbst mal prüfen welcher Fehler enthalten ist.

Die Logs sind besetimmt schon gelöscht, ist schon länger her das Entpacken. Das heißt, im Log hätte ich dann wohl sehen können, dass ein Archiv einmal erfolgreich entpackt wurde (und dann gelöscht automatisch) und - an anderer Stelle im Log wohl - dass es diesen "Extraction error" gab?

Rauszufinden ist es schon, zumindest eingeschränkt, aber mit recht großem Aufwand, weil ich ja für jedes einzelne Archiv nachsehen müsste, manuell. Sind ziemlich viele Archive / Pakete. Hatte gehofft, es gäbe in JD noch irgendeine (verborgene) Information, an der man das schnell sehen könnte.

Kann man eigentlich nur die Archive anzeigen, die mit so einem Entpackungsfehler angezeigt werden?

[Jiaz]

Originally Posted by Dockel

und - an anderer Stelle im Log wohl - dass es diesen "Extraction error" gab?

Richtig, im Log würde dann der Fehler ebenfalls auftauchen. Aber in dem Fall hier bedeutet der Fehler das es beim Entpacken einen CRC Fehler gab, sprich das Archiv(Part) beschädigt ist und daher die entpackte Datei fehlerhaft.

[Jiaz]

Der Screenshot zeigt das es beim Entpacken einen CRC Fehler gab, also ein Teil des Archivs beschädigt ist. Spalte größer ziehen oder Tooltip zeigt die Meldung komplett.

[Dockel]

Der Screenshot zeigt das es beim Entpacken einen CRC Fehler gab, also ein Teil des Archivs beschädigt ist.

Ja, aber das stimmt ja eben nicht meistens, denn die Dateien waren ja schon entpfackt (und gelöscht), als sie zum zweiten Mal entpackt werden sollten.

[Jiaz]

Originally Posted by Dockel

Ja, aber das stimmt ja eben nicht meistens, denn die Dateien waren ja schon entpfackt (und gelöscht), als sie zum zweiten Mal entpackt werden sollten.

Wenn die Dateien schon vorhanden wären, dann würden diese einfach übersprüngen werden oder neu entpackt, je nachdem was eingestellt ist. Die Fehlermeldung des Screenshots wird aber nur gesetzt wenn es beim Entpacken zu einem CRC/Entpackfehler kam. Hier gab es seit Jahren keine Änderungen und mir sind keine Fehler bekannt und der Fehler kann auch nur an zwei Stellen gesetzt werden, wenn es eben beim Entpacken zu einem Fehler kam.

[Dockel]

Die Fehlermeldung des Screenshots wird aber nur gesetzt wenn es beim Entpacken zu einem CRC/Entpackfehler kam.

Oder eben, wenn die Archive nicht mehr vorhanden sind (weil sie schon entpackt wurden und dann von JD automatisch gelöscht wurden), wie hier jetzt.

Hier gab es seit Jahren keine Änderungen und mir sind keine Fehler bekannt und der Fehler kann auch nur an zwei Stellen gesetzt werden, wenn es eben beim Entpacken zu einem Fehler kam.

Ja, hier offenbar, weil die Dateien nicht (mehr) da sind.

[Jiaz]

Originally Posted by Dockel

Oder eben, wenn die Archive nicht mehr vorhanden sind

Nein. Der genannte Fehler wird nur gesetzt wenn es beim Entpackvorgang einen Fehler gab. Wenn ein Teil fehlt, dann wird der Entpackvorgang erst gar nicht loslaufen. Da die Prüfung vorher passiert.

[Dockel]

Das kann aber nicht sein hier. Wenn keine Archive da sind zum Entpacken wird diese Fehlermeldung angezeigt, wenn ich versuche das Entpacken manuell auszulösen. Was man ja auch als Fehler ansehen könnte. Aber ein CRC-Fehler kann das ja nicht sein.

[Jiaz]

@Dockel: Du hast Recht! Entschuldige. Da muss irgendwann was futsch gegangen sein, denn wenn das Archiv unvöllständig, dann sollte da ein anderer Fehler kommen

[Jiaz]

@Dockel: Mit nächstem Core Update wird der richtige (Datei fehlt) Fehler angezeigt.

[Dockel]

OK, super, vielen Dank!

Aber kann ich das jetzt noch rausfinden:

JD hat einige Archive ganz normal automatisch entpackt, andere auch gar nicht, bei denen steht dann "Extraction error". Dann habe ich einige Archive markiert, darunter auch die schon von JD entpackten, und auf "Entpacken" gelickt, woraufhin hinter den schon erfolgreich entpackten "Extraction error" steht.

Wie kann ich von diesen Archiven (bei denen "Extraction error" steht) die erkennen, finden, die tatsächlich erfolgreich entpackt sind?

Vielleicht nach dem nächsten Core-Update spätestens? Aber wohl werden diese Informationen gar nicht (mehr) vorhanden sein, vermute ich. Es geht also bestimmt nicht rückwirkend.

Ich glaube, nur die Archive, die beim Entpacken einen CRC-Fehler haben oder, wenn die Anzeige "Datei fehlt" da ist nach dem Update, kann man sich nicht jeweils einzeln oder zusammen anzeigen lassen, wie diese hier (etwa um sie zu löschen aus der Downloadliste):

[Jiaz]

@Dockel: Es wird auch weiterhin nicht möglich sein nachträglich jene Archive zu finden welche erfolgreich entpackt wurden, wenn sie nun einen Fehler haben. Mit dem nächsten Core Update wird lediglich die korrekte Unterscheidung zwischen "CRC Fehler" und "fehlenden Dateien" behoben sein.

Originally Posted by Dockel

Ich glaube, nur die Archive, die beim Entpacken einen CRC-Fehler haben oder, wenn die Anzeige "Datei fehlt" da ist nach dem Update, kann man sich nicht jeweils einzeln oder zusammen anzeigen lassen, wie diese hier (etwa um sie zu löschen aus der Downloadliste)

Du kannst unten im Suchfeld (in der Mitte) nach Status suchen und dort dann zb "Extraction error" eingeben

[Dockel]

@Dockel: Es wird auch weiterhin nicht möglich sein nachträglich jene Archive zu finden welche erfolgreich entpackt wurden, wenn sie nun einen Fehler haben. Mit dem nächsten Core Update wird lediglich die korrekte Unterscheidung zwischen "CRC Fehler" und "fehlenden Dateien" behoben sein.

Ja, aber dann erkennt man doch, welche Dateien tatsächlich fehlerhaft sind und welche eben nicht entpackt werden konnten, weil die Archive nicht (mehr) da waren. Genau das will ich ja wissen. Läßt sich das jetzt oder nach dem Update herausfinden? Korrigiert sich die Anzeige nach dem Update? Ich nehme an, nein.

Du kannst unten im Suchfeld (in der Mitte) nach Status suchen und dort dann zb "Extraction error" eingeben

Ach ja, gar nicht dran gedacht, dann lassen sich ja beide Fehlervarianten jeweils zun zusammen finden / anzeigen.

[Jiaz]

@Dockel: Nein, der Status wird sich nach dem Update nicht ändern, da er ja aufgrund des Fehlers falsch gesetzt wurde.

[Dockel]

Ja, verständlich, schade. Es gibt also keine Möglichkeit mehr die Archive / Pakete (mit falscher CRC-Fehlermeldung) zu finden in der Downloadliste, die nicht entpackt wurden, weil die Dateien nicht (mehr) da waren.

[Dockel]

Was bedeutet der grüne Haken vor dem Symbol von "Extraction error"(?):




Dass die Archive schon einmal erfolgreich entpackt wurden?

[Jiaz]

Originally Posted by Dockel

Dass die Archive schon einmal erfolgreich entpackt wurden?

Nein. Eine solche Information gibt es nicht/wird nicht gespeichert. Es gibt nur einen Entpackstatus. Wenn du das Archiv erneut entpacken lässt, dann ist der vorherige Status weg.

[Jiaz]

@Dockel: Downloadstatus und Entpackstatus sind zwei verschiedene Dinge. In dem Fall ist der Download erfolgreich und beim Entpacken kam es zum Fehler.