Check Sum of Downloaded File do not Match on >4GB Files Tested with#88,#100

[GOlf]

Check Sum of Downloaded File do not Match on >4GB Files Tested with#88,#100

I didn't test on #101-#103 cause download 4GB files spend more times (1 Day!! on my connectioon). This problem occur when i try to download single movies image file like .iso which size more than 4GB. when download completed it's can play about 75% in Timeline and then hang then i check the checksum with file on server and file that i downloaded it do not match!!!

This happen when
Download with IDM with 8 connections
Download with Flashget with 1, 4 connections

But if i download with IDM 1 connection or download with firefox itself  have no problem

Can this cause from Prevent leeching feature? (if not what is prevent leeching feature do?)


Thx

[rejetto]

Can this cause from Prevent leeching feature? (if not what is prevent leeching feature do?)

yes... it may be a sort of bug with this feature.
i guess it doesn't need a big file to check if such bug exists.
can someone else make a test?
i will as soon as i can

[GOlf]

today i test #102 with disable prevent leeching feature.  I load file 4.4GB with flashget 5 connection The problem is still occur

size : 4.22 GB (4,536,795,136 bytes)

MD5 of original file
14410FC4E9438693FB861EA3F2D3D075

MD5 of file from flashget
2D35F16235905C59115014A9D38CC9C7

[GOlf]

the same situation as above flashget 5 connection + #102 with disable prevent leech

file size : 63.3 MB (66,418,692 bytes)

The check sum Match!!
52E28D65AC82D74C5CC77E37B6DCF5CE

So i think only large file make a problem

[MarkV]

How about segmenting? Download managers often download a large file in segments. It could be you're getting this type of problem with flashget trying to download a file in segments. Maybe you could try disabling segments and test again...

It could even be the case that Flashget has some sort of bug when putting the downloaded parts together.

It would be very interesting to see a byte-by-byte comparision of the two files.

[rejetto]

i will make a test

[rejetto]

ok,
it took me over 5 hours  

In the end i found that a stupid soFromBeginning should be changed in soBeginning.
This appears to be trivial, but caused HFS to actually corrupt any file that was resumed from 2GB+.
That is, a 4GB file was not corrupted if the resume was made at 1GB, but corrupted if it was made at 3GB.
This is true for any version of HFS till now.
I fixed it in the next build, and will try to publish a new stable as soon as possible, like a week.

[GOlf]

Great jobs!

Many Thx to Rejetto 

I'll wait for a build that fixed this bug.