[ziko]

Guten Morgen allerseits

Möchte folgendes, unlogisches, Verhalten von Jdownloader2 melden.
Bei Links, die Offline sind, wird immer wider versucht diese runter zu laden.
Anstatt sie gleich zu überspringen. bleibt Jdownloader ewig auf diesen toten Links hängen.
Verwende mehrere Muslihoster, bei Allen das Gleiche mit toten Links.
Nun weitere Beobachtungen, die mir aufgefallen sind:
Alldebrid meldet "Cloudflare blocked..."
Anscheinend kann man über diesen Multihoster und Jdownloader nix mehr runterladen?
Denen ihrer Plugin für Firefox ist Müll
Cocoleach Plugin ist da viel besser, Rechtsklick "Runteladen mit Cocoleach" ist super.
Linksnappy ist auch so ein Kandidat von "Cloudflare blocked...".
Alldebrid und Linksnappy laden über Jdownliader nur Free Hoster, Youtube und dergleichen, bei Emload, Kshared, die normalerweise bei denen auf der Webseite zum runterladen gehen, kommt in Jdownloader diese Cloudflare Meldung.
Hoffentlich könnt ihr etwas gegen dieses nervige Verhalten bei oten Links bewirken.
Liebe Grüsse.

[pspzockerscene]

Originally Posted by ziko

Bei Links, die Offline sind, wird immer wider versucht diese runter zu laden.

Dies sollte nicht passieren.
Um welchen Multihoster geht es?
Bitte poste Testlinks.

Originally Posted by ziko

Alldebrid meldet "Cloudflare blocked..."

Wenn der Fehler wirklich im Alldebrid Handling kommt: Melde das beim Alldebrid Support.
Davor sollten wir schauen, woher er kommt -> Bitte poste ein Log (Anleitung verlinke ich weiter unten).

Originally Posted by ziko

Anscheinend kann man über diesen Multihoster und Jdownloader nix mehr runterladen?

Doch kann man - habe ich hier live im Einsatz.

Originally Posted by ziko

Denen ihrer Plugin für Firefox ist Müll

Ich empfehle, dieses Feedback in präziser an den Alldebrid Support zu schicken.

Originally Posted by ziko

Linksnappy ist auch so ein Kandidat von "Cloudflare blocked...".

Glaube ich nicht.
Ich vermute, JD versucht aus anderen Gründen den Download ohne Multihoster und direkt beim Filehoster und rennt dann in Cloudflare. Bitte poste einen Log.
Bitte lies zusätzlich unser Cloudflare FAQ:
https://board.jdownloader.org/showthread.php?t=83712
Bitte lies unseren Multihoster Troubleshooting Artikel:
https://support.jdownloader.org/Know...roubleshooting

[ziko]

Hallo Leute

Muss doch das Thema neu aufgreifen.
Es geht um das ungesunde Verhalten von JD2 wenn Links offline sind oder das Datenvolumen des Hosters oder Musltihosters, aufgebraucht ist.

JD2 pingt Sundenlang die Seite an und versucht den Link, der Offline ist auf dem OCH, neu zu laden.
Stundenlang, genau.

Jetzt kommt das Problem: mich sperrt Emload, Cloudflare, Seite mit den kopierten Links, mit irgendeiner Meldung temporär weil JD hartnäckig Zugriffe auf Emload und Co generiert, obwohl der Link tot ist und die Datei gelöscht ist.

Genauso ist es mit der Seite, von wo man die Links mit Rechtsklick -> alles auswählen -> kopiern in jD2 einfügt.

Anstatt die Links zum OCH zu übernehmen, werden die Links zur Seite übernommen.
Im Fall dass die Links auf der Seite tot sind, gelöscht, Datenvolumen aufgerbaucht, was auch immer.... JD2 pingt die Seite Tausende Male an um die gelöschten Links zu übernehmen.
Anstatt direkt vom OCH versuchen zu laden, pingt JD2 immer wieder die Seite mit den zur Verfügung gestellten Links.
Da kommt die Sperre von Cloudflare oder der Seite, es werden DoS Angriffe von JD2 simuliert und vermutet.

Mein Wunsch:
- Links direkt zum OCH übernehmen, nicht die Links zur Seite mit den OCH-Links in JD2 einfügen sonst Pingt JD die Seite unnötig an und wird gesperrt.
- tote Links, gelöscht nicht unnötig weiter versuchen zu laden
- bei verbrauchtem Datenveolumen des Premiumabos vom OCH oder Multihoster, das melden oder einfach aufhören weiter die Seite mit den kopierten Links weiter zu pingen und versuchen die Links zu laden. Sperre kommt.

Hoffe, es ist nicht so schwer zu realisieren.
Bin überzeugt, wenn das von mir beanstandete Fehlverhalten von JD unterbunden wird, gibts auch weniger Fehlermeldungen im Forum.
Denkt doch nach, Kshared und einige andere OCH auch, haben eine Cloudflare Sperre aufgebaut für JD.
Woran liegts?
Woran?
Habe es doch oben aufgelistet.

Danke für eure Hilfe in dieser Angelegnheit.

[pspzockerscene]

Doppelte Threads zusammengeführt.

@ziko
Bitte lies meine Antwort #2 in diesem Thread erneut und poste die fehlenden Informationen.

[ziko]

Originally Posted by pspzockerscene

Glaube ich nicht.
Ich vermute, JD versucht aus anderen Gründen den Download ohne Multihoster und direkt beim Filehoster und rennt dann in Cloudflare. Bitte poste einen Log.
Bitte lies zusätzlich unser Cloudflare FAQ:
**External links are only visible to Support Staff**...
Bitte lies unseren Multihoster Troubleshooting Artikel:
**External links are only visible to Support Staff**...

Melde mich wieder mit einigen Rückmeldungen.
So einfach ist es nicht, alles auf andere, Multihoster, Cloudflare oder sonnst wenn abzuwälzen.
Nach einer Serie Updates, hat isch etwas getan.
Vorteihaftes aber auch weniger.
Habe nun keine Meldung von Emload erhalten "Emload blocked your IP" das ist gut. Trotzdem läuft JD2 in diese sinnfreie Warteschleife rein, wenn die Datei offline ist. Nicht nachvollziehbar, weil oft die Datei online ist.
Aber JD2 fällt von sich aus in diese Warteschleife, obwohl die Datei online, Traffic vorhanden ist, Cloudflare nix blockt.
Wenn ich die Links bei Alldebrid auf der Seite in deren Downloadmanager eingebe, werden sie sofort geladen.
Reines JD2 Problem.

Problem ist seit geraumer Zeit wieder, JD2 ändert mir die Spracheinstellungen und Tastatur Layout selbstsändig. Wenn JD2 im Hintegrund lädt, ich ihn aufrufe, ändert er mir das Tastatur Layout immer wieder.
Das ist kein Cloudflare oder Emload Verhalten.
Das nervt.

K.A. ob ich das erwähnt habe, nutze eine 10 Gbit/s Glasfaser Leitung an einem verkabelten 10 Gbit/s Port am PC. Downloadspeed mit JD2 auf SSD hatte ich früher und mit JD2, max. 1,5 - 1,7 Gbit/s auf SSD.

Beobachtungen nach der Update Serie in JD2:
1. Nun lade ich 3000 .zip .rar .7z Dateien herunter, kleinere und grössere, alle sind sie mit dem gleichen Passwort geschützt. Nach einigen schnellen Downloads, popt JD2 ein Fenster auf, wo ich zur Eingabe des Passwortes aufgefordert werde. Danach entpackt er die aufgelaufenen Dateine und vergisst erneut das soeben eingebene Passwort. Dabei hat JD2 schon etliche Dateien mit diesem Passwort entpackt, stürzt aber ab nach einigen schnellen Downlowds von kleinen Datein, ab. Das Passwort wurde für den ganzen Ordner und Batch an Dateien eingegeben, das ist nicht die Ursache.

2. JD2 schaltet nun eine Trauerpause beim Downloaden ein, nur die erste Datei in der Liste wird versucht zu laden. Verhalten bei Emload und Jumploads. Das nervt, nun hat man eine schnelle Leitung, bezahlt Premium Accounts und JD2 legt vor jedem Download mehrer Sekunden Pause ein.
Wozu?
Wenn ich Pech habe, stürzt JD genau bei dieser Datei ab und rödelt 10 Minuten mit der Meldung "Starte" vor sich hin, ohne wirklich online zu gegehn, die URL Aufzurufen, online Status prüfen, JD2 stürzt einfach in sich ab. Irgendwann kommt eine Meldung und die nächste Datei wird vorgenommen.
Da JD2 schon abgestürzt ist, meldet er auch bei dieser Datei "Kurzzeitig nicht verfügbar", was nicht stimmt. Datei ist online und Traffik vorhanden.
Zum Glück habt ihr das sinnfrei Pingen des Servers von Emload unterbunden, wenn die Datei Offline ist. Emload blockiert nicht mehr meine IP. Wenigsten reduziert. Da hat sich etwas getan.

3. der Prozess "JDownloader2.exe" an TCP Port 9665 und 9666, startet den Prozess "LM.licenses.Adobe.com", wobei der Port 9666 auch vom alleinigen Prozess "JDownloader2.exe" genutzt wird.
Habt ihr eine Ahnung woran das liegt?
Habe einige Screenshots gemacht, hab k.A. wie ich diese Bilder an dieser Stelle einfügen kann.

4. am Anfang der Update Serie, wurde der Speed von JD2 auf max. 12 Mb/s, Anzeige rechts oben in JD2. Das ist nun wieder weg. Leider wird der Downloadspeed von den Trauersekunden vor jedem Download begrenzt, es wird immer nur eine Datei geladen, die restliche sind in einer Warteschleife. Anzahl gleichzeitiger Downloads bringt keine Abhilfe, nur die Zahl Wartesekunden steigt auf 60 Sekunden.

5. JD2 "vergisst" den Haken "überspringen" bei Doppelten Datein. In unregelmässigen Intervalen muss ich das bestätigen und den Haken bei "Anwenden auf das ganze Paket" neu setzen. Dauernde Popups für das Passwort, Haken setzen, andauern kotrollierne od er wieder abgestürzt ist und 10 Minuten bei irgendeiner Datei vor sich hinrödelt, Tastaur Layout jedes mal erneut ändern....das Ding ist nervig. Da geht der direkte Download schneller beim jeweiligen Multihoster.
Andauern muss man bei dem Ding etwas eingeben überspringen, deaktivieren....
Das nervt wirklich.
Hoffe, ihr könnt etwas mit dem ausführlichen Bericht anfangen.

Die erwähnten Screenshots muss ich am Schluss anfügen.

Liebe Grüsse an das Team und ihr schafft das.

[pspzockerscene]

Sers ziko,
mir scheint als gäbe es hier einige technische Verständnisschwierigkeiten.
Zudem hast du die von mir angefragten Informationen (Log, Testlinks) nicht zur Verfügung gestellt. Durch eigene Tests und, weil ich selbst auch einen Cocoleech Account besitze, konnte ich das Problem dennoch zuverlässig nachstellen.
Ich werde in diesem Post ausschließlich auf dein konkretes Problem mit offline Links von emload.com und dem Download über den Multihoster Cocoleech eingehen - den Rest beantworten wir ggf später oder er wird bereits beantwortet sein, wenn ich diesen Post abschicke.

Originally Posted by ziko

So einfach ist es nicht, alles auf andere, Multihoster, Cloudflare oder sonnst wenn abzuwälzen.

Meine bisherigen Antworten sollten eigentlich nicht plump bedeuten "es liegt an Cloudflare".
Sollte dies so rübergekommen sein: Nein ist nicht so, siehe genaue Erklärung weiter unten.


Ich erkläre dir zunächst die Ursaches des Problems und bitte dich, diesen Teil aufmerksam zu lesen.
Dein Problem entsteht wie folgt:

1. Du fügst einen toten emload.com Link ein.
   Wegen Cloudflare kann JD diesen nicht prüfen, was du am "Uncheckable Status" (blaues Fragezeichen) erkennen kannst.
   Würde JD den Link prüfen können, würde er ihn an dieser Stelle bereits als offline anzeigen und ein Downloadversuch würde niemals zustande kommen.
2. Du startest die Downloads -> Dein emload.com Link wird über Cocoleech versucht -> Der Versuch scheitert mehrmals.
3. Nun wird der emload.com Link im Free Modus (ohne Account) versucht und du bekommst die Cloudflare Fehlermeldung.

Nun zunächst die Erklärung, warum JD bei Schritt 2 nicht einfach "Datei nicht gefunden" anzeigt sondern es mehrmals versucht:
In der Vergangenheit waren Multihoster höchst unzuverlässig, was den offline-Status eine Datei angeht.
Daher vertrauen wir an dieser Stelle nur dem Status des Originalhosters.
Da dieser hier nicht vorhanden ist, werden tote emload.com Links (ja, wegen Cloudflare!) derzeit niemals als solche erkannt.

Folgende zwei Lösungsansätze gibt es:

Lösungsansatz 1:
Dafür sorgen, dass der emload.com Linkcheck funktioniert sprich, nicht von Cloudflare geblockt werden.
Gestern habe ich eine Stunde lang nach Möglichkeiten geschaut, aber es ist nicht möglich:
- emload.com bietet keinerlei API
- emload.com hat Cloudflare sehr streng konfiguriert - auch Login Cookies mit gültigen Cloudflare Cookies halten nicht länger als ein paar Minuten [darüber ginge es aber kurzzeitig]
Diesen Ansatz kannst du ab sofort testen - ich habe Cookie Login Unterstützung in das emload.com Plugin eingebaut. Es reicht, einen kostenlosen(!) emload.com Account hinzuzufügen, um den Linkcheck zum Laufen zu bringen.
Wichtig ist hier, dass zum Cookie Import ausschließlich das Addon "FlagCookies" verwendet wird, da dies den User-Agent Wert mitschickt.

Lösungsansatz 2:
JDownloader könnte dem "Datei nicht gefunden" Status von Multihostern generell- oder in bestimmten Situationen vertrauen.
Hier die Erklärung, was passieren kann, wenn man dem offline Status von Multihostern vertrauen würde:
Angenommen der User hat drei Multihoster Accounts und ein online(!) emload.com Link wird probiert:
Versuch Über Multihoster 1: Fehlgeschlagen
Versuch Über Multihoster 2: Fehlgeschlagen - Multihoster sagt "Datei ist offline"
-> Keine weiteren Versuche, da der Offline-Status final ist.

Ich bin offen für Vorschläge und ich kann das "Vertrauen vom offline status von Multihostern" gerne mal aktivieren und wir schauen, wie gut das funktioniert.
EDIT

Lösungsansatz 2 habe ich soeben eingebaut und als Update veröffentlich.

[Jiaz]

Originally Posted by ziko

3. der Prozess "JDownloader2.exe" an TCP Port 9665 und 9666, startet den Prozess "LM.licenses.Adobe.com", wobei der Port 9666 auch vom alleinigen Prozess "JDownloader2.exe" genutzt wird.
Habt ihr eine Ahnung woran das liegt?

Hier die kurze Erklärung und nein mit Adobe hat das nix zu tun Port 9666 ist der lokale Port für ClickAndLoad, damit du im Browser mittels ClickAndLoad Links/Container an die laufende JDownloader Instanz schicken kannst, lauscht der JDownloader auf diesen Port auf HTTP ClickAndLoad Requests. Port 9665 ist der Standardport für das SingleInstance Handling, siehe meine kürzliche Antwort hier https://board.jdownloader.org/showpo...06&postcount=9 . Über diesen Port können weitere Instanzen mit der aktuell laufenden Instanz kommunizieren und die Kommandozeile weitergeben.

[Jiaz]

Originally Posted by ziko

5. JD2 "vergisst" den Haken "überspringen" bei Doppelten Datein. In unregelmässigen Intervalen muss ich das bestätigen und den Haken bei "Anwenden auf das ganze Paket" neu setzen. Dauernde Popups für das Passwort, Haken setzen, andauern kotrollierne od er wieder abgestürzt ist und 10 Minuten bei irgendeiner Datei vor sich hinrödelt, Tastaur Layout jedes mal erneut ändern....das Ding ist nervig. Da geht der direkte Download schneller beim jeweiligen Multihoster.
Andauern muss man bei dem Ding etwas eingeben überspringen, deaktivieren....
Das nervt wirklich.

Ich glaube dir sehr das es nervt und daher gut das du danach fragst. Du hast mit dem *vergisst* Recht, aber das ist auch so *gewollt* Ich erkläre kurz.
Die

Einstellung->Profieinstellung->GeneralSettings.iffileexistsaction ist der Standard "Ask me/Nachfragen"

Auch zu finden unter Einstellungen->Allgemein.
"Ask me/Nachfragen" bedeutet hier, das der JDownloader eben für jede Datei und/oder Paket nachfragt was getan werden soll und die Checkbox *merken* merkt sich diese Einstellung für das aktuelle Paket der Datei, sodass man nicht für jede Datei im selben Paket erneut die Auswahl treffen muss. Nach einem Download Start/Stop Cycle, wenn also der Play/Start Button wieder verfügbar ist, sind diese Auswahlen verworfen und JDownloader wird dich erneut fragen.

Lösung: Hier anstatt "Ask me/Nachfragen" eine Auswahl treffen, sodass JDownloader auch ohne Nachfragen weiß wie mit der Situation verfahren werden soll.
Weitere Einstellungen im gleichen Themenbereich wären

Einstellungen->Profieinstellungen->
Extraction.iffileexistsaction
LinkgrabberSettings.handleincompletearchiveonconfirmlatestselection
GraphicalUserInterfaceSettings.confirmincompletearchiveaction

Evtl sollte man hier im Dialog der kommt ebenfalls die Möglichkeit geben den Standardwert dauerhaft abzuändern und nicht nur für die laufende Session.

[Jiaz]

Originally Posted by ziko

Beobachtungen nach der Update Serie in JD2:
1. Nun lade ich 3000 .zip .rar .7z Dateien herunter, kleinere und grössere, alle sind sie mit dem gleichen Passwort geschützt. Nach einigen schnellen Downloads, popt JD2 ein Fenster auf, wo ich zur Eingabe des Passwortes aufgefordert werde. Danach entpackt er die aufgelaufenen Dateine und vergisst erneut das soeben eingebene Passwort. Dabei hat JD2 schon etliche Dateien mit diesem Passwort entpackt, stürzt aber ab nach einigen schnellen Downlowds von kleinen Datein, ab. Das Passwort wurde für den ganzen Ordner und Batch an Dateien eingegeben, das ist nicht die Ursache.

Ursache ist hier das JDownloader den Magic der zu entpackenen Dateien nicht kennt und daher das Passwort nicht verifizieren kann. Erklärung folgt: Um zu wissen ob ein Passwort korrekt ist, bedarf es normalerweiße das Entpacken der kompletten Datei, da erst am Ende bekannt ist ob das Passwort korrekt war (wird von RAR mittels Prüfsummen geprüft). Um diesen Vorgang deutlichst zu beschleunigen entpackt JDownloader von der Datei nur die ersten paar wenige Bytes und prüft diese dann auf einen passenden Magic<->Dateiendung, siehe en.wikipedia.org/wiki/List_of_file_signatures . Ohne diese Optimierung müsste ansonsten zb um ein Passwort aus der Liste zu finden/nutzen ein 1Gb Archiv 10 mal vollständig entpackt werden, wenn das korrekte Passwort an 10ter Stelle in der Liste vorhanden ist. Mittels

Einstellungen->Profeinstellungen->Extraction.maxcheckedfilesizeduringoptimizedpasswordfindinginbytes

wird die maximale Anzahl von Bytes hierfür definiert, sprich entweder kann eine Datei erfolgreich entpackt werden welche kleiner als maxcheckedfilesizeduringoptimizedpasswordfindinginbytes ist, oder eine passende Magic wird gefunden.

Lösung: Wir benötigen eine entsprechende Datei bei dem das automatische Entpacken nicht klappt, sowie das zugehörige Passwort und können dann den entsprechenden Magic in der JDownloader bekannten Liste aktualisieren/hinterlegen. Alternativ kannst du uns die Information zukommen lassen, wir brauchen den Dateinamen, sowie die ersten 8-16 Bytes /zb als Hex-Darstellung, und dann können wir ebenfalls diese Liste aktualisieren.

[Jiaz]

Weil du mehrfach erwähnt hast das JDownloader abstürzt. Das ist nicht normal, da Fehler nicht zum Beenden/Absturz des Prozesses führen, es sei denn es ist so gewollt. Sprich wenn dies passiert, dann aufgrund von Grunden außerhalb JDownloader, zb weil in Java selbst ein Bug ist, oder zb Speicherverwaltung(OutOfMemory) oder in nativen Teilen(Entpacker) es zu Fehler kommt. In den meisten Fällen sind es native Teile, so z.B. gab es viele Bugs zwischen Java und Windows beim Abrufen des DateiIcons von Windows, damit JDownloader dieses in der Übersicht nutzen/anzeigen kann. Dieser Fehler tritt zufällig/sporadisch auf, lässt sich aber direkt in der hs_err Datei erkennen. Wann immer es zu einem richtigen Absturz (Prozess/JDownloader ist weg), sollte Java noch eine hs_err Datei im JDownloader anliegen, wo quasi der Zustand vor dem Absturz enthalten ist und dieses Datei kann Hinweise liefern warum genau der Prozess starb. Wir benötigen diese Datei um die Ursache zu klären und dir mögliche Lösungen/Abhilfen zu erläutern.

[Jiaz]

Originally Posted by ziko

Problem ist seit geraumer Zeit wieder, JD2 ändert mir die Spracheinstellungen und Tastatur Layout selbstsändig. Wenn JD2 im Hintegrund lädt, ich ihn aufrufe, ändert er mir das Tastatur Layout immer wieder.

Ursache ist ein Workaround der dem JDownloader hilft das Fenster in den Vordergrund zu bringen, siehe

Einstellungen->Profieinstellungen->GraphicalUserInterfaceSettings.windowswindowmanageraltkeyworkaroundenabled

Windows hat sich halt genau die gleiche Tastenkombination fürs Layoutswitching ausgedacht und das führt zu dem genannten Problem.
Lösung: Die genannte Option deaktivieren.

[Jiaz]

Wenn du bei bestimmten Bereichen weitere Fragen/Anmerkungen hast oder etwas weiterhin unklar sein sollte, einfach nachfragen

[pspzockerscene]

@ziko
Feedback wäre schön gewesen.

Nochmal zu cocoleech.com:
Durch meine Änderung passiert nun in manchen Fällen genau das, was ich befürchtet hatte: Manche Links, die eigentlich online sind, werden als offline markiert, weil die cocoleech.com Schnittstelle behauptet, sie seien offline, siehe:
https://board.jdownloader.org/showthread.php?p=535250

[cremor]

Dieser Thread ist im Changelog im Kontext "Multihoster handling: allow multihost plugins to trigger "file not found" errors" verlinkt. Dazu habe ich eine Frage: Wenn im JDownloader die Meldung "Multihoster claims that this file is offline" erscheint, wird der Download dann nach einiger Zeit wieder versucht? Das wäre schon sehr hilfreich für Fälle, wo das File nicht wirklich offline ist.

[pspzockerscene]

Ja.
Ich habe das im aktuellen preview Changelog (Spoiler im Post aufklappen) nun präzisiert.