JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 24.10.2016, 23:59
JDmurphy JDmurphy is offline
JD Fan
 
Join Date: Mar 2012
Posts: 78
Default 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 09:07.
Reply With Quote
  #2  
Old 25.10.2016, 09:07
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,945
Default

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
Reply With Quote
  #3  
Old 26.10.2016, 23:32
JDmurphy JDmurphy is offline
JD Fan
 
Join Date: Mar 2012
Posts: 78
Default

Disclaimer vorab:
Der Post ist aufgrund des Verlaufs lang geworden, aber vollständiges Lesen lohnt sich (für Devs, nicht für User!)

Quote:
Originally Posted by Jiaz View Post
Der Grund ist ganz einfach;) Die Mirrors sind nicht identisch.
Tja, wenn man den Grund kennt ^^ Der ist ja so ohne Weiteres nicht erkennbar ...
Quote:
Part03 bei SO hat 157286874 Bytes und bei UL 157286868 Bytes.
... denn ich habe mal unter unter Part » Rechtsklick » Properties geschaut und auch auch im Properties Panel, aber keine Angaben zur Dateigröße finden können – also hast du die wahrscheinlich aus dem Logfile, oder ich hab was übersehen :|

Quote:
Mit den Default-Einstellungen müssen aber Dateiname und Größe identisch sein, damit sie als Mirror erkannt werden.
Gut zu wissen; ich ging bisher nur vom Dateinamen aus (daher oben der Hinweis darauf), weil abweichende Dateinamen dann ja auch effektiv für Probleme sorgen, denn schon Versuch des Entpackens würde daran scheitern.

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:
In den Profieinstellungen kannst du unter
GeneralSettings.mirrordetectionfilesizeequality
wieviel % die Dateigrößen übereinstimmen müssen.
Im vorliegenden Fall lag die "Equality" mit 6 abweichenden von 157286874 Bytes bei 99,999996%.
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:
Als Alternative kannst du auf die Dateigröße verzichten, dann stelle
GeneralSettings.mirrordetectiondecision auf Filename
Würde ich (außer wie gerade eben kurz mal zu Testzwecken) nie tun, da sich aus erheblich abweichenden Dateigrößen garantiert Probleme ergeben. Deshalb möchte ich die empfohlene Option GeneralSettings.mirrordetectionfilesizeequality angesichts der anfangs beschriebenen Problematik natürlich auch sehr gern nutzen, doch wird diese erst dann sinnvoll einsetzbar sein, wenn der entsprechende Wert mit praxisbezogener Genauigkeit definierbar ist. Ergo der Request oben ^^

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])
vollkommen für die Katz zu sein, weil der Download der gleichnamigen aber "andersgroßen" Datei desselben Parts zwar gestartet, aber gleich darauf auch wieder abgebrochen wird, weil eine Datei mit demselben Namen ja nun schon vorhanden ist.
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:
Es gibt für bestimmte Links eine Whitelist, zb auch für Imgur
Schade, denn das bedeutet entweder Bearbeitung der Bilder zwecks Entfernung nicht für die Öffentlichkeit bestimmter Details (danke für das Entfernen meines Links nach Sichtung ^^) oder Ausknobeln eines Bilderhosters, der nicht auf eurer Whitelist steht. Ist die vertraulich, oder darfst du mir die Liste zukommen lassen, damit ich nicht erst alle durchprobieren muss? =)

Hab mal kurz ins Wiki geschaut, aber da ist nur bluehost.to aufgeführt ...
Nebenbei kommt mir die Doku zum Teamviewer irgendwie Spanisch vor ;°)
Reply With Quote
  #4  
Old 27.10.2016, 13:47
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,945
Default

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
Reply With Quote
  #5  
Old 27.10.2016, 13:49
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,945
Default

Quote:
Originally Posted by JDmurphy View Post
Schade, denn das bedeutet entweder Bearbeitung der Bilder zwecks Entfernung nicht für die Öffentlichkeit bestimmter Details (danke für das Entfernen meines Links nach Sichtung ^^) oder Ausknobeln eines Bilderhosters, der nicht auf eurer Whitelist steht. Ist die vertraulich, oder darfst du mir die Liste zukommen lassen, damit ich nicht erst alle durchprobieren muss? =)

Hab mal kurz ins Wiki geschaut, aber da ist nur bluehost.to aufgeführt ...
Nebenbei kommt mir die Doku zum Teamviewer irgendwie Spanisch vor ;°)
Das Wiki ist schon arg veraltet, nach und nach überführen wir das alles in die Knowlegdebase https://support.jdownloader.org/Knowledgebase/List

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
Reply With Quote
  #6  
Old 27.10.2016, 14:24
oEFLKQzikCqw oEFLKQzikCqw is offline
JD Legend
 
Join Date: Mar 2012
Posts: 1,505
Default

Quote:
Originally Posted by Jiaz View Post
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?
Bei diesen Paddingbytes handelt es sich doch wohl immer um einige wenige Bytes, so dass da die maximale Abweichung von Bytes sinnvoller ist. Die benötigte Genauigkeit bei der prozentualen Abweichung ist sehr stark von der Dateigröße abhängig und passt dann nicht für stark unterschiedlich große Dateien. Eine Sonderbehandlung von RAR-Dateien (und anderen Archivformaten mit gleichem Verhalten) wäre sicher denkbar, Gewissheit hätte man aber nur bei einem Dateivergleich oder wenn man den Hash der kleineren Datei über die Datenmenge der größeren Datei bildet, welche der Dateigröße der kleineren Datei entspricht, beim Hash also mögliche Paddingbytes ignoriert.
Reply With Quote
  #7  
Old 27.10.2016, 15:16
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,945
Default

Am besten wäre dann wohl eine Zuordnung von Dateiendung->max. Abweichung in Bytes.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #8  
Old 27.10.2016, 15:30
oEFLKQzikCqw oEFLKQzikCqw is offline
JD Legend
 
Join Date: Mar 2012
Posts: 1,505
Default

Sieht wohl so aus.
Reply With Quote
  #9  
Old 27.10.2016, 16:00
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 63,945
Default

__________________
JD-Dev & Server-Admin
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 05:11.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.