Bug 248176 - KGet stalls downloads at 100%, file found to be corrupt
Summary: KGet stalls downloads at 100%, file found to be corrupt
Status: RESOLVED FIXED
Alias: None
Product: kget
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
: 265509 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-17 19:47 UTC by Vlad P
Modified: 2011-02-06 20:38 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.6.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vlad P 2010-08-17 19:47:06 UTC
Version:           unspecified (using KDE 4.4.2) 
OS:                Linux

I attempted to download several .zip archives, but upon reaching 100%, the file status was still listed as "Downloading" and the speed would be listed as "Stalled". This did not change over about 30 minutes. When I attempt to open the files, they do not appear to be valid archives.

Reproducible: Always

Steps to Reproduce:
I set the multithreaded download plugin to use 5 threads and use search engines.

Actual Results:  
Files would not show up as "completed"

Expected Results:  
I would expect them to download and be completed once the download is done.

After downloading, the details of the file show a size anomaly, such as showing 277.7 MiB of 275.4 MiB.
Comment 1 Vlad P 2010-08-17 19:48:42 UTC
Sorry, I forgot to mention. KGet version is 2.4.2

(In reply to comment #0)
> Version:           unspecified (using KDE 4.4.2) 
> OS:                Linux
> 
> I attempted to download several .zip archives, but upon reaching 100%, the file
> status was still listed as "Downloading" and the speed would be listed as
> "Stalled". This did not change over about 30 minutes. When I attempt to open
> the files, they do not appear to be valid archives.
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> I set the multithreaded download plugin to use 5 threads and use search
> engines.
> 
> Actual Results:  
> Files would not show up as "completed"
> 
> Expected Results:  
> I would expect them to download and be completed once the download is done.
> 
> After downloading, the details of the file show a size anomaly, such as showing
> 277.7 MiB of 275.4 MiB.
Comment 2 Matthias Fuchs 2010-08-17 20:44:42 UTC
Are there some links you could provide?

Does this really happen always?
Comment 3 Vlad P 2010-08-17 21:11:35 UTC
Here's a sample link... It's a map pack for a GPS application.

http://dl.mapdroyd.com/maps/BAQD4DGEWEEENDJDOD6DZEPEREBEHEVDXE5DKDUE1DLD.zip

I tested it with a couple of smaller files and it did not seem to happen, but I have not been able to find other large files to test it with properly at this point.
Comment 4 Matthias Fuchs 2010-08-19 23:54:30 UTC
Is that file always failing for you?
Did you stop sometimes inbetween while downloading?
Comment 5 Joachim Mairböck 2010-09-16 11:33:30 UTC
This happens to me occasionally, especially on bigger files as well, e.g. the current fglrx driver package:
https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-9-x86.x86_64.run

The file appears to be finished, there is no more .part file in the target directory, the download job stays at 99.6 MiB / 99.2 MiB. I could successfully make the file executable with chmod, but couldn't execute it:
bash: ./ati-driver-installer-10-9-x86.x86_64.run: Das Programm kann nicht ausgeführt oder verändert werden (busy)

KGet uses pretty much CPU.
Comment 6 Joachim Mairböck 2010-09-16 12:51:54 UTC
After killing and restarting KGet, the file was redownloaded from the beginning, and this time it worked. It kept its executable flag but I could still not run it.

Then I opened the file with the "Open target" button of the finished job, it opened in Kate as expected (it is a shell script), but it nearly froze my system for about about 15 minutes with full disk access. After closing Kate, everything was normal again and this time I could execute the file. The redownload probably overwrote the faulty file.
Comment 7 Matthias Fuchs 2011-02-06 20:24:17 UTC
*** Bug 265509 has been marked as a duplicate of this bug. ***
Comment 8 Matthias Fuchs 2011-02-06 20:25:14 UTC
SVN commit 1219170 by mfuchs:

Segment retries to write data after some time.

If the Segment can't write its data it will wait for 50 msec and then retry.
If this fails 100 times an error is emitted.
BUG:248176

 M  +4 -4      multisegkiodatasource.cpp  
 M  +37 -10    segment.cpp  
 M  +13 -5     segment.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1219170
Comment 9 Matthias Fuchs 2011-02-06 20:37:05 UTC
This whole issue should finally be solved.
If it turns out that you still have this problem in 4.6.1 then please reopen this report.
Comment 10 Matthias Fuchs 2011-02-06 20:38:00 UTC
SVN commit 1219173 by mfuchs:

Backport r1219170
Segment retries to write data after some time.

If the Segment can't write its data it will wait for 50 msec and then retry.
If this fails 100 times an error is emitted.
CCBUG:248176

 M  +4 -4      multisegkiodatasource.cpp  
 M  +36 -10    segment.cpp  
 M  +13 -5     segment.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1219173