mutti macht sich sorgen.

seit dem update heute auf ver 0.9.227 funzt die externe reconnect methode nicht mehr.

sys: xp pro sp3, java 1.6 u15

das batchscript manuell funzt wie sau. im jd wird die verbindung nicht mal mehr getrennt.

redundante ereignisse werfen ihre schatten voraus (v0.4 anyone? )

ich hab den eindruck das das script garnicht angefasst wird.

werde mich jetzt mal durch die logs wühlen um dem problem näher zu kommen und ggf aussagekräftige teile hochladen.

bin ich alleine mit diesem problem?

edit:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

also der testrecon is offensichtlich der meinung er hätte die leitung getrennt (dem ist nicht so).

zum schluss wird sogar ein fröhliches reconnect successfully ausgegeben (der blanke hohn lol).

muss definitiv am update liegen denk ich mal, gerstern war alles noch io.

edit2:

das log nochmal für alle: http : // pastebin . com / m6f8564b0

hab den timeout mal von 2 auf 5 gestellt, hat natürlich keinen einfluss.

edit3:

http : // pastebin . com / m3400e474

hier der versuch die verbindung über den recon button zu reconnecten.

bei dieser variante wird die verbindung tatsächlich getrennt (das passiert im normalen dl-betrieb garnicht erst) aber in der folge nicht wiederhergestellt. das log macht den eindruck als wenn die 2te scriptzeile zum wiederverbinden (siehe log 1) nicht ausgeführt wird. somit rennt die ip-prüfung natürlich immer gegen die wand (wie homer lol).

frage am rande: wieso kann man die ip-prüfung eigentlich nicht mehr komplett abstellen? früher ging das mal. jetzt is das balanced ip check !?! o0

edit3:

interessantes verhalten. trenne ich die leitung und führe den reconnect über den button aus wird die 2te zeile des recon scripts durchaus verarbeitet und verbindung hergestellt.

wenn ich meinen recon 2 zeiler in die Batch methode im JD übertrage (quasi nicht External sondern Batch) besteht das identische problem. strange...

edit4:

kann zugemacht werden. ein reinstall mit nervtötender konfiguration hat dafür gesorgt das das problem nicht gelöst aber doch beseitigt ist.

@deinemudder: danke!

[coalado]

hm...
einserseits gut.. andererseits schade.

mit dem Parameter -branch pinky_4 hättest du zur alten version zurückkehren können.
Und wir hätten trotzdem in aller ruhe den fehler bei pinky_5 suchen können.

joa is richtig...

ich glaub aber letzten endes war das ne randgruppengeschichte. ich glaub seit der v0.5 lief immer alles und ich hab nur updates gemacht.

in der vergangenheit kam es mir bereits so vor das es von zeit zu zeit sinn macht jd komplett neu zu insten da sich eine über diverse major releases geupdeatedte version irgendwie immer von der aktuellen download version unterscheidet.

in meiner "alten" v.0.9.227 hatte ich im gegensatz zu meiner "neuen" die löschauswahl im downloadfenster (aus liste oder von platte) nicht.

wenn ich in der "alten" 9.227 ein script in der reconnect batchmethode eingetragen und wieder entfernt habe, war es nach dem neustart von jd wieder da (beim switch zwischen verschiedenen recon methoden mit einhergehender modifikation wäre ein eineindeutiger speicherprozess hilfreich). bei der "neuen" 9.227 tritt dieser fehler nicht auf.

das fahrwasser auf dem fluss zur lösung solcher unstimmigkeiten wird unnötig tief.

sicher wäre es interessant diese zusammenhänge zu verstehen...

ich vermute die lösung von problemen die auch nach einer neuinst auftreten haben hier priorität.

wir werdens nie erfahren... schwamm drüber...

[coalado]

So...
Es gibt in JD einen Execution Timeout. Nach dieser Zeit wird ein externer Prozess beendet und JD kehrt zurück.

Dieses "Feature" war bisher buggy, und hat unter Windows nicht funktioniert. Es wurde mit der neusten JD Version allerdings gefixt.

Ich vermute dass du früher dort irgendetwas >0 eingetragen hattest. Deshalb wurde der Vorgang abgebrochen bevor die *.bat durchgelaufen ist.

http://jdownloader.org/_media/screen...4-14.29.19.png

Übrigens solte man zwischen disconnexct und reconnect eine pause von 5-8 sekunden z.B. mit ping google.de -n 8 machen


kannst ja mal probieren ob das problem wieder auftritt wenn du da z.b. 1 einschreibst..

Für alle:

http://jdownloader.org/_media/screen...4-14.29.19.png
HIER SOLLTE eine 0 stehen!

Originally Posted by coalado

So...
Es gibt in JD einen Execution Timeout. Nach dieser Zeit wird ein externer Prozess beendet und JD kehrt zurück.

Dieses "Feature" war bisher buggy, und hat unter Windows nicht funktioniert. Es wurde mit der neusten JD Version allerdings gefixt.

Ich vermute dass du früher dort irgendetwas >0 eingetragen hattest. Deshalb wurde der Vorgang abgebrochen bevor die *.bat durchgelaufen ist.

http://jdownloader.org/_media/screen...4-14.29.19.png

LECK MICH AM ARSCH... du hast recht!

zumal mir nich ganz klar ist warum es jetzt mit 0 sekunden funktioniert.

ich hatte ja im vorfeld ("alte neue" version) auch 0, 2, 5 eingestellt und es ging auch nicht. ok, wenns im arsch war, wars im arsch.

jetzt läuft es auf jeden fall mit 0 sekunden wie sau. wenn ich es auf 1 sekunde stelle tritt der fehler wieder auf.

entzieht sich grad meiner logik warum es funktioniert wenn er nicht (0 sekunden) warten soll.

Originally Posted by coalado

Übrigens solte man zwischen disconnexct und reconnect eine pause von 5-8 sekunden z.B. mit ping google.de -n 8 machen

ja ja ich weis. mein recon is'n sportwagen, wenn der mehr zeit bräuchte würde ich sie ihm geben.

mein kompletter recon dauert im schnitt 4 sekunden (ohne ip prüfung), und das bleibt auch so.

wie stellt man denn heutzutage die ip-prüfung total ab?

[coalado]

0 entspricht "kein timeout - laufe bis das programm zu ende ist"

Desshalb geht 0

hab ich mir schon mal so gedacht... geht aus der oberfläche nich so wirklich hervor...