Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc-3.2-36 SuSE OS: Linux If connection terminates with popup 'connection to host foobar is broken' kget is unable to resume it without manually ticking the 'ok' and then resuming it manually.
similar problem here, but not even manually pause/retry helped. I needed a complete kget shutdown, to be able to resume the download. Probably it´s because the download source had changed its ip, but had still the same URL (used an dynamic dns service)
When I need to download files through proxy(Squid2.4 STABLE4),and connection is broken,before trying to "reastart" I'm needing to "kill -KILL kget".Direct connection - OK.
I am able to restart the transfer, the only Problem is that Kget drops the partly loaded file and starts from the beginning.
Same situation here. I wasn't able to resume any file - all are restarted from scratch. WWWOFFLE is used as a prox.
I have similar problem. I cannot resume or queue up the job that was terminated because of network error. After displaying message from KIO:Job the program locks up and I needed to do 'killall -9 kget' and run it again to continue transfer. I found the bug also - it is in the Slave::slotResult() method. It comes from terminating the thread that is waiting for wake up from QWaitCondition object and then trying to wake up newly started thread. Please see the patch.
Created attachment 2587 [details] patch
P.S. I'm running kget-0.8.3 under FreeBSD 4.8
Andriy, your patch does not compile with KDE-CVS. running doesn't exist. Can you provide an updated patch? Also, please use "cvs diff -u3p". Thanks
Sorry, I didn't notice the trouble with running. I meant to interrupt the thread loop in the Slave::run() to avoid calling the worker.wait() again eventually. In addition I've read horrors about QThread::terminate() in QT docs :-) So I rewrote the patch to throw away the terminate() method call (and thoroughly tested the patch this time). This patch is against latest CVS version.
Created attachment 2647 [details] updated patch
Kget is not doing what it should as download manager. When the connection is interupted on my firewall/router/server , kget says "stalled" for the interrupted download. It will not resume automatically, despite the fact that there is a setting that should take care of timeouts and retrying. Manually pausing and and requeing DOES work however. The need of manual intervention defies the purpose of a dl manager in my opinion. This is mot most important thing it should do.
I have the same problem with kget as the one in the very first message - have to click ok and manually click the resume button. My kde is 3.2 installed from rpms for Fedora.
Kget does no mischief with file under download,but needs manual intervention. Though I have seen it working with 'stalled' status and trying to reconnect, obviously after an unknown time intervals,it breaks off,though 'number of retries' is set high, and it has not reached the limit.
Kget does no mischief with file under download,but needs manual intervention. Though I have seen it working with 'stalled' status and trying to reconnect, obviously after an unknown time intervals,it breaks off,though 'number of retries' is set high, and it has not reached the limit. Parameshwara Bhat
My last report on this malfunction is from dec 2003. Today in KDE 3.4.2 I noticed that it still shows the behavior of not figuring out how to resume after a connection is back up... I guess it is getting time to consider other programs... I am not a programmer, but I can image that it should not be too hard to have the program check at intervals whether the connection is up and resume automatically....
In addition to this last report I like to mention that beside the few times that it did not resume it also did resume another time... Somehow it has thus worked the way it should this one time....
KGet won't resume after 1 minute as per the retry connect option, when the "Active Popup" dialog is visible which says "Can't save the file" or "Connection error" I guess the Real culprit is the Popup dialog.
here kde 3.5beta2, and after clicking the "OK" to the popup-dialog, the transfer restart/reconnect after 1 minute. But what if I'm not at my desk? whose gonna click the god damned "OK" for the popup dialog :) Please consider making the Active popup to a Passive-Dialog notification. thanks.
*** Bug 158659 has been marked as a duplicate of this bug. ***
Version: 0.8.5 (using KDE 3.5.9) Installed from: Gentoo Portages If the server disconnects (for any reason, but it happens often once a day during the night), kget doesn't resume the download. To resume the download I need to click manually on pause button and then start button again. Please add the feature for auto resume. THX
This bug should be finally history to the recent changes by dario. At least I just tried to unplug the network cable and plug it in later and all the downloads continued without problems. :) Thanks for reporting and giving feedback.