Transfer Queue inner workings

Good Day.

Recently installed v3.0.1016.10 for personal use. Been using SmartFTP since ver 1x. Seems as if the transfer queue is a hot topic with version 3x. For me too.

I've read how to disable the animation, what the queue should do after "idle", etc.

My problem, if it truly is an issue with the software, is that the requirement of using the queue is taking too long. It seems that before my current version, that I'd drag a file from the local browser to the remote and the status area of the remote browser would show that the file is uploading. Now when I drag to the remote browser, the file goes to the queue. I double click the file in the queue and the details are shown.

These details show that the program is making a new connection to the remote server, then uploading (based on rules) the file. To me this seems a bit redundant -- since there's already an open stream with the remote browser, why is a new connection need to be opened???

Am I missing a setting somewhere to use the current connection?

[I'm guessing that this is the "problem" many are having in the forum about wanting to disable the transfer queue. ]


Connections are being reused. The Transfer Queue only opens a new connection for the first transfer.


Thanks for the response.

In trying to see if the "details" window agrees with you, I went to refresh my remote browser, and ...

A). In the remote browser, if after the connection has been timed out, I right-click in the file window and click on "refresh" which does nothing. It used to. Now I have to change directory in the remote browser to get it to refresh (and the refresh button doesn't do it either) Am I missing a setting here too?

Ok, the Enable Cache checkbox was checked, so I went in and unchecked it, restarted SmartFTP, let it time out and tried to refresh which then it worked like before. Yea.

. The Details window disagrees with you. I highlighted two files to be uploaded and dragged them to the remote browser and they became listed in the Transfer queue. The first file's Status says Connecting, and the detail window shows the program establishing a connection and then it transfers the file. Then the second file appears, according to the details window, does the same thing -- establishes a connection then transfer the file.

So, that's three connections being made. Something is amiss here. I tried doing a second group while still connected, and the same thing occurs.

Ok, so I increased the "workers" from one to two and they now both connect at nearly the same time, but according to the details window, they are each opening up a connection.

I'm trying to track this down because my connection takes upwards of one minute to actually make the connection. Thus this new way of doing things is really slowing me and my work down. Before, would drag a file up to the remote browser and since that was already connected (and kept the connection by the issuance of NOOPs) the file would be uploaded in mere moments.


Please purchase a license for our product and our technical support will be able to answer your questions in more detail.

Thank you

Just a clarification. .. Will support be able to answer my questions or solve my problem?

Technical support will be able to answer your questions but there is a no guarantee the answers will solve your problem.

I am having the same problems and it is very frustrating !

I believe MAT is wrong !!!
The transfer queue opens on each and every transfer!

I also agree with dmayo2, that the "NEW" transfer routines are redundant.
The old version worked perfectly. This "NEW" version is more trouble than it is worth.
It seems to me the so-called "defaults" which everyone is having to alter to get this version to run right, should have been set to the changes we have to make from the start !!!

I tried to go back to the previous 2.x version, but it appears that you have to alter the system registry and everything, besides doing an automatic and manual uninstall. Crazy!!!

mb . . .
Buying a license to get support which gives you answers that "are not a guarantee..." sounds like a car salesman selling someone a car that he doesn't really need and then telling him the service the warranty covers can not guaranteed the solve any problems the vehicle may encounter, but buy it anyway...try your luck !! What is the purpose of "buying" the license, if the "trained" support people can not solve the problems with the Software from their company?

Geez my knees !

Duplicate posting.

I'm glad I'm not the only one that feels that this newest version isn't as good as the previous. Having spent way too much time, I was able to locate the Setting to have the Transfer Queue reuse connections:
- Tools > Settings > Queue
In the "Transfer" part on the right side, make sure that "Reuse connections in Transfer Queue" is checked.

Why this isn't checked in the default distribution I'm sure was over looked by SmartFTP. Why wouldn't you want to reuse the same connection???

However, there still appears to be redundancy here. If I'm reusing the Transfer Queue connection, that's one stream that's open. Then the Remote Browser has it's own connection, so that makes two streams open. Why not share the Remote Browser's stream to transfer files?

As I tweak my web files, and re-upload them, the Transfer Queue's connection is staying open and (now) transferring pretty quickly like the last version (but not as quick). But the Remote Browser sits there getting NOOP'd until it times out. I'm pretty sure that this is a new implementation of how the transfer of files works in SmartFTP, because in the older versions, the Remote Browser's log would show the transfer of files, not some lame notice:
"The operation has been added to the Transfer Queue. Check the Transfer Queue for the status."

Can a SmartFTP developer weigh in here and clue us in as to why the apparent change in operation?

I do agree with Bombadil in that the initial response was quite weak and did not instill any confidence in actually purchasing a license. The tech support should have been able to point me to the correct Settings so that at least the Transfer Queue reuses it's connection. With the race to the bottom in pricing for everything nowadays, service is what makes a product stand out and actually worth paying for. [I'll get off my soapbox now.]

Thank you for your valuable feedback. We appreciate your opinion and suggestions.