Incorrect time remaining/transfer speed for transfers

[Snowknight26]

Had to shorten the title for it to fit.

The actual issue is as such:
The time remaining/average file transfer speed for transfers that are hidden because of a small display area for currently queued files (when a scrollbar is visible) is incorrect. As soon as the once-hidden-due-to-overflow transfers become visible, the time remaining is close to 0 and the average speed is ~100 times what it should be, until it slowly converges to the actual speed. The average speed/time remaining should continue to be calculated even if those labels aren't visible. I can provide a video of the issue if necessary.

[botg]

Speed calculation does not depend on visibility of the queue entry, must be something else you are observing.

[Snowknight26]

I can get a video if you really want.

[botg]

Has there been any transfer error in the log shortly before making that screenshot?

[Snowknight26]

No. A another file simply finished transfering and this one was moved into the visible area. Similarly, if you scroll down to see some hidden entries during the transfer, the transfers that weren't visible but now are will show the same effect.

[Snowknight26]

Any word on this?

[boco]

Did you already file a bug report using http://trac.fileZilla-project.org? In this forum, threads can get lost, this one obviously did.

[botg]

Cannot reproduce

[Snowknight26]

So this is still happening 12 years later. What kind of information do I need to provide to help you guys reproduce this?

I think the easiest way to reproduce this is to drag the splitter above the transfer queue as far down as possible so that you can't see the current transfers, then after maybe 10 seconds, drag it back so the current transfers are in view.