#1
|
||||
|
||||
Fehler beim CRC-Check - Dateien werden nicht auf der HDD abgespeichert
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#2
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#3
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#4
|
||||
|
||||
bitte nutze die nightly und berichte ob das problem dort noch immer auftritt.
__________________
JD-Dev & Server-Admin |
#5
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#6
|
||||
|
||||
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.
__________________
JD-Dev & Server-Admin |
#7
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. Last edited by netGhost; 24.01.2011 at 13:09. |
#8
|
||||
|
||||
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.
__________________
JD-Dev & Server-Admin |
#9
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#10
|
||||
|
||||
was genau geht denn im reconnect noch nicht?
__________________
JD-Dev & Server-Admin |
#11
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#12
|
||||
|
||||
hast du den ip check deaktiviert?
ich sehe keinen einzigen ipcheck im log
__________________
JD-Dev & Server-Admin |
#13
|
||||
|
||||
bzgl keine weiteren download starten, bitte ein screenshot
__________________
JD-Dev & Server-Admin |
#14
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. Last edited by netGhost; 24.01.2011 at 17:27. |
#15
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#16
|
||||
|
||||
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 Code:
cd /pfad/zum.kopierten/jd java -jar jdupdate.jar -branch NIGHTLY |
#17
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#18
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#19
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#20
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#21
|
||||
|
||||
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)
__________________
JD-Dev & Server-Admin |
#22
|
||||
|
||||
hab ich dir schon geschrieben, in meinem post...
|
#23
|
||||
|
||||
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: Quote:
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#24
|
||||
|
||||
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.
__________________
JD-Dev & Server-Admin |
#25
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#26
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#27
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#28
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#29
|
||||
|
||||
core update der nightly gabs noch immer nicht, da wir noch immer an tiefen änderungen arbeiten. haben lediglich ein plugin update dort geworfen
__________________
JD-Dev & Server-Admin |
#30
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#31
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#32
|
||||
|
||||
nein gab noch kein core update, nur plugins
__________________
JD-Dev & Server-Admin |
#33
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#34
|
||||
|
||||
pm mir deine email und ich kann dich gerne informieren,
wir arbeiten noch immer am nächsten nightly update.
__________________
JD-Dev & Server-Admin |
#35
|
||||
|
||||
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.;)
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. |
#36
|
||||
|
||||
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
__________________
JD-Dev & Server-Admin |
#37
|
||||
|
||||
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.
__________________
Wissen ist Macht. Nichts wissen... macht aber auch nichts. Last edited by netGhost; 10.07.2011 at 21:06. |
Thread Tools | |
Display Modes | |
|
|