download problem still there
 

Hello again!

Aargh, the D/L problem appeared again, at least in some form:

A download "completed", in the "Download" tab the size was reported as 0/0 and the rate as -35,436/Sec avg, 0s left.

The total file size of the "complete file" was missing 8192 bytes. Could it perhaps be related to a minimum segment size of 16384?

In the end, the incomplete-directory contained a left-over segment (sg71) 1,512,719 bytes long.

MJ

What was correct total file size?

I found the problem with the drive a: you should not see the drive anymore with the next release.
Its in CVS but sourceforge needs a while till its public visible..

Gregor

I mailed you (?) the exact file size. It was about 60 MB.

The file size doesn't seem to matter, though. I tested downloading a much smaller file, ~4 MB, and it worked most of the time. Almost always, however, the final size after download was reported as 0/0, instead of the correct size. Sometimes also, even if the download was complete, one thread/segment got stuck in the "Downloading..." state.

Twice out of about 10 D/L's, the "complete" file was too short, by 8546 and 3046 bytes.

This was with the CVS version as of 13 Feb, the current public CVS doesn't compile.

MJ

I assume, you use MacOSX.... I just committed some changes, which will make it compile again (It did withthhe old Java-SDK, with the new one some classes are missing...

If you have developer access, try getting it with ssh, there the changes with already be there, other ways can have a certain lag.

Hello arne_bab!

I don't use Mac (for this at least :-) but now when you mention it, I see that the compilation indeed fails in */macosx/GURLHandler.java.

I don't have dev access, so I'll just have to wait a while!

MJ

Sorry I got your email. I was busy recently.

Just delete the GURLHandler class... I think its not used anywhere yet. Public CVS access on sourceforge is always about 48h behind and recently even more since they are doing some internal updates.

Gregor