Excellent, thanks!
- mickdo
Post a reply
Topic review
- martin
Re: Background transfer progress
Any chance that the taskbar progress bar could include the progress of background transfers as well? When using an external editor and saving files, it's impossible to know when the files have actually finished uploading without viewing the WinSCP window
It does. But only in 5.2.x beta:
https://winscp.net/tracker/151
- mickdo
Background transfer progress
Any chance that the taskbar progress bar could include the progress of background transfers as well? When using an external editor and saving files, it's impossible to know when the files have actually finished uploading without viewing the WinSCP window
- martin
Re: Overall progress bar
Thanks for all your ideas. I'll think about it :)
- Marcus P.
Overall progress bar
Hi Martin,
I would expect such a behaviour; To me that sounds and feels logical. And such a jump/change in the progress bar only occurs if the user takes an action by either deleting or adding stuff to/from the queue. So, that's just how it is :D Everything else would feel odd and hard to comprehend I think.
Yeah, you're right, good point. If I remember correctly, most FTP clients have such an initial phase, before the real transmission starts.
Several ideas came up to my mind:
1.) Just put the current transmission on hold to get the additional required info and resume after all data is obtained. But because a lot of servers doesn't support resume, that's certainly not the best solution, because parts of your current up/download might fail and get lost. I fact, a bad idea :)
2.) Wait until the next file transmission is completed, before executing the update. The downside here: If you only transmit one large file, the update will take forever or won't get executed at all. So, also not the best idea. Might work well with many small files though, but not in all cases.
3.) Just don't touch the current operation, in case of adding new files. The added files will be stored as a new follow-up operation in a queue, but the current up/down load will normally proceed. This would also solve your concerns about the jumps in the progress bar. For deleting files from an upload queue, I think that should be possible without any problems. You might now say, well this way, that's no longer an overall progress bar and you're right :shock: So, no perfect solution either.
4.) Reserve one connection for the lookup. For those who want to have all connections used for transmission, an option might help. But in that case you loose the overall progress bar. Downside here is the reserved connection channel. Probably, performance will suffer far less than expected because of bandwidth load balancing. To me, sounds like an appropriate idea.
From my point of view the problem becomes much easier if you ignore the "add" task at runtime. Currently we loose all progress display if there are multiple transmissions active, so this would already be a great improvement.
What do you think Martin?
Best Regards,
Marcus
I'd do it the same way you suggest.
I just do not really like how adding new tasks may have different affect on the progress indicator.
Imagine you tun 10 hours upload. When you are 99.99% done, you add another 10 hours upload. That means that your progress drops to about 49.9% and stays there even when the first upload finishes after 10 seconds. While if you wait those 10 seconds before starting the second upload, you would naturally expect (starting with empty queue) that the progress indicator starts as 0%. To me it looks strange how those 10 seconds difference have a lasting impact on progress display for 10 hours. Though I admit that this is an edge case.
I would expect such a behaviour; To me that sounds and feels logical. And such a jump/change in the progress bar only occurs if the user takes an action by either deleting or adding stuff to/from the queue. So, that's just how it is :D Everything else would feel odd and hard to comprehend I think.
Another complication is that for recursive downloads, WinSCP has to query the server to retrieve the download size. Currently, it does that only once the respective tasks starts. While to calculate the total progress, it would have to do it at the time the task is added to the queue. What is not a trivial change. Either it has to do it on foreground (what may block the main window for a while) or it would have to open an additional connection to run the query on (what may need to breache the user preference on maximal number of opened connections).
Yeah, you're right, good point. If I remember correctly, most FTP clients have such an initial phase, before the real transmission starts.
Several ideas came up to my mind:
1.) Just put the current transmission on hold to get the additional required info and resume after all data is obtained. But because a lot of servers doesn't support resume, that's certainly not the best solution, because parts of your current up/download might fail and get lost. I fact, a bad idea :)
2.) Wait until the next file transmission is completed, before executing the update. The downside here: If you only transmit one large file, the update will take forever or won't get executed at all. So, also not the best idea. Might work well with many small files though, but not in all cases.
3.) Just don't touch the current operation, in case of adding new files. The added files will be stored as a new follow-up operation in a queue, but the current up/down load will normally proceed. This would also solve your concerns about the jumps in the progress bar. For deleting files from an upload queue, I think that should be possible without any problems. You might now say, well this way, that's no longer an overall progress bar and you're right :shock: So, no perfect solution either.
4.) Reserve one connection for the lookup. For those who want to have all connections used for transmission, an option might help. But in that case you loose the overall progress bar. Downside here is the reserved connection channel. Probably, performance will suffer far less than expected because of bandwidth load balancing. To me, sounds like an appropriate idea.
From my point of view the problem becomes much easier if you ignore the "add" task at runtime. Currently we loose all progress display if there are multiple transmissions active, so this would already be a great improvement.
What do you think Martin?
Best Regards,
Marcus
- martin
Re: Feedback and a two feature requests
I'd do it the same way you suggest.
I just do not really like how adding new tasks may have different affect on the progress indicator.
Imagine you tun 10 hours upload. When you are 99.99% done, you add another 10 hours upload. That means that your progress drops to about 49.9% and stays there even when the first upload finishes after 10 seconds. While if you wait those 10 seconds before starting the second upload, you would naturally expect (starting with empty queue) that the progress indicator starts as 0%. To me it looks strange how those 10 seconds difference have a lasting impact on progress display for 10 hours. Though I admit that this is an edge case.
Another complication is that for recursive downloads, WinSCP has to query the server to retrieve the download size. Currently, it does that only once the respective tasks starts. While to calculate the total progress, it would have to do it at the time the task is added to the queue. What is not a trivial change. Either it has to do it on foreground (what may block the main window for a while) or it would have to open an additional connection to run the query on (what may need to breache the user preference on maximal number of opened connections).
I just do not really like how adding new tasks may have different affect on the progress indicator.
Imagine you tun 10 hours upload. When you are 99.99% done, you add another 10 hours upload. That means that your progress drops to about 49.9% and stays there even when the first upload finishes after 10 seconds. While if you wait those 10 seconds before starting the second upload, you would naturally expect (starting with empty queue) that the progress indicator starts as 0%. To me it looks strange how those 10 seconds difference have a lasting impact on progress display for 10 hours. Though I admit that this is an edge case.
Another complication is that for recursive downloads, WinSCP has to query the server to retrieve the download size. Currently, it does that only once the respective tasks starts. While to calculate the total progress, it would have to do it at the time the task is added to the queue. What is not a trivial change. Either it has to do it on foreground (what may block the main window for a while) or it would have to open an additional connection to run the query on (what may need to breache the user preference on maximal number of opened connections).
- Marcus P.
Re: Feedback and a two feature requests
Hi Martin,
thanks a lot for your reply.
Well, to be honest, I'm already happy that WinSCP *does* show a progress bar on the task bar icon at all, because FileZilla suffers from not having this feature:
https://trac.filezilla-project.org/ticket/2086
And I guess you're right, I never realized that windows only reflect the progress of one task. From my experience, in most cases it doesn't make a big difference though, because if you split an upload into several equal parts, they will take a fairly similar amount of upload time. Of course, that may be differ for users with other requirements.
What I would expect is that the overall amount based on transfered data (Not time) is displayed. So, for example assume that there are 3 upload threads given:
1.) 1 GB overall, 100 MB already uploaded (currently 10%)
2.) 500 MB overall, 300 MB already uploaded (currently 60%)
3.) 4 GB overall, 1 GB already uploaded (currently 25%)
If you just build the average of all percentages you would get: ((0,1 + 0,6 + 0,25) / 3) = ~0,31
But this approach doesn't reflect the overall progress very well because it doesn't consider the different amounts of data for each thread.
A much better approach would be to consider the data amounts which would result in: ((100 + 300 + 1000) / (1000 + 500 + 4000)) = ~0,25
which reflects a far better status from my point of view.
Regarding adding new tasks during runtime: Well, you would see a jump in the progress bar if you do that. But that's what I would expect because for me that feels natural.
Whether tasks that are on hold with a scheduled upload time are considered or not is certainly a design question. Personally I would consider these tasks too, but other people may have other opinions here.
Of course that's all just my opinion, how I would implement it, if I would code that.
Thanks a lot for taking the time to listen to my suggestion.
Keep up the good work,
Best Regards,
Marcus
thanks a lot for your reply.
Regarding your reference to Windows progress bar: It's not really a fair comparison as Windows 7 does not have a queue of transfers. It's displaying progress of single transfer only (equivalent to single line in WinSCP queue). When Windows shows single progress for multiple parallel transfers (Windows does that when its groups multiple buttons into one, when taskbar becomes crowded; Windows 8 does this always), it's not doing any good job as it shows progress of the least "progressed" transfer only (see attached Windows 8 screenshot). I believe this is not what you seek for.
Well, to be honest, I'm already happy that WinSCP *does* show a progress bar on the task bar icon at all, because FileZilla suffers from not having this feature:
https://trac.filezilla-project.org/ticket/2086
And I guess you're right, I never realized that windows only reflect the progress of one task. From my experience, in most cases it doesn't make a big difference though, because if you split an upload into several equal parts, they will take a fairly similar amount of upload time. Of course, that may be differ for users with other requirements.
It's not really easy to show overall progress of multiple tasks that potentially start at a different times (new tasks can be added while others are still running). How would you calculate it? I have some idea, but it is not straightforward to implement. Maybe you have better Smile
What I would expect is that the overall amount based on transfered data (Not time) is displayed. So, for example assume that there are 3 upload threads given:
1.) 1 GB overall, 100 MB already uploaded (currently 10%)
2.) 500 MB overall, 300 MB already uploaded (currently 60%)
3.) 4 GB overall, 1 GB already uploaded (currently 25%)
If you just build the average of all percentages you would get: ((0,1 + 0,6 + 0,25) / 3) = ~0,31
But this approach doesn't reflect the overall progress very well because it doesn't consider the different amounts of data for each thread.
A much better approach would be to consider the data amounts which would result in: ((100 + 300 + 1000) / (1000 + 500 + 4000)) = ~0,25
which reflects a far better status from my point of view.
Regarding adding new tasks during runtime: Well, you would see a jump in the progress bar if you do that. But that's what I would expect because for me that feels natural.
Whether tasks that are on hold with a scheduled upload time are considered or not is certainly a design question. Personally I would consider these tasks too, but other people may have other opinions here.
Of course that's all just my opinion, how I would implement it, if I would code that.
Thanks a lot for taking the time to listen to my suggestion.
Keep up the good work,
Best Regards,
Marcus
- martin
Re: Feedback and a two feature requests
Regarding the overall progress bar for "Transfer each file individually", a queue counter is certainly an improvement. However, one of the features I like most in windows 7, is the overall progress bar, that is automatically displayed on the task bar icons. So, I often minimize the application and still can see the operation progress which is currently not possible in WinSCP if you're using multiple queues or the "Transfer each file individually" mode.
First, WinSCP shows number of items in the queue on the taskbar button (when WinSCP is in background). I believe this gives you the feedback you want.
Regarding your reference to Windows progress bar: It's not really a fair comparison as Windows 7 does not have a queue of transfers. It's displaying progress of single transfer only (equivalent to single line in WinSCP queue). When Windows shows single progress for multiple parallel transfers (Windows does that when its groups multiple buttons into one, when taskbar becomes crowded; Windows 8 does this always), it's not doing any good job as it shows progress of the least "progressed" transfer only (see attached Windows 8 screenshot). I believe this is not what you seek for.
It's not really easy to show overall progress of multiple tasks that potentially start at a different times (new tasks can be added while others are still running). How would you calculate it? I have some idea, but it is not straightforward to implement. Maybe you have better :)
- Marcus P.
PostRe: Feedback and a two feature requests
Hi Martin,
Thanks for getting back to me. I think it's great to see how you guys care about people's suggestions and wishes.
Many thanks also for adding a "Delete All" case to you DB, much appreciated! I already look forward to the version that contains the implementation.
Regarding the overall progress bar for "Transfer each file individually", a queue counter is certainly an improvement. However, one of the features I like most in windows 7, is the overall progress bar, that is automatically displayed on the task bar icons. So, I often minimize the application and still can see the operation progress which is currently not possible in WinSCP if you're using multiple queues or the "Transfer each file individually" mode.
Thanks again for your support. Great tool - great site!
Kind Regards,
Marcus
Thanks for getting back to me. I think it's great to see how you guys care about people's suggestions and wishes.
Many thanks also for adding a "Delete All" case to you DB, much appreciated! I already look forward to the version that contains the implementation.
Regarding the overall progress bar for "Transfer each file individually", a queue counter is certainly an improvement. However, one of the features I like most in windows 7, is the overall progress bar, that is automatically displayed on the task bar icons. So, I often minimize the application and still can see the operation progress which is currently not possible in WinSCP if you're using multiple queues or the "Transfer each file individually" mode.
Thanks again for your support. Great tool - great site!
Kind Regards,
Marcus
- martin
Re: Feedback and a two feature requests
1.) If I use the background transfer mode with "Transfer each file individually" for simultaneously multiple file uploads, I'm loosing my overall progress display. FileZilla suffers from the same problem, but for me this would be great advantage to still have an overall progress bar in this mode.
Thanks for your suggestion.
This issue has been added to the tracker:
https://winscp.net/tracker/1031
See also:
https://winscp.net/tracker/1030
2.) If I have started a background upload using "Transfer each file individually", cancelling this upload is a pain, because I have to stop and delete every single queue entry. A function for "Delete all" would be very handy.
https://winscp.net/tracker/602
- Marcus P.
Feedback and a two feature requests
Hi guys,
just want to post some feedback from my WinSCP experience.
First of all, I have tested over 10 different FTP clients within the last days, including FileZilla, CuteFTP, WS FTP Pro, SmartFTP, FlashFXP and many more and I have to say WinSCP is the best of all.
So I already made my donation because this will be the client I want to work with in the future.
It's smart, fast and has a flicker free GUI with easy handling.
There's still something I would like to see in future updates:
I regularily upload great amounts of data (Splitted archive files) and for performance reasons, simultaenously uploads of multiple files will boost the upload speed.
While this is possible with WinSCP, there are some restrictions I'm not really happy with:
1.) If I use the background transfer mode with "Transfer each file individually" for simultaneously multiple file uploads, I'm loosing my overall progress display. FileZilla suffers from the same problem, but for me this would be great advantage to still have an overall progress bar in this mode.
2.) If I have started a background upload using "Transfer each file individually", cancelling this upload is a pain, because I have to stop and delete every single queue entry. A function for "Delete all" would be very handy.
I've tested with beta build 5.2.2.
Anyway keep up the good work, the client is already very good!
Kind Regards,
Marcus
just want to post some feedback from my WinSCP experience.
First of all, I have tested over 10 different FTP clients within the last days, including FileZilla, CuteFTP, WS FTP Pro, SmartFTP, FlashFXP and many more and I have to say WinSCP is the best of all.
So I already made my donation because this will be the client I want to work with in the future.
It's smart, fast and has a flicker free GUI with easy handling.
There's still something I would like to see in future updates:
I regularily upload great amounts of data (Splitted archive files) and for performance reasons, simultaenously uploads of multiple files will boost the upload speed.
While this is possible with WinSCP, there are some restrictions I'm not really happy with:
1.) If I use the background transfer mode with "Transfer each file individually" for simultaneously multiple file uploads, I'm loosing my overall progress display. FileZilla suffers from the same problem, but for me this would be great advantage to still have an overall progress bar in this mode.
2.) If I have started a background upload using "Transfer each file individually", cancelling this upload is a pain, because I have to stop and delete every single queue entry. A function for "Delete all" would be very handy.
I've tested with beta build 5.2.2.
Anyway keep up the good work, the client is already very good!
Kind Regards,
Marcus