Time of the termination of loading is incorrectly calculated

[E_zombie]

in attachment

[Razzloss (razzloss)]

Does this happen all the time or with a certain file? Or after some disconnect/resume cycle?

--RZ

[E_zombie (lv77)]

1. add new TTX
2. search alternative source
3. start download
 ==> time normal

3. close linuxdcpp
4. start linuxdcpp
5. download resume
 ==> time bad

system Fedora 8 x86_64

[Razzloss (razzloss)]

Ok, still can't reproduce the problem (with 0707-core, might have to try with the public branch later...). Does the time left stay f*d up the whole download or does it get fixed after the first chunk is completed after the restart? And I'm assuming that the size column is 0 when the time left is incorrect (negative)?

--RZ

[E_zombie (lv77)]

i use https://code.launchpad.net/~razzloss/linuxdcpp/0705-core for compile code.

[Razzloss (razzloss)]

Yeah, figured that much. But I didn't see the behavior that you described with that branch either. But it might be because the first chunk completed so fast and the filesize was updated correctly after the first one.

So does the negative time left stay there for the whole duration of the download (after it appears?). Or is it only for the first chunk after restart?

--RZ

[Steven Sheehy (steven-sheehy)]

I like how you hide your search criteria in the status bar but not in the tab name. Nice. :D

[Steven Sheehy (steven-sheehy)]

I experience this too, but I don't know how to reproduce it.

[Razzloss (razzloss)]

AAAAAAAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRGGGGGGGGGGHHHHH!

[Steven Sheehy (steven-sheehy)]

E_zombie, if you could help to retest this fix and let us know your results it would be greatly appreciated.

[E_zombie (lv77)]

probable work normal, but need more time for good testing.

[E_zombie (lv77)]

rev 308

1. close linuxdcpp
2. start linuxdcpp
3 download resume
 ==> time bad

[Razzloss (razzloss)]

And I assume the Size column in the transfer parent row is 0.0?

--RZ

[E_zombie (lv77)]

whet start client speed of download normal (300-400 kb\s).
after some time it decries to zero.

[Razzloss (razzloss)]

I'd say that is a network problem and has nothing to do with the GUI or dcpp core. (Unless you can show that the file is actually being transferred and the GUI shows the speed wrong.)

--RZ

[E_zombie (lv77)]

download file from one user. apex 1.2 (wine) download stable 150-500 kb\s 2 day.

I suggest to freeze an error for more detailed checks.

[Razzloss (razzloss)]

Please compile in debug mode and produce a backtrace from the coredump in case any of the existing asserts fail. As I cannot reproduce the incorrect time left calculation nor the missing usernames, no matter what I do.

For information about building in debug mode see Debugging in http://openfacts.berlios.de/index-en.phtml?title=Ldcpp_Manual and about coredumps the part which begins with: 2) Run normally and wait for it to crash and produce a coredump.

If none of the current asserts fail (and times are negative and names missing) report back here and I'll prepare a patch with more asserts so that I could catch where everything goes wrong...

--RZ