Bug 508077 - Copy/move status dialog: using rolling averages to estimate average speed and remaining time
Summary: Copy/move status dialog: using rolling averages to estimate average speed and...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Notifications (other bugs)
Version First Reported In: 6.4.4
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2025-08-10 08:32 UTC by Tx872
Modified: 2025-08-12 21:08 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Example of spiky transfer rates that lead to poor estimations (62.12 KB, image/png)
2025-08-10 08:32 UTC, Tx872
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tx872 2025-08-10 08:32:24 UTC
Created attachment 183922 [details]
Example of spiky transfer rates that lead to poor estimations

SUMMARY

The calculation for the displayed time remaining on the file transfer dialog for file copy/move operations seems to be based off of the current transfer speed and remaining data to be transferred only.
This leads to highly variable estimations that render the information mostly useless a lot of the time (rapidly changing between 3-4 minutes and 20+ minutes, for example) .

This is especially evident when transferring multiple files from a slower/inconsistent/high-latency source (see attached screenshot for an example).

Instead, the estimation should be based on a rolling average, perhaps something like the last 10 seconds, to absorb spikes and variability and provide more reliable and useful feedback to the user.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Comment 1 Filip 2025-08-10 14:59:44 UTC
Can confirm the rapid change in time left calculation. Moving to other section, I believe it belongs to KIO.
Comment 2 TraceyC 2025-08-11 22:40:53 UTC
I can also confirm this behavior on git-master