Opened 19 years ago
Last modified 6 months ago
#2086 new Feature request
|Reported by:||anonymous||Owned by:|
|Keywords:||ETA, remaining, overall, progress||Cc:||Josh Davis, Alexander Schuch, jw5801@…, kalzd|
|Component version:||Operating system type:|
|Operating system version:|
Add a progress bar indicating overall "job" progress
with an estimated time of completion. Name the job e.g.
Uploading the folder "settings"
Change History (14)
comment:1 by , 19 years ago
comment:2 by , 14 years ago
|Priority:||normal → high|
This feature is important. When I drop a set of files I want to know how long the overall transfer has to go.
- When transferring completed reset counters
- otherwise compute the ETA from the starttime, total MiB and transferred MiB
This is the only aspect of Filezilla that isn't great. (maybe download upgrades in the background...)
comment:3 by , 13 years ago
There's not even a need to have a progress bar or a 'percentage completed'. A simple ETA for the overall queue would serve just as well, simply a matter of dividing the remaining queue by the current transfer rate. This would be very helpful!
comment:4 by , 12 years ago
|Keywords:||ETA remaining overall progress added|
If this has been stalling here for 7 years because of lack of interest then I put in my positive vote as well. This is quite literally the only feature I've wanted the filezilla didn't already have.
comment:5 by , 11 years ago
I add my vote too as the first thing I spotted that annoyed me was lacking. This seeems a pretty standard sort of wish to me I confess. Sad that it's stalled for 8 years.
comment:6 by , 11 years ago
Adding my vote too.
In my view, a very basic and needed feature.
The first -and only - thing I want to know when I start a transfer is how long it'll take. ( That's because I'm used to FZ reliability, and it's so easy to restart a failed transfer, and failed transfers are well notified )
When downloading 1000+ files in a single directory and in a single bulk , reading the individual ETA is just impossible.
I don"t think this is complicated.
Maybe put an ETA for the queue, on a per server basis, and only on servers that have started transferring. Letting ETA to "?" for the Volume of servers that have not yet started transferring
( just trying to figure out what would be a headache for this simple feature request )
Adding this feature would give users a very valuable piece of information on their transfers.
comment:7 by , 11 years ago
This is a duplicate of #1860 , but there's more text here.
Should one of these be closed and merged into the other?
comment:8 by , 10 years ago
Fully support the idea!
comment:9 by , 7 years ago
Adding my vote as well.
I thought I'm just not able to find this feature in the UI, but after googling I found this open incident. Registered just to add comment.
I'm often transferring a lot of content (custom builds or training data in order of tens of gigabytes). Transfer times varies from tens of minutes to several hours and I'm doing ETA calculation manually myself to help me with:
a) the decision to leave laptop at work or to take it home
b) the decision how I should share content the fastest - to wait for the FTP transfer to finish or to fallback to use flash drivers or a network share
ETA should take into account parallel transfers to several FTPs, so simple division of total size VS current speed might not be accurate.
comment:10 by , 7 years ago
I agree... FlashFXP has it.
Queue Total Time Remaining is sorely missed.
comment:11 by , 7 years ago
cant believe that nothing happened since 12 years :-( I cant do it myself, so I'm adding my vote here too. thanks beforehand!
comment:12 by , 5 years ago
comment:13 by , 3 years ago
16 years now, actually. :(
Adding in my vote, too!
comment:14 by , 6 months ago
19 years ago. I wish I could help at this point. I'm a developer and I've been using FileZilla a lot among the past years. That feature sure sounds like something not only I am seeking for, even if that's somewhat minor, it sounds like a simple but useful addition.
I'll see if I can propose a pull request for this.
I think the counter in the bottom right could easily be
modified to support this since it already shows the
remaining megabytes for the current queue. The only
difficult point would be when to reset the overall size of
the queue used for the percentage bar?
Perhaps reset it when the queue hits zero, and otherwise,
any new files added would increment the "total" vs remaining.