[Solved] Keep2Share "downloadlimit erreicht"

[mero4711]

Keep2Share "downloadlimit erreicht" wird nicht mehr richtig verarbeitet, nachdem in JD nun erfoglreich auf ReCaptcha V2 umgestellt wurde (https://board.jdownloader.org/showthread.php?t=74735)

Wenn Keep2Share meldet "downloadlimit erreicht" (oder auch "no slots available") versucht JD trotzdem weiter alle Keep2Share links nacheinander zu downloaden, statt alle Links (für diese Verbindung (!)) anzuhalten bis die Sperre aufgehoben ist.

Das resultiert, dass JD für all diese Links unnötigerweise Captchas abfragt, die zu nichts führen, weil die Sperr-Meldung dann für jeden weiteren Link erfolgt.

Verwendet man die Plugin-API funktioniert es korrekt, dort gibt es aber nur 30 KB/s download speed.

(Ich dachte erst, es läge an der Vewendung mehrerer "Verbindungen" (Proxies) in JD, passiert aber auch, wenn nur eine Verbindung aktiv ist).

[Jiaz]

Bitte ein Log erstellen, siehe https://support.jdownloader.org/Know...d-session-logs
und logID hier posten

[Jiaz]

[mero4711]

Ich konnte es heute noch nicht reproduzieren.

Bei Keep2Share scheint es zwei Arten von Sperrmeldungen zu geben:
1. Downloadlimit erreicht
2. maximale Anzahl DL erreicht (oder so ähnlich)

Der Fehler scheint aufzutreten, wenn Sperrmeldung 2 in Englisch (!) ("no slots available") in der JD GUI erscheint (und NICHT über die API geladen wird)

Via API hab ich die Fehlermeldungen nur in deutsch gesehen. Und das JD Verhalten war korrekt.

Wenn's wieder auftritt, mache ich ein Log.

[mero4711]

Kaum schreib ich es, schon tritt der Fehler auf: ;-)

"No free slots available->ERROR_TEMPORARILY_UNAVAILABLE|Value:600000"

Danach wartet JD (im nicht-API Modus) nicht eine angemessene Zeit für Keep2Share, sondern versucht direkt den nächsten Keep2Share Link.


--ID:698TS:1504592930884-05.09.17 08:28:50 - [] -> jd.plugins.PluginException: No free slots available->ERROR_TEMPORARILY_UNAVAILABLE|Value:600000
at jd.plugins.hoster.Keep2ShareCc.handleFreeErrors(Keep2ShareCc.java:503)
at jd.plugins.hoster.Keep2ShareCc.doFree(Keep2ShareCc.java:443)
at jd.plugins.hoster.Keep2ShareCc.handleFree(Keep2ShareCc.java:334)
at jd.plugins.PluginForHost.handle(PluginForHost.java:1085)
at jd.controlling.downloadcontroller.SingleDownloadController.download(SingleDownloadController.java:39 5)
at jd.controlling.downloadcontroller.SingleDownloadController.run(SingleDownloadController.java:575)

--ID:698TS:1504592930884-05.09.17 08:28:50 - [jd.http.Browser(setProxySelector)] -> Use local proxy: 192.168.10.1:3128 (Http Proxy) wished: 192.168.10.1:3128 (Http Proxy)
--ID:698TS:1504592931314-05.09.17 08:28:51 - [jd.controlling.downloadcontroller.SingleDownloadController(download)] -> Exception:
--ID:698TS:1504592931314-05.09.17 08:28:51 - [] -> jd.plugins.PluginException: No free slots available->ERROR_TEMPORARILY_UNAVAILABLE|Value:600000
at jd.plugins.hoster.Keep2ShareCc.handleFreeErrors(Keep2ShareCc.java:503)
at jd.plugins.hoster.Keep2ShareCc.doFree(Keep2ShareCc.java:443)
at jd.plugins.hoster.Keep2ShareCc.handleFree(Keep2ShareCc.java:334)
at jd.plugins.PluginForHost.handle(PluginForHost.java:1085)
at jd.controlling.downloadcontroller.SingleDownloadController.download(SingleDownloadController.java:39 5)
at jd.controlling.downloadcontroller.SingleDownloadController.run(SingleDownloadController.java:575)

[Jiaz]

Hab das Handling von 'pro Datei' nun auf 'Host' umgestellt.
Bitte auf Update warten

[mero4711]

Prima. Danke!

Ich frage mich schon länger: Hält JD die Warte/Sperr-Zeiten für die verwendeten Verbindungen einzeln nach? Will sagen: Wenn mehrere Verbindungen (und damit IPs) benutzt werden, berücksichtigt JD die Sperrmeldung und damit Wartezeit pro Verbindung oder wartet JD bis zum nächsten Download nur in Abhängigkeit was der Hoster zuletzt gesagt hat? Unabhängig von welcher Verbindung.

Ich frage im Kontext hier weil ich mehrere Verbindungen/Proxies benutze und die Verbingung (Proxy 192.168.10.1 (oben im Log) anscheinend die einzige mit dem gelegentlichen Problem war.
Die externe IP dieser Verbindung ist aus einem spanischen Adress-Pool und wird möglicherweise anders/schlechter behandelt als andere und früher gesperrt.

Die Wartezeiten sollten verbindungsbezogen sein und ich bin (auch aus anderen Beobachtungen) nicht sicher, ob JD das wirklich macht. Deshalb die Nachfrage.

[Jiaz]

Ja, solche Informationen werden pro Verbindung (Einstellungen-Verbindungen) gehalten.
Wenn natürlich eine Verbindung im JDownloader intern mehrere IPs verwaltet, dann klappt das ganze natürlich nicht mehr. Daher besser das Setup so konfigurieren, dass je Verbindung auch wirklich eine externe IP genutzt wird.

[mero4711]

Originally Posted by Jiaz

Ja, solche Informationen werden pro Verbindung (Einstellungen-Verbindungen) gehalten.

Wunderbar. So habe ich es erhofft.

Originally Posted by Jiaz

Wenn natürlich eine Verbindung im JDownloader intern mehrere IPs verwaltet, dann klappt das ganze natürlich nicht mehr.

Jau, das ist klar. Ich benutze Proxies auf Routern in lokalen und via VPN zusammengeschalteten Netzen. Das funktioniert sehr gut.

Das einzige Problem ist subbyshare (von den Hostern, die ich benutze). Die akzeptieren keine DL-Verbindungen via Proxy (und ist bei mir in die Verbingsausnahmen der Proxies gewandert). Denen könnte man vielleicht noch beikommen, wenn man den Proxy in dessen Konfiguration "unsichtbar" macht. Mache ich vielleicht, wenn ich dort mal viele Links laden wollte.

[Jiaz]

Proxy auf Connect Method schalten, sofern es der Proxy kann. Kann man von Hand in der Proxykonfiguration umstellen. Im cfg Ordner

[mero4711]

Cool. Habe ich gerade in org.jdownloader.settings.InternetConnectionSettings.customproxylist gefunden.

Werde ich für die nächsten subbyshare Links ausprobieren. Brauche ich die Proxies selber vielleicht gar nicht anfassen.

THX!

[Jiaz]

Bemerkung: die meisten Proxies erlauben per default kein Connect auf Port 80. Meist nur auf Port 443

[mero4711]

Jetzt bin ich verwirrt.

Ich hatte verstanden, dass sich nur die Connect Methode ändert. Die Proxies laufen (listening) auf Port 3128. Würde JD sie mit ConnectMethod auf Port 80 ansprechen wollen? Dann scheidet die Lösung wohl doch aus und ich muss den Proxies selbst eine Tarnkappe verpassen.

[Jiaz]

Ein HTTP Proxy kennt zwei Wege.
1.) Einen Request im Auftrag von Client machen
2.) Eine TCP Verbindung im Auftrag von Client machen (zb für HTTPS)
2te ist via Connect und die meisten Proxies erlauben das in der default-Konfiguration nur auf Port 443(Https). Sofern du an den Proxies was einstellen kannst, dann erlaube einfach noch Port 80 und dann aktiviere die CONNECT methode.

[mero4711]

OK, danke. Jetzt hab ich's verstanden.

Wenn JD Port 80 braucht, scheidet das leider aus. Auf dem Port laufen Web-Server.

[Jiaz]

Narf, nein

Port 80 ist HTTP, Port 443 ist HTTPS

JDownloader baut HTTP über Proxy auf, Proxy leitet den Request weiter an Server
JDownloader baut HTTPs über Proxy auf, Proxy erstellt eine TCP Verbindung auf Port 443 an den Server und gibt diese an den JDownloader weiter. HTTPs möglich.

Mit CONNECT.
JDownloader baut HTTP über Proxy auf, Proxy erstellt eine TCP Verbindung auf Port 80 an den Server und gibt diese an den JDownloader weiter. HTTP via Connect möglich.

[mero4711]

Originally Posted by Jiaz

Narf, nein

Hehe. OK. Aber jetzt hab ich's. Gemeint war der Ziel-Port.

THX again!

[Jiaz]

Genau