| Summary: | kget ignores simultaneous download limit | ||
|---|---|---|---|
| Product: | [Applications] kget | Reporter: | Ingmar Sittl <pizzaboy> |
| Component: | general | Assignee: | KGet authors <kget> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ile9999, kde, rdieter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Removal of the iteration breaking the simultaneous download limit
handle case where cache is disabled but kget requests KIO::CC_CacheOnly |
||
|
Description
Ingmar Sittl
2005-03-20 05:03:06 UTC
Confirmed i'm seeing the same problem Redhat 9 rpm's build by kde-redhat. Is there a patch we can apply? Confirmed per Willy's comment. Created attachment 10251 [details]
Removal of the iteration breaking the simultaneous download limit
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. I confirm too on arch linux 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. 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 #7: The patch is for kdelibs, not KGet. Do you think this bug is not KGet specific? Is it a KIO problem? 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. See Comment #9. It's a KIO problem, not KGet. There's a patch in Comment #7. *** Bug 117389 has been marked as a duplicate of this bug. *** The patch in comment #7 has been applied by someone, is there a reason to keep this bug open? Yes: the patch has not been applied. Is the patch valid? Should it be applied? AFAICT, the patch in comment #7 appears correct, but my opinion certainly is not authoritative. Confirming the analysis given in comments #7 and #9 is easy. The patch was written for obvious correctness rather than elegance. *** Bug 129049 has been marked as a duplicate of this bug. *** 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? 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. 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? 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... This should be fixed in KGet2... Lukas |