Version: 2.0.1 (using KDE 4.0.0) Installed from: Compiled From Sources Compiler: GCC 4.1.2 Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1.2/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib Thread model: posix OS: Linux Almost every file downloaded with KGet for the first time is corrupted. Md5sums don't match and tar archives don't unpack. But if I start the same file to download again, sometime it is downloaded correctly (usually after the second time and almost always after the third one). The download task in KGet goes OK to 99%, then it gets "Stalled" status and then it finishes, but the file is bad. Most frequently this problem occurs with sourceforge, but I also noticed it with some ftp's. I also tested the same downloads with Firefox built-in downloader, it gets the files successfully by the first time.
Please provide an example link. Do you something "special" while downloading? Pause the download? What download speed do you have?
The problem occurs, for example, with this link: http://ovh.dl.sourceforge.net/sourceforge/gpac/gpac-0.4.4.tar.gz. But note that, as I mentioned before, it's not the persistent problem. For example, while I test this link now it finally was downloaded correctly, after the second try. I don't actually do anything special, just click the link in browser, select destination in KGet dialog and it starts downloading. The speed is usually about 150-300 KB/s but at approx. 97-99% it reduces dramatically to 0. I've noticed, if KGet manages to finish the downloading before it reduced, the file is ok, otherwise it gets 'stalled' status and then the file is bad.
On Sunday 10 February 2008 12:35:57 pm Alexey Chernov wrote: Hi Alexey it works fine here. can you please check how many threads you have set on the multithreaded plugin settings widget? note that if it is 1 it disable the plugin. and use the regular kio copy-file method to fetch the file. thanks manolito > The problem occurs, for example, with this link: > http://ovh.dl.sourceforge.net/sourceforge/gpac/gpac-0.4.4.tar.gz. But note > that, as I mentioned before, it's not the persistent problem. For example, > while I test this link now it finally was downloaded correctly, after the > second try. I don't actually do anything special, just click the link in > browser, select destination in KGet dialog and it starts downloading. The > speed is usually about 150-300 KB/s but at approx. 97-99% it reduces > dramatically to 0. I've noticed, if KGet manages to finish the downloading > before it reduced, the file is ok, otherwise it gets 'stalled' status and > then the file is bad. _______________________________________________ > Kget mailing list > Kget@kde.org > https://mail.kde.org/mailman/listinfo/kget
Hello. It's set 5 in 'number of threads' value, but I don't remember, whether I set it manually or it is so by default. I believe, I didn't change anything in settings. But now I'm in doubt. Also, maybe the cause of problem is my architecture.. I use x86_64 with SMP, so maybe this is the reason.
On Sunday 10 February 2008 2:39:52 pm Alexey Chernov wrote: > Hello. > It's set 5 in 'number of threads' value, but I don't remember, whether I > set it manually or it is so by default. I believe, I didn't change anything > in settings. But now I'm in doubt. Also, maybe the cause of problem is my > architecture.. I use x86_64 with SMP, so maybe this is the reason. 5 threads is the default value. so kget is using multithreaded plugin to download the file. can you please check on other architecture? and let us know thanks Manolito
Manolo I also got this problem too, but these days I'm very busy to post anything.. I still need to do some stuff on kget :) btw x86_64 but not sure this is the problem... on doka i experienced this problem too, don't remember exactly what fixed Manolo Valdes <nolis71cu@gmail.com> escreveu: ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. http://bugs.kde.org/show_bug.cgi?id=157570 ------- Additional Comments From nolis71cu gmail com 2008-02-10 19:28 ------- On Sunday 10 February 2008 2:39:52 pm Alexey Chernov wrote: > Hello. > It's set 5 in 'number of threads' value, but I don't remember, whether I > set it manually or it is so by default. I believe, I didn't change anything > in settings. But now I'm in doubt. Also, maybe the cause of problem is my > architecture.. I use x86_64 with SMP, so maybe this is the reason. 5 threads is the default value. so kget is using multithreaded plugin to download the file. can you please check on other architecture? and let us know thanks Manolito _______________________________________________ Kget mailing list Kget@kde.org https://mail.kde.org/mailman/listinfo/kget --------------------------------- Abra sua conta no Yahoo! Mail, o
I'm afraid, I won't be able to test it on another architecture... I've compiled only 64 bit libraries, so I don't have multilib binaries and 32 bit support. Really pity..
I've thoroughly tested the case for KGet in KDE 4.1.0 (with Qt 4.4.1) and I've found this bug luckily disappeared. I've tested both large and small files and all the md5sums have been similar. It seems to be somewhat fixed. I think, we can close the bug.