#1
|
|||
|
|||
Multiple Downloads of Identical Parts
Trotz der auf Englisch knackigeren Überschrift mach ich mal auf Deutsch weiter ;)
Alle Jubeljahre stoße ich (ohne erkennbare Ursache) auf folgendes Phänomen: - einem Package befinden sich 2n Parts, n Parts von Hoster A und n Parts von Hoster B - die Filenames eines Parts X aus n sind identisch = bei Hoster A und B jeweils dieselben - dennoch versucht JD2 jeden Part X gleichzeitig sowohl von Hoster A als auch B zu laden - es bleibt einem keine Wahl, als jeden zweiten Part eines Hosters zu disablen / zu skippen Hier das Logfile, beschränkt auf das beschriebene Problem: 24.10.16 23.25.50 <--> 24.10.16 23.30.11 jdlog://4534781887641/ Und hier noch ein Screenshot: (nach Start von part03@SO und Skippen von part03@UL und dann Abbruch des Downloads) Was ich schon mal versucht habe, ist zwischendurch ein Neustart des Clients - daher auch die (irreführenden) Fehlermeldungen "File already exists", aber das ist wieder ein anderes Thema ... Und noch ein anderes Thema: Wenn ich mich abmelde, bleibt der oben eingefügte Link sichtbar; es erscheint nicht wie sonst üblich (und nützlich) "**External links are only visible to Supporters**". Warum? Last edited by Jiaz; 25.10.2016 at 10:07. |
#2
|
||||
|
||||
Der Grund ist ganz einfach Die Mirrors sind nicht identisch.
Part03 bei SO hat 157286874 Bytes und bei UL 157286868 Bytes. Mit den Default-Einstellungen müssen aber Dateiname und Größe identisch sein, damit sie als Mirror erkannt werden. In den Profieinstellungen kannst du unter GeneralSettings.mirrordetectionfilesizeequality wieviel % die Dateigrößen übereinstimmen müssen. Als Alternative kannst du auf die Dateigröße verzichten, dann stelle GeneralSettings.mirrordetectiondecision auf Filename Es gibt für bestimmte Links eine Whitelist, zb auch für Imgur
__________________
JD-Dev & Server-Admin |
#3
|
|||||
|
|||||
Disclaimer vorab:
Der Post ist aufgrund des Verlaufs lang geworden, aber vollständiges Lesen lohnt sich (für Devs, nicht für User!) Tja, wenn man den Grund kennt ^^ Der ist ja so ohne Weiteres nicht erkennbar ... Quote:
Quote:
In diesem Fall aber ließ sich trotz diverser weiterer abweichender Parts – das beschriebene Problem trat auch schon bei den ersten beiden und noch manchen nachfolgenden auf – das aus SO- und UL-Parts bunt zusammengewürfelte Package problemlos und fehlerfrei entpacken! Also habe ich entweder a) tierisch Schwein gehabt oder b) die bei SO zusätzlich angehängte Bytefolge 0D 0A 0D 0A 0D 0A spielt beim Entpackvorgang gar keine Rolle. Bis auf dieses obskure Supplement sind die beiden Files binär-kompatibel. Weil dies aber wie gesagt 1. kein Einzelfall war, und sich 2. in allen von mir bisher beobachteten Fällen ebenfalls keine Probleme beim Entpacken ergaben, da vermutlich 3. keine file corruption vorliegt, sondern ein wiederkehrender unkritischer Effekt [ob nun SO diese Bytefolge anhängt oder woher diese sonst kommt weiß der Geier] würde ich den Thread noch nicht als "solved" betrachten, sondern schauen ob wir dafür eine legitime Lösung finden können, ohne den JD2 übermäßig fehlertolerant werden zu lassen. Quote:
Für eine allgemein eher typische Part Size von ~100000000 Bytes läge sie somit bei 99,999994%. Daher habe ich den Wert für die "Equality" mal auf 9999 = 99,99% = kleinstmöglicher Abweichungswert gesetzt. Demzufolge werden aber nun zwei Dateien, von denen die eine 157286874 Bytes groß ist und die andere 157271146 Bytes groß ist (und die somit um ziemlich heftige 15728 Bytes abweichen), als "gleich groß" toleriert. Das würde mit ziemlicher Sicherheit schief gehen. Daher folgender REQUEST: Genauigkeit für GeneralSettings.mirrordetectionfilesizeequality erhöhen; Maximalwert = 10000000 —» Genauigkeit von ~10 Byte bei typischen Part Sizes Defaultwert = 9999999 —» um den wiederkehrenden unkritischen Fall abzufangen Quote:
Unabhängig davon, wie der ausgehen wird, habe ich aber für dich noch einen BUG REPORT: Mein weiteres Vorgen im obigen Fall, von dem du den Screenshot gesehen hast, war zu der Zeit folgendes: 1. restart after completion of part01 and part02 2. yet problem occurs again on part03 3. therefore manual skip of part03[UL] 4. stop all running downloads + screenshot 5. part03 » other » reset 6. start downloads 7. part03[SO] is downloading 8. part03[UL] is now detected as mirror + automatically skipped 9. part04[UL] is downloading ... ohne die von dir vorgestellten Optionen zu verändern, die ich ja zu dem Zeitpunkt noch gar nicht kannte! :D Heißt: Wird ein Part resettet, wird für diesen Part damit auch die von euch eigentlich so gewollte und implementierte Nicht-Mirror-Detection aufgrund abweichender Dateigrößen außer Kraft gesetzt. Zudem scheint dies auch der Fall zu sein, wenn ein Mirror eines Parts bereits heruntergeladen (und der Client ggf. restartet) wurde. Erinnerst du dich noch an den Screenshot? Da stand nach dem Neustart dann "File already exists" bei part01 und part02, die zuvor noch als Nicht-Mirrors gewertet wurden und daher von mir manuell geskipped werden mussten. Ganz in meinem Sinne, aber eben inkonsistent zum eigentlich implementierten Verhalten %) ↑ gestern ________ ↓ heute Aber es kommt noch besser: Als ich nun, statt den teilweise noch ungeklärten Post abzusenden, brav weitertestend die von dir aufgeführten Optionen wieder auf Default zurückgesetzt habe, wurden auch weiterhin alle eigentlich unterschiedlichen Dateien eines jeweiligen (zuvor gelöschten, also noch nicht vorhandenen) Parts trotzdem als Mirrors gewertet, d.h. die Nicht-Mirror-Detection war – trotz Rückkehr zur Ausgangslage – weiterhin außer Kraft gesetzt. Daraufhin packte mich die Neugier und ich entfernte das komplette Package, um es per Linkgrabber erneut hinzuzufügen. Et voilà, Ausgangssituation wiederhergestellt, Verhalten des Clients nun wieder genau wie ursprünglich beschrieben. Und jetzt kommt der Oberknaller ^^ und damit auch ein weiterer BUG REPORT: 1. part01[SO] captcha solved 2. part01[SO] is downloading 3. part01[UL] not detected as a mirror (due to default settings) 4. part01[UL] captcha solved 5. part01[UL] is – Überraschung! – not downloading 6. part01[UL] is automatically skipped due to "File already exists" 7. part02[UL] captcha solved 8. part02[UL] is downloading Ergo scheint die ganze Nicht-Mirror-Detection für Code:
filename(partX[hosterA]) == filename(partX[hosterB]) && filesize(partX[hosterA]) != filesize(partX[hosterB]) Oder anders gesagt: Sie bewirkt eigentlich nur, dass man ein sinnloses Captcha für ein File vor die Füße geworfen bekommt, welches dann eh nicht heruntergeladen wird. :D Für mich wurde damit jedenfalls endlich das Rätsel gelöst, warum bei Verwendung eines Premium-Accounts – der ja leider neulich ausgelaufen ist :] – in manchen Fällen "Mirror is downloading" (gleichnamige+gleichgroße Mirrors) und in anderen Fällen "File already exists" (gleichnamige+ungleichgroße Mirrors) als Statusmeldung ausgegeben wurde. Ist ja auch was, hat mich nämlich schon immer gewundert %) Probleme beim Entpacken gab es übrigens auch in diesen Fällen nie. OT-Teil: Quote:
Hab mal kurz ins Wiki geschaut, aber da ist nur bluehost.to aufgeführt ... Nebenbei kommt mir die Doku zum Teamviewer irgendwie Spanisch vor ;°) |
#4
|
||||
|
||||
Winrar/RAR sind Dummy/Padding Bytes am Ende einer Datei egal Evtl kann ich das ganze ja mit in die Mirror Detection integrieren, muss ich mal prüfen. Also special Handling für RAR.
Ich kann entweder die Abweichung in % mit höherer Genauigkeit einbauen oder man gibt gleich die maximale Abweichung in Bytes an. Was ist dir lieber? Mirror Erkennung ist unabhängig von File-Exists Mirror Erkennung dient der Verwaltung von Links/Mirrors. Sofern JDownloader 2 Dateien nicht als Mirrors erkennt versucht er natürlich beide Herunterzuladen und dann schlägt FileExists zu, also je nachdem was du möchtest (Skip,Rename,Overwrite) Schick mir mal am besten ein paar BspLinks an support@jdownloader.org und ich versuch mich an nem SpecialHandling für RAR Archive.
__________________
JD-Dev & Server-Admin |
#5
|
||||
|
||||
Quote:
Ich beabsichtige ebenfalls eine PasteBin/Upload Seite welche nur von Entwicklern/Supporter gelesen werden können. Leider hat der Tag nur 24h :(
__________________
JD-Dev & Server-Admin |
#6
|
|||
|
|||
Quote:
|
#7
|
||||
|
||||
Am besten wäre dann wohl eine Zuordnung von Dateiendung->max. Abweichung in Bytes.
__________________
JD-Dev & Server-Admin |
#8
|
|||
|
|||
Sieht wohl so aus.
|
#9
|
||||
|
||||
__________________
JD-Dev & Server-Admin |
Thread Tools | |
Display Modes | |
|
|