Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[barbapapa]

these is two strange bug on HUGE file (i see it on 2 file with 3.6 Go), amule say on 'last see complete' : unknow (?) ... but download the file and finish it !
and when you use sort on size it take it on the opposite side ( 3,6Go < 145ko ) ( i point on something like a signed long on size or compare ? )

well it's not a big issue but may be it affect something else or may be in a near futur ...

[Jacobo221]

Hehe, thanx! There's always a new bug to find in huge files... so that's the new RC2's huge giles realted bug ;-)

Thanks a lot for that report!
Greetings.

[Jacobo221]

About "'last see complete' : unknow (?)", maybe it really never saw a user with the complete file. I guess "Last seen complete" stands for "last time I saw some user shareing the whole file" not if it has seen all parts of that file. SO maybe you have downloaded the whole file, but none of those users you connected to had downloaded the whole file already (which seems logic, I wouldn't have a 3'06GB file being shared on my pc for no longer than what I can last to burn it into a DVD or whatever ;-)

Greetings!

(P.S.: I hope Kry or DeltaHF will give a word on this issue)

[Jacobo221]

ok ,after some tests:
 - The huge_files bug is only in the Transfers tab (search tabs sorts just perfectly ok).
 - The limit between sorting ok and badly is around 2,5GB
 - Files in the early limit (2,51GB, 2.47GB, and so on) aren't strictly considered the most little ones. i.e. a file 2.51GB will be sorted between a 40MB file nd a 700MB file. This is the weirdest thing I've ever seen xDDDD

Well, I hope this helps clarifying the bug.
Regards

[barbapapa]

ok now i know where the sort bug come, i found strange that this only append on download list but not on shared list.

i look on the cpp file and see that the sort is implemented on SharedFilesCtrl.cpp and on DownloadListCtrl.cpp but the "compare" function is not the same :

on shared it is a :
file1->GetFileSize()==file2->GetFileSize()?0:(file2->GetFileSize()>file1->GetFileSize()?1:-1);

and on download a :
file1->GetFileSize() - file2->GetFileSize();

the two work most of the time execpt that compare return a int so it give a result betwenn something like [ - 2 000 000 ; + 2 000 000 ] so if the different is more than 2Go it get  a neg number and change order ... i try to copy the first on the second and it worked...

[Jacobo221]

Thanks a lot barbapapa... but remember to disable smilies when pasteing code ;-)
You could attach the patch into the patches forums ( http://www.amule-project.net/amule/board.php?boardid=47&sid= ) so anybody can get it.

Thanx a lot for the fix!
Greetings.

[Kry]

Uou're right. many thanks, and welcome to the changelog.

[barbapapa]

i think i found another on file PartFile.cpp :

void CPartFile::UpdateAvailablePartsCount()
{
   uint8 availablecounter = 0;  <- change to uint16 i think...
   bool breakflag = false;
   uint16 iPartCount = GetPartCount();
         ....

if i'm not wrong *mule get part with 9Mo so a uint8 is not big enough to handle large file, i try and it 'seem' to work...

stupid question i know but how do get i this to patch forum ? i must do a 'diff' file or something or juste copy back there ?

[Jacobo221]

About the diff question:
`diff -u > patch.diff`
Then go to the Patches forum and atach the file ;-)

Thanks for all those fixes!
Greetins