Während JDownloader noch seinen 1h-Countdown zum "warte auf neue IP" abzählte, versuchte ich mal via Firefox zu downloaden und - erfolgreich!

Habe JDownloader daraufhin neu gestartet (was den Countdown löscht) und prompt konnte auch er wieder problemlos downloaden.

Wie funktioniert denn dieser IP-Countdown? Wird der Wert nicht vom Server selbst ausgelesen? Oder kann ich in den Einstellungen z.B. angeben, dass bereits nach 5' ein weiterer Versuch gestartet wird?

Merci!
Meriba

[Jiaz]

welches plugin? logfile?
der wert wird ausgelesen, aber es gibt bestimmte hoster da sind unschöne hacks nötig und es kann sein das da einer angepasst werden muss
daher brauchen wir bsp links

[leonk]

Falls Meriba von Share-Online spricht kann ich das bestätigen, habe das auch beobachtet als ich noch als Free-User heruntergeladen habe.
Man kann auch in JDownloader die Dateien in der Warteschlange zurücksetzen (oder den ganzen Container), manchmal (aber nicht immer) kann man dann eine Datei herunterladen, aber dann kommt wieder die Wartefrist. Im Endeffekt ist man dadurch nicht viel schneller und muss zudem andauernd das Zurücksetzen von Hand machen.
Eventuell hat das etwas mit der Verfügbarkeit von Downloadslots für Free-User zu tun.

O.K. hier endlich ein Log. Dauerte etwas, bis der Fall wieder aufgetreten ist.

Server: share-online.biz

JDownloader markierte alle Files mit [warte auf neue IP], Neustart behob das Problem, Download startete sofort.

http://jdownloader.net:8081/pastebin/48924

[Jiaz]

firewall/av/proxy probleme
jd zeigt lauter netzwerkfehler an! diese solltest du mal in den griff bekommen

Stimmt zwar, hat aber doch nichts mit diesem Bug zu tun, oder?

[Jiaz]

ich hätte schon gern ein log wo eindeutig der fehler zu finden ist. weiss gott welche auswirkungen es hat wenn auf einmal das internet weg ist....das kann ja allerlei nebenfehler erzeugen

Heute früh hatte ich einige nicht eruierbare Probleme mit dem Netz, welche kaum mit JD zu tun hatten. Werde nochmals eines posten, wenn meiner Meinung nach alles o.k. war.

Würde dennoch empfehlen, die [warte auf neue IP]-Behandlung zu überarbeiten, z.B. mit einem einfachen Test-Connect alle 5 Minuten (nur 1 je Server, nicht je File!).

Egal was der Auslöser war, merkt JD somit, wenn das Warten deutlich früher zu Ende ist.

Beste Grüsse & herzlichen Dank aber auf jeden Fall für Eure Arbeit!!
Bruno

O.k. habe jetzt einiges Versucht, es kommt aber immer wieder zu folgendem Logeintrag:

------------------------  Thread: 131  -----------------------
131 10.08.11 01:26:47 - INFO [java_downloader] -> Start working on 1080Arma.part041.rar
131 10.08.11 01:26:47 - INFO [java_downloader] -> Keine Free-Slots verfügbar. Premium kaufen oder warten.
131 10.08.11 01:26:47 - WARNING [java_downloader] -> 
Error occured- latest: ERROR_TEMPORARILY_UNAVAILABLE
00100000000001000000100000000001 <Statuscode
00000000000000000000000000000001 |TODO
00000000000000000000100000000000 |ERROR_TEMPORARILY_UNAVAILABLE
00000000000001000000000000000000 |PLUGIN_IN_PROGRESS
00100000000000000000000000000000 |PLUGIN_ACTIVE
StatusText: Verbinden...
ErrorMessage: Keine Free-Slots verfügbar. Premium kaufen oder warten.

131 10.08.11 01:26:47 - WARNING [java_downloader] -> Error occurred: Temporarily unavailably: PLease wait 600000 ms for a retry

Und obwohl hier 600000ms steht, wartet JD anschliessend 3600000 ms. (komplettes Log im Anhang).

Das Problem erinnert stark an "Keine Internet Verbindung?" und kann jedes mal mit einem JD-Neustart gelöst werden. Scheint mir auf jeden Fall ein Bug bzw. verbesserbar...

Ein Tip, was ich noch verbessern könnte, damit JD nicht immer wieder auf die ID kommt, es müsse auf eine neue IP warten? Router/Firewall scheinen mir nicht verbesserbar. Ev. eine Avast-Einstellung?

http://jdownloader.org/pastebin/48926

Muss mich korrigieren: Obiger Eintrag ist ganz natürlich für das "Keine Free-Slots verfügbar". Das "Temporarily unavailably: PLease wait 600000 ms for a retry" entspricht dem 10'-minütigen Warten bis zum nächten Versuch.

134 10.08.11 01:40:42 - INFO [java_downloader] -> Download Limit erreicht

scheint der Log-Eintrag, auf welchen das einstündige "Warten auf neue IP" folgt - welches durch einfachen JD-Neustart behoben werden kann!

Meines Erachtens hat das Log auch keine Netzwerkfehler o.ä. drin, sondern JD interpretiert das "Keine Free-Slots verfügbar" von share-online.biz irgendwie falsch...

[Jiaz]

Originally Posted by BRotondi

Egal was der Auslöser war, merkt JD somit, wenn das Warten deutlich früher zu Ende ist.

das werden wir nicht einbauen denn genau sowas endet dann im ddos + evtl ip ban deines rechners.
das no slot handling funktioniert bestens und viel besser als die alte *lass es einfach nach paar mins nochma versuchen* methode.

[Jiaz]

ich sehe ein paar fertige download von so und danach download limit erreicht, was ja komplett korrekt ist.
seh keinen fehler!
er behandelt no slot free richtig, dann lädt 2,3 files und dann ip sperre weil limit erreicht

In jedem einzelnen Fall genügte ein JD-Restart, um weiter downloaden zu können!

Das deutet doch darauf hin, dass JD hier etwas missinterpretiert, oder?

[Jiaz]

die zeit für ip sperre ist fest 60 mins, ich weiss ja nicht das es evtl schon früher geht.
ich kann gerne die zeit hier auf 30 mins runtersetzen oder so

gerne nehm ich auch ein ausführliches logfile, auf dem man evtl noch mehr sieht

jd beenden
windows_createlog.bat mit notepad öffnen
dafür sorgen das es so aussieht
...JDownloader.jar -debug -brdebug (-brdebug ist neu)
speichern und starten und warten bis es passiert und dann logfile hochladen

Salü Jiaz

Wie ich aus den vielen Threads verstehe, nutzen all die Tausend User JD für ganz verschiedene Zwecke. Ich fände es sehr entgegenkommend, wenn man die IP Sperre individuell einstellen kann, ev. mit dem Hinweis "auf eigene Verantwortung" oder einem Link zu weiteren Infos.

Auch ändern die Hoster Ihre Einstellungen ja auch immer wieder. Aktuell z.B. beobachtet: Nach exakt 5 "Keine Free-Slots verfügbar" wird ein "Downloadlimit erreicht" übermittelt, jedoch nicht so gemeint. Zumindest konnte ich JD neu starten, erhielt nochmals 5 Versuche, nochmals neu gestartet und prompt beim nächsten Versuch geklappt. (Nachtrag: könnte natürlich auch sein, dass ich irgend eine Einstellung verändert habe, welche diesen Effekt erzielt...)

D.h. für meinen ganz individuellen Hoster würde ich die IP Sperre auf 5 Minuten setzen - auf eigenes Risiko. (Praktisch wäre es natürlich, noch weitere Details für die Behandlung konfigurieren zu können, aber lassen wir das mal.)

Heissen Dank im Voraus!
Bruno
(ausführliches Log folgt Morgen, Gute Nacht allerseits!)

... doch noch heute erledigt

"C:\Program Files (x86)\Java\jre6\bin\javaw.exe" -jar -Xmx512m JDownloader.jar -debug -brdebug 2> errlog.txt >log.txt

log.txt, errlog.txt

Originally Posted by Jiaz

die zeit für ip sperre ist fest 60 mins

Was mir noch auffällt: Bei Hostern mit "echter IP-Sperre" (z.B. Netload.in) liest JD die verbleibende Zeit aus und setzt nach dem Neustart den Countdown dort fort, d.h. es kann die Restzeit weiterhin ausgelesen werden.

Bei "meinem Fall" wird nach dem Neustart keine Sperre mehr festgestellt, was die Frage aufwirft, wieso überhaupt eine angenommen wurde. Wurde die Angabe von share-online.biz missinterpretiert oder hat share-online.biz bewusst "geblufft"?

Heute Nacht habe ich Versuche mit 300MB-Files unternommen: Nach wirklich jedem Download wurde 60 Minuten gewartet. Die Wartezeit lässt sich aber auch wie gehabt durch JD-Neustart umgehen.

[Jiaz]

das log zeigt nur limit reached von netload, bei so ist alles in butter im log
und nach 5 keine free slots...free slots verwahtlung ist serverabhängig, sprich
server X hat no free slots, dann werden automatisch alle andren vom selben server direkt übersprungen, somit verhindern wir die ip sperre.

ich konnte deine feststellung nicht bestätigen und das logfile zeigt wie gesagt netload limit, nix von so

[Jiaz]

laut support gehen 500mb pro stunde als free und jd wartet wenn die meldung kommt 60 mins, weil die seite keine zeit angibt.
ich kann gerne die wartezeit mal auf 15 mins reduzieren oder so, aber 5 mins sicherlich nicht

[Jiaz]

habs jetzt mal auf 10 mins gestellt

Merci für die Anpassung!

Zu share-online.biz: Das mit den 500MB ist nur eine Pseudogrenze, welche für Free-User aufgrund der Limitierung auf ca. 135kbps eh eingehalten wird. Wieso JD ab und zu ein "Limit erreicht" interpretiert - oder der Server zurückgibt - ist mir schleierhaft.

Z.B. heute Nacht: 300MB download in 40', 1h Pause, 300MB download, 1h Pause, ...

[Jiaz]

weil jd die meldung seitens so auswertet und dann halt bisher immer 60 mins wartet, weil wir ja nicht wissen wie lange diese anhält, jetzt wartet er halt 10 mins

Wenn ihr eh je Server individuelle Einstellungen verwenden könnt, empfehle ich dringend, die Wartezeit für SO auf 1 Minute zu reduzieren, denn

• Freeuser haben ein Limit von 135kbps und 500MB/h
• aber 1h à 135kbps = 475MB
• Die "Limit erreicht"-Meldung erscheint je nach Serverauslastung sogar schon nach einem einzigen Versuch! D.h. JD testet dann nur noch all 10 Minuten auf einen freien Slot! (Hier genau so beobachtet. Nach 10' wurde kurz getestet und wieder 10' gewartet. Auch ein paar Neustarts nach 20' behoben das Problem nur insofern, dass mit etwas Glück schliesslich ein freier Slot erwischt wurde.)

Nochmals betont: Es handelt sich hier um einen serverspezifische Empfehlung ausschliesslich für SO.

Besten Grüsse & guten Appetit!

[Jiaz]

freie slot meldung hat NICHTS mit traffic limit reached meldung zu tun
das sind 2 komplett unterschiedliche dinge
das eine ist serverabhängig und nicht vorauszusehen wann es wieder geht
das andre ip abhängig und volumen abhängig

Das ist schon klar.

Aber SO dürfte gar kein "traffic limit reached" melden. Wie erwähnt kann ein Free-User das Limit gar nicht erreichen! Es macht begrenzt Sinn, länger als eine Minute mit dem Suchen nach freien Slots zu warten - egal welche Meldung SO herausgibt.

Ich glaube nach wie vor, dass SO unserem JD erfolgreich ein Schnippchen schlägt... (Übrigens auch der Konkurrenz. Habe kurz CryptLoad getestet, die warten auch gleich eine ganze Stunde...)

Edit

• SO testet im Voraus. Dadurch erscheint z.B. ein "Datei zu groß für Ihr restliches Download Volumen!" wenn in dieser Stunde bereits 300 MB gedownloadet wurden und eine weitere 300MB-Datei ansteht.
• Einfach erneut zu probieren, hat in den letzten Stunden nicht mehr gefruchtet. Ev. wurde auf SO etwas umprogrammiert - oder es war reiner Zufall, dass ich bisher dauernd nach Ablauf der Stunde probierte. Insbesondere bei den 100MB-Files geht es ja fast exakt auf, d.h. es braucht wenig Glück um einen Treffer zu landen.
• Bei einer Wartezeit von 10 Minuten gehen pro Stunden maximal 10 Minuten verloren - wenn z.B. der Timer kurz vor Ablauf beginnt und nur noch wenige Sekunden benötigt worden wären. Ich empfehle daher weiterhin den Timer noch kürzer zu nehmen. Z.B. 3 Minuten wären erträglicher. Es ist nicht anzunehmen, dass man gebannt wird, wenn je Stunde 20 Retries eintreffen (im Worst Case, wenn ich eine 499MB-Datei anfordere nachdem bereits 2MB geladen wurden).
• Schade ist natürlich, dass man sehr wohl noch ein paar kleinere Dateien downloaden könnte. Aber JD diesbezüglich anzupassen wäre aufwändiger.

Nun eine Woche unterwegs aber noch schnell ein Feedback:

Nach der heutigen Testnacht scheint klar, dass das Handling auf den SO-Servern überarbeitet wurde und nun erfreulich zuverlässig funktioniert:

• Es treten keine "Warten auf neue IP" mehr auf, ohne dass das Limit wirklich erreicht wurde (bisher trat dies auch auf, wenn zu lange kein Free-Slot verfügbar war)
• ein, zwei Mal wurde 5 Minuten lang ein freier Slot gesucht, ohne dass die "falsche Limit erreicht"-Meldung (welche via JC-Reset behoben werden kann) erhalten wurde. (siehe pastebin-Log)

Aus der Vorgabe "Max 500MB/h, im Voraus für jedes File berechnet" ergeben sich folgende theoretischen Überlegungen:

• Werden Chunks < 100MB geladen, kann endlos geladen werden, da das Limit nie ausgeschöpft wird.
• Bei Chunks > 100MB muss gewartet werden, da der letzte Chunk der Stunde die 500MB-Grenze überschreitet.

In der Praxis bestätigt (siehe auch Attachement: Grafik-log der letzten 19h):

• Bei 300MB-Chunks kann immer nur eine je Stunde geladen werden. Die 18' Wartezeit handelt JD durch 2x10' fast verlustfrei.
• Bei 101MB-Chunks ist das Limit nach 55' erschöpft, JD wartet aber 10', d.h. 5'/h werden nicht ausgeschöpft (Mit 3'-Schritten wären es durchschnittlich nur 1.5 Minuten.)
• Bei 99MB-Chunks kann endlos geladen werden da der 5. Chunk die 500MB-Grenze nicht überschreitet und kurz nach 1h fertig wird.

Ich würde behaupten, dass die auf 10 Minuten gekürzte Wartezeit gefahrlos auch auf 3 Minuten reduziert werden kann. SO hält dem User bewusst die genaue Zeit vor, welche er noch zu warten hat und wird ihn wohl kaum bannen, wenn er es noch ein paar mal versucht, bevor die Stunde um ist.

So oder so wurde das Handling für SO aber sehr zu meiner Zufriedenheit verbessert.

Merci!
Meriba

Originally Posted by Meriba;161902[LIST=1

Ich würde behaupten, dass die auf 10 Minuten gekürzte Wartezeit gefahrlos auch auf 3 Minuten reduziert werden kann. SO hält dem User bewusst die genaue Zeit vor, welche er noch zu warten hat und wird ihn wohl kaum bannen, wenn er es noch ein paar mal versucht, bevor die Stunde um ist.

Wenn ich Jiaz richtig verstanden habe befürchtet er durch eine niedrige Wartezeit ein DDos auf SO. Und dann kann niemand mehr laden...