Bug 101956 - kget ignores simultaneous download limit
Summary: kget ignores simultaneous download limit
Status: RESOLVED FIXED
Alias: None
Product: kget
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
: 117389 129049 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-20 05:03 UTC by Ingmar Sittl
Modified: 2008-05-31 16:32 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Removal of the iteration breaking the simultaneous download limit (828 bytes, patch)
2005-03-21 20:27 UTC, Ingmar Sittl
Details
handle case where cache is disabled but kget requests KIO::CC_CacheOnly (1.01 KB, patch)
2005-10-27 22:34 UTC, Roger Luethi
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ingmar Sittl 2005-03-20 05:03:06 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
Compiler:          gcc (GCC) 3.4.3 
OS:                Linux

kget currently ignores the simultaneous download limit (tested with file-downloads over http) and starts all downloads after some arbitrary short time. I think the culprit is the new (as of KDE 3.4.0) iteration at the end of KMainWidget::checkQueue(), which calls checkCache() on the items to be downloaded. At least removing this iteration fixes this problem for me.
Comment 1 Willy De la Court 2005-03-21 14:10:08 UTC
Confirmed i'm seeing the same problem Redhat 9 rpm's build by kde-redhat. Is there a patch we can apply?
Comment 2 Rex Dieter 2005-03-21 14:17:07 UTC
Confirmed per Willy's comment.
Comment 3 Ingmar Sittl 2005-03-21 20:27:39 UTC
Created attachment 10251 [details]
Removal of the iteration breaking the simultaneous download limit
Comment 4 Ingmar Sittl 2005-03-21 20:29:04 UTC
The only patch I can provide is the complete removal of the new iteration. But I dont really know what the author of this code intended, so that is be a workaround at best, although the removal of the offending code did not create any noticeable negative effect on any use-case I tried out since.
Comment 5 Woodhouse 2005-04-03 14:49:02 UTC
I confirm too on arch linux
Comment 6 Roger Luethi 2005-07-24 21:51:31 UTC
The problem persists in KDE 3.4.1 (kget v0.8.4). Unfortunately, this affects one of the main use cases for an otherwise great tool: Having dozens of connections open and stall at the same time isn't what you'd expect for large batch downloads.
Comment 7 Roger Luethi 2005-10-27 22:34:47 UTC
Created attachment 13184 [details]
handle case where cache is disabled but kget requests KIO::CC_CacheOnly

There may be more than one way to trigger the symptoms, but one of them is to
disable caching (e.g. in konqueror). Given that setting, the current code does
not handle properly the case of a process requesting KIO::CC_CacheOnly. Here's
a patch to fix that.
Comment 8 Urs Wolfer 2005-10-27 23:06:23 UTC
Comment #7: The patch is for kdelibs, not KGet. Do you think this bug is not KGet specific? Is it a KIO problem?
Comment 9 Roger Luethi 2005-10-27 23:37:20 UTC
Correct. It's a KIO problem because its response in this case makes no sense.

It turned out the problem is that kget is capable of exercising KIO with a combination of flags that nobody anticipated (the one I described in Comment #7). The response that _should_ be given is pretty clear: the file can't be found (since the function is instructed to check nothing but the cache although the cache is disabled). Instead it reports finding the file in the cache which of course confuses the caller (i.e. kget).

Kget is probably the only app to ever present that combination of flags. It does work once KIO throws a proper error rather than pretending a file is in the cache when said cache is disabled.
Comment 10 Urs Wolfer 2005-10-27 23:53:21 UTC
See Comment #9. It's a KIO problem, not KGet. There's a patch in Comment #7.
Comment 11 Rainer Wirtz 2005-12-01 20:00:38 UTC
*** Bug 117389 has been marked as a duplicate of this bug. ***
Comment 12 Rainer Wirtz 2005-12-01 20:03:42 UTC
The patch in comment #7 has been applied by someone, is there a reason to keep this bug open?
Comment 13 Thiago Macieira 2005-12-01 20:12:10 UTC
Yes: the patch has not been applied.
Comment 14 James Ots 2006-02-01 18:22:29 UTC
Is the patch valid? Should it be applied?
Comment 15 Rex Dieter 2006-02-01 18:56:24 UTC
AFAICT, the patch in comment #7 appears correct, but my opinion certainly is not authoritative.
Comment 16 Roger Luethi 2006-02-02 12:31:19 UTC
Confirming the analysis given in comments #7 and #9 is easy. The patch was written for obvious correctness rather than elegance.
Comment 17 Urs Wolfer 2006-06-12 18:15:34 UTC
*** Bug 129049 has been marked as a duplicate of this bug. ***
Comment 18 Roger Luethi 2006-10-17 21:13:31 UTC
This bug had a patch attached for almost a year now. The bug is easy to reproduce and the fix is simple. What's keeping it from going in?
Comment 19 Xushi 2006-12-08 12:01:00 UTC
Confirmed here.

I'm on kde 3.5.5 and kget 0.8.5. Even with a limit, all downloads start at the same time. My fix is to just close kget, then open it again, that way it'll stick with the limit.

Comment 20 David Wood 2007-01-14 17:30:57 UTC
Hi guys. Can someone please commit this patch? 

Right now there's a great download manager that someone went to all the trouble of writing and integrating with KDE so beautifully and it's useless because someone won't look this patch over and commit it?

What's the point of kget if it can't queue multiple downloads?
Comment 21 Dawit Alemayehu 2007-09-01 23:51:53 UTC
Sorry for the very late response, but this fix was never committed because the issue has nothing to do with kio_http. The comment in #9 is incorrect. The problem has everything to do with KGet and not kio_http. If caching is not enabled, kio_http will never look at the flag that determines how it should treat requests from the cache. And this is the proper behavior. 

What is missing is that KGet forgets to set the "UseCache" meta-data before it sends the request through. That is why the condition expected is never encountered. Anyways, this might be a moot point now since KGet is getting re-designed, but reassigning just the same...
Comment 22 Lukas Appelhans 2008-05-31 16:32:55 UTC
This should be fixed in KGet2...

Lukas