[netGhost]

Ich hatte schon mehrmals über Probleme bezüglich des CRC-Checks gepostet - bislang ging es darum dass dieser beim parallelen Laden auf mehreren Hostern durch den Reconnect abgebrochen wird. Die Teile werden darauf hin deaktiviert, weil sie nach dem Check zwar vorhanden, aber durch den JD nicht als abgeschlossen erkannt werden - wodurch in letzter Konsequenz auch das automatische Entpacken nicht läuft. Dieses Problem ist auch seit inzwischen über einem Jahr noch nicht behoben.

Nach Euren jüngsten Updates habe ich einen neuen Bug im Zusammenhang mit dem Check, der noch viel übler ist. Inzwischen werden der Check nicht nur durch einen Reconnect unterbrochen, sondern auch durch einen weiteren laufenden Download - in der Fileübersicht bleiben die Teile auf "> CRC-Check läuft" hängen - der Check selber wird nicht ausgeführt. Und jetzt kommt der Hammer: Das Teil wird nicht auf der Festplatte abgespeichert, fehlt also hinterher. Ich hoffe mal das (inzwischen sehr umfangreiche) Log gibt das her (http://jdownloader.org/pastebin/26502).

Anzumerken wäre noch dass ich momentan unter Linux (Kubuntu 10.10. "Maverick" amd64) lade, die Teile werden dabei auf einer NTFS-Partition mit vollständigen Lese- und Schreibzugriff abgespeichert. Der Fehler ist aber auch bereits einmal unter Windows aufgetreten, wovon ich jetzt kein Log mehr habe. Am OS liegt es also nicht - bringt also bitte endlich die Behandlung des CRC-Check im JD in Ordnung.

[Jiaz]

ein fehler im dateisystem/rechte/treiber
Could not rename file /Windows_D/Downloads/blabla.part03.rar.part to /Windows_D/Downloads/blabla.part03.rar

kann dein problem nicht nachvollziehen

[netGhost]

Ich lade bereits schon seit rund einem Monat mal abwechselnd unter Windows und Linux mit dem JD, bis vor kurzem ohne Probleme. Der Fehler tritt definitiv erst nach Eurem Update auf die Version 0.9.581 auf, und das halte ich definitiv für keinen Zufall. Unter der 0.9.580 hatte alles noch reibungslos funktioniert - auch unter Linux. Und auch auf NTFS.

Ich werde mal versuchen, den Download hier irgendwie zu Ende zu brigen - der erste Versuch, zwei der vier fehlenden Teile nachzuladen, einmal hat es funktioniert, einmal schlug es wiederum mit dem gleichen Fehler fehl. Notfalls nehme ich halt RS als FreeUser - da gibt es keinen CRC-Check mehr. Und dann funktioniert auch alles... Ich werde es mal wieder unter Windows testen und bringe Euch dann noch ein zweites Fehlerlog.

Außerdem arbeite ich mit Eurem Programm schon von ganz am Anfang an mit den frühen Alpha-Versionen - dieses Mal sitzt der Fehler nicht 60 cm vor dem Bildschirm, sondern steckt in Eurem Programm.

[Jiaz]

bitte nutze die nightly und berichte ob das problem dort noch immer auftritt.

[netGhost]

Apropos Nightly - was ist eigentlich mit meinem Problem bezüglich des Reconnects: http://board.jdownloader.org/showthr...htly+reconnect ? Nachdem ich von Euch nichts mehr gehört hatte ist die Nightly für mich tabu - würde sie aber gerne mal testen. Wäre ja jetzt noch einfacher - unter Windows Nightly und unter Linux Stable - oder umgekehrt.

Du musst das Szenario aber auch wie bei mir gestalten, sonst dürfte das Ergebnis wenig aussagekräftig sein: Zwei parallele Downloads auf uploaded und share-online - jewels als Free-User. Hatte noch nie einen Premium - warum auch, soeben bekam ich als Free-User auf Megauploaded rund 10 MBit/sec.

[Jiaz]

ich hatte noch nie ein solces problem und habe es auch aktuell nicht, auch wenn ich 8 downloads parallel hab (egal ob free/premium)
das reconnect, teste die nightly und wenn es noch immer nicht deinem wunsch entspricht muss man es wohl noch weiter anpassen.

[netGhost]

Bezüglich des CRC-Checks - daran liegt es ja auch nicht, dieser funktioniert an sich einwandfrei. Allerdings ist es so dass dieser durch einen anderen Prozess (wie z.B. den Reconnect) unterbrochen wird, und damit kommt Euer Programm anscheinend nicht klar.

Zudem ist mir aufgefallen dass manchmal vor dem Reconnect noch ganz kurz die Meldung "> Untätig" in der Fileübersicht des JD erscheint - irgendwie scheint da noch ein anderer Prozess im Hintergrund zu laufen. Wenn dem so ist, könnt Ihr mein Szenario ohnehin nicht überprüfen - das ist dann auch von den Einstellungen im JD selber abhängig, und welche Plugins man benutzt.

Ach so, das Wichtigste hätte ich noch vergessen: Das Problem taucht definitiv nur auf wenn man über mehr als einen Hoster gleichzeitig lädt, das ist jedenfalls der Auslöser aller Probleme bei mir, vielleicht soilltet Ihr dort einmal ansetzen. Wie die Steuerung mehrerer paralleleler Download überhaupt abläuft, welcher Download bei einem Reconnect abgebrochen werden darf, wenn der Hoster Resuming unterstützt (Option: "Reconnect darf laufende Downloads unterbrechen). Hast Du es auch mit dieser Einstellung versucht? Die ist bei mir aktiviert. Ich werde mal zusätzlich versuchen, diese abzuschalten, vielleicht läuft es dann ja besser. Übrigens ist ebenso die Option "Downloads warten auf Reconnect" aktiviert - schließen die beiden sich etwa aus? Falls dem so sein sollte, dann sollten sie aber auch nicht separat voneinander zu aktivieren sein.

[Jiaz]

untätig ist nen alter bug im downloadsystem, nur gui technisch
ich schaus mir nochmals an

aber bitte teste die nightly, damit ich weiss obs dort auch noch passiert, da ich rückwirkend nicht auf >1 jahre alten code fixe/teste.

[netGhost]

Ich würde es ja gerne auf der Nightly testen (und diese auch gerne nutzen), aber dort funktioniert der Reconnect bei mir leider nicht (Stand Oktober 2010). Vgl. dazu mein Post - es sei denn Ihr habt es mittlerweile gefixt. Ohne Reconnect würde der Test nicht viel bringen - denn der hat auch irgendwie etwas damit zu tun.

[Jiaz]

was genau geht denn im reconnect noch nicht?

[netGhost]

So, wieder da. Ich habe den JD jetzt kurz mit dem Startparameter auf die NIGHTLY umgestellt, und dabei sind mir folgende Dinge aufgefallen:
Der (Versuch des) Reconnect hat den CRC-Check bei der Nightly nicht unterbrochen. Das funktioniert schon mal soweit, bloß ist es beim Reconnect leider beim Versuch geblieben, dazu später.
Auch die Teile wurden einwandfrei auf die Platte gespeichert, allerdings ist das noch wenig aussagekräftig, da es unter der STABLE nur manchmal nicht funktioniert hatte - und unter der Nightly nach diesen vier ersten Teilen Feierabend war - der Download lief nicht mehr weiter.

Die Ursache dafür ist der nicht funktionierende Reconnect - dieser wurde wie bereits letzten Herbst nicht ausgeführt. Dabei scheint mir das Problem nicht beim Reconnect selber zu liegen - das per Router-Control erstellte Skript ist ja das gleiche. Es funktioniert schlicht und ergreifend die IP-Erkennung nicht. Beweis: Nachdem ich den Reconnect händisch mittels der Websteuerung des Routers ausgeführt hatte, schien das den JD herzlich wenig zu beeindrucken. Der Download blieb nach wie vor mit "Teile warten auf Reconnect" stehen. Nachdem ich die Downloads manuell gestoppt und gleich darauf wieder gestartet hatte, ging es unverzüglich weiter. Ich habe Euch nochmals ein Log beigefügt, schaut mal ob Ihr damit etwas anfangen könnt: http://jdownloader.org/pastebin/26519 .

Eines habe ich noch nicht ausprobiert: Die NIGHTLY unter Kubuntu. Gesetzt den Fall, ich bekomme die Startparameter auch dort unter KDE an die Programmstartsteuerung übergeben (und die Funktion funktioniert auch wirklich, was bei KDE alles andere als selbstverständlich ist), werde ich das mal austesten.

[Jiaz]

hast du den ip check deaktiviert?
ich sehe keinen einzigen ipcheck im log

[Jiaz]

bzgl keine weiteren download starten, bitte ein screenshot

[netGhost]

IP-Check deaktiviert? Warum sollte ich das tun? Das sind meine momentanen Einstellungen unter "Reconnect" => "Erweitert": . Dass ich keinen weiteren Download starten konnte, hatte ich so nicht geschrieben. Tatsache ist bloß, dass der Reconnect versagt und dann die Teile mit "Warten auf neue IP" stehen bleiben. Alllerdings laufen bei der STABLE nach einem manuellen Reconnects die Downloads direkt weiter, hier bei der NIGHTLY in meinem Fall leider nicht, was an der nicht funktionierenden IP-Überprüfung liegt.

[netGhost]

Mir ist in der NIGHTLY ein weiterer Fehler aufgefallen, in Zusemmenhanf mit dem Hoster share-online.biz. Manchmal erscheint als Rückmeldung "Plugin defekt Download failed!", was aber falsch ist, die richtige Rückmeldung des Servers ist "Keine Free-Slots verfügbar. Premium kaufen oder warten", siehe Screenshot: . Ich muss dazu auch sagen, dass ich diesen Hoster mit seinen unfairen Methoden normalerweise um diese Uhrzeit nicht benutze, war jetzt nur für diesen Test.

[eisbaer]

kopier dir dein JD in ein anderes verzeichniss.
hat den vorteil, falls die nightly nicht laufen sollte, du dann noch
eine funktionierende stable hast.
mach eine konsole auf

cd /pfad/zum.kopierten/jd
java -jar jdupdate.jar -branch NIGHTLY

[netGhost]

Zur Zeit weiß ich ja, dass die NIGHTLY bei mir nicht korrekt funktioniert, da brauche ich den JD eigentlich nicht zweimal unter Windows. Ohne Reconnect ist der für mich ohnehin weitgehend nutzlos. Ich werde mal versuchen, unter Kubuntu auf die NIGHTLY zu wechseln, das ist ohnehin nicht mein Produktivsystem. Da Kubuntu bash verwendet, funktioniert der Reconnect dort ohne jegliche Änderung am Skript.

[netGhost]

Noch eine Frage: Kann mir jemand sagen, wie ich unter (k)ubuntu 10.10.an die Nightly komme? Ich habe den JD über das Repo für ubuntu installiert.

[Jiaz]

komm doch bitte mal in den supportchat und lass uns teamviewer machen

das mit dem plugin defekt ist absicht aktuell, da nach 5 retries automatisch als defekt gewertet wird.

das mit so werd ich abändern
das mit dem reconnect können wir dann gemeinsam anschaun

[netGhost]

Gerne. Melde mich dann heute Nachmittag wieder, momentan habe ich nicht so viel Zeit. Ich habe allerdings momentan noch keinen Teamviewer auf meinem Rechner installiert, sollte ich das nicht dazu tun?

Zusätzlich würde ich unter Kubuntu mal gerne die NIGHTLY testen, ob der Reconnect da auch nicht funktioniert. Wie komme ich daran? Auch wenn ich in KDE den Startbefehl so wie in Eurem Nightly-Thread angegeben ändere, es wird immer wieder die Stable gestartet. Vor allem habe ich noch keinen Ordner fpr den JDownloader gefunden, nur das Startskript unter /usr/bin. Unter /usr/share ist nichts.

[Jiaz]

ja installier dir teamviewer (läuft auf jedem os).
jd beenden und

java -jar jdupdate.jar -branch NIGHTLY (RESET=stable zurück)
im jd ordner (console)

[eisbaer]

Originally Posted by netGhost

Noch eine Frage: Kann mir jemand sagen, wie ich unter (k)ubuntu 10.10.an die Nightly komme? Ich habe den JD über das Repo für ubuntu installiert.

hab ich dir schon geschrieben, in meinem post...

[netGhost]

Hallo Jiaz, der Befehl bringt mir herzlich wenig, da ich eigentlich unter Linux (Kubuntu) auf die NIGHTLY umstellen wollte. Der Teamviewer läuft hier auch bereits, es gab ein passendes .deb dafür, auch für amd64.

Wenn ich mit dem whereis-Befehl in Linux nach dem JDownloder suche, bekomme ich folgende Ausgabe:

netghost@netghost-Saugstation:~$ whereis jdownloader
jdownloader: /usr/bin/jdownloader
netghost@netghost-Saugstation:~$

Und dort im Verzeichnis befindet sich nur ein Skript, kein Ordner.

Aber gut, um die Sache nicht unnötig lange zu verzögern, werde ich unter Windows 7 auf die NIGHTLY umstellen (dort geht es über eine Startbefehl-Erweiterung) und auch noch den Teamviewer installieren. Melde mich gleich wieder im Chat.

[Jiaz]

damit schaltest du auf die nightly um
java -jar jdupdate.jar -branch NIGHTLY (RESET=stable zurück)
natürlich vorher in den jd ordner wechseln
cd /home/user/.jd_home (oder wo auch immer du es hininstalliert hast)

kannst nochmals in chat kommen, brauch nochma das log.

[netGhost]

So, Update. Ich habe den JD-Ordner auf Kubuntu endlich gefunden, mit ein Bisschen Hilfe... Hatte sich versteckt, im wahrsten Sinne des Wortes.

Die Konfiguration ist jetzt so wie ich sie ursprünglich geplant hatte - NIGHTLY jetzt unter Kubuntu (Reconnect funktioniert allerdings momentan auch hier nicht, zusätzlich habe ich noch den Teamviewer installiert - für alle Fälle), und zurück auf die STABLE unter Windows 7.

[Jiaz]

musst noch auf das nächste nightly warten wo der bugfix für deinen router drin ist, sollte nächste woche kommen da wir noch am update derzeit rumschrauben

[netGhost]

Ist nicht so wild. Ich habe ja JD unter Windows, wo der Reconnect funktioniert. Und JD unter Kubuntu, wo files.mail.ru im Gegensatz zur Stable läuft, und wo man keinen Reconnect braucht. Das sind halt die Vorteile von Dual Boot. Man muss nur wissen wofür man welches OS startet.

Danke jedenfalls schon mal im Voraus für Eure Bemühungen.

[netGhost]

Sorry, dass ich den Post hier jetzt noch einmal hervorkramen muss. Aber trotz inzwischen mehrerer Updates - auch dem von heute - funktioniert der Reconnect bei mir unter der NIGHTLY leider nach wie vor nicht.

[Jiaz]

core update der nightly gabs noch immer nicht, da wir noch immer an tiefen änderungen arbeiten. haben lediglich ein plugin update dort geworfen

[netGhost]

Heute kam bei mir das nächste Update (neuer Build 19735). Ich wollte nur Bescheid geben, dass der Reconnect leider nach wie vor nicht funktioniert.

[Jiaz]

ich muss später erstma kontrollieren was im update drin ist, keine ahnung ob der core geupdated wurde, wenn ja lass uns dann nochma teamviewer machen

[Jiaz]

nein gab noch kein core update, nur plugins

[netGhost]

Da ich den JD unter Linux auch mal nutzen möchte, habe ich wieder auf die STABLE resettet. Dadurch bekomme ich aber natürlich nicht mehr mit, sobald es eine neue NIGHLY gibt. Es wäre schön, wenn Ihr mich danach irgendwie darüber benachrichtigen könntet, am Besten per IM.

[Jiaz]

pm mir deine email und ich kann dich gerne informieren,
wir arbeiten noch immer am nächsten nightly update.

[netGhost]

Inzwischen ist ein weiteres viertel Jahr vergangen, und daher möchte ich den Post bezüglich des nicht funktionierenden Reconnects bei der NIGHTLY in Verbindung mit meinem Router mal wieder etwas nach vorne holen.

Ich habe jetzt mittels Startbefehlerweiterung unter Windows 7 wieder auf die NIGHTLY umgestellt, um zu schauen ob sich etwas getan hat. Einen kleinen Erfolg kann ich insofern vermelden dass der Reconnect jetzt partiell funktioniert. Das "partiell" soll heißen, den JD führt den Reconnect in meinem Router durch und besorgt mir auch eine neue IP, das funktioniert jetzt insoweit. Leider erkennt der JD die neue IP nach wie vor nicht (die Sache mit dem Cookie...), so dass der Download nicht wieder anläuft und der JD einen Fehler beim Reconnect meldet. Das manuelle Stoppen der Downloads nach dem Reconnect und sofortiger Neustart schafft Abhilfe, es sollte aber doch zu bewerkstelligen sein dass der JD die neue IP auch ohne solche Tricks korrekt erkennt.

Ein funktionierender Reconnect wäre nämlich nicht schlecht, es ist wohl kaum davon auszugehen dass die jetzige Freeuser-Regelung auf Rapidshare bis in alle Ewigkeit so bleibt.;)

[Jiaz]

es gab seit dem noch kein nightly update. wir arbeiten noch immer auf ein update hin, aber viel arbeit und nur 2 main coder = wird noch dauern

[netGhost]

Dass die Sache bei Euch nicht oberste Priorität hat hat ich durchaus nachvollziehen. Ich habe bloß die Befürchtung dass die Sache bei Euch in Vergessenheit gerät, die Nighly irgendwann ohne Patch zur neuen Stable wird und ich (und wohl auch noch andere Nutzer) ab dann von der Nutzung des JD ausgeschlossen werden.

Und irgend etwas müsst Ihr am Kern geändert haben, denn der eigentliche Reconnect funktioniert ja bei mir inzwischen, was vorher nicht der Fall war. Obwohl Euer Programm da auch etwas banane ist. Wenn ich die IP-Erneuerung über die Einstellungen starte, steht da in der Maske nach dem Reconnect eine andere IP als davon, das muss das Programm doch wohl selber erkennen dass die beiden nicht identisch sind. Es kommt trotzdem die Meldung "Reconnect fehlgeschlagen".

Edit: Die Probleme mit der IP-Überprüfung konnte ich jetzt dadurch umgehen, dass ich in den Einstellungen den IP-Check deaktiviert habe. Der Reconnect läuft jetzt bei mir mit der Nightly insoweit, allerdings konnte ich das bislang nur auf Netload als Free User testen. Leider bekomme ich ständig Fehlermeldungen bei einzelnen Parts wie "Hoster offline?" und "Disconnect?", wobei ich nicht weiß ob es am JD bzw. der Einstellung liegt oder am Hoster selber, da sich Netload in den vergangenen Wochen nicht gerade als Sinnbild für Zuverlässigkeit präsentiert hat, vorsichtig ausgedrückt.