| Summary: | Copy/move status dialog: using rolling averages to estimate average speed and remaining time | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Tx872 <tx872yz339+kdebugs> |
| Component: | Notifications | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | dolphin-bugs-null, filip.kendes1, kde, kdedev, kdelibs-bugs-null, nate |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | 6.4.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Example of spiky transfer rates that lead to poor estimations | ||
Can confirm the rapid change in time left calculation. Moving to other section, I believe it belongs to KIO. I can also confirm this behavior on git-master |
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