transfer pauses then errors

I would have 3 or 4 workers open and the will be always 1 that pauses then errors out with a retry in x:xx mins
if I right click on it and select process it will go though or when the retry happens it will go through.
This will happen on any server that I connect too. Including my Own.

There is most likely a problem which causes the 1st transfer attempt to fail. You can double click the file in the transfer queue and you will get more details about the error.

There is most likely a problem which causes the 1st transfer attempt to fail. You can double click the file in the transfer queue and you will get more details about the error.
Happens all the time There is always one that is retry or sitting there.
But I will check thanks

here is what the log said

[09:42:52] Operation Begin

[09:42:52] MLST top_footer_mid.png

[09:42:52] 250-Begin

[09:42:52]  type=file;size=223;modify=20110127215623;UNIX.mode=0644;UNIX.uid=513;UNIX.gid=509;unique=808g2aa1e67; top_footer_mid.png

[09:42:52] 250 End.

[09:42:52] PASV

[09:42:52] 227 Entering Passive Mode (74,55,42,106,55,185)

[09:42:52] Opening data connection to Port: 14265

[09:42:52] RETR top_footer_mid.png

[09:43:53] Timeout (60s).

[09:43:53] Active Help:

[09:43:53] Client closed the connection.

[09:43:53] Transfer failed.

[09:43:53] Operation End

Going to try to change the mode from passive to Active Be back later

Mine does this same thing. My Host is set to close connections after so long and usually it needs to reconnect. Sometimes I'll just refresh the folder or something if I know it has timed out. If I start something too soon after a connection/reconnect it is like the worker threads/connections haven't had time to reconnect or realize there was a connection drop and my first always fails like this. I get the same results too and usually just the first fails with the rest reconnecting and the retry working fine (Although if I retry really quick sometimes I can get it to fail 2-3 times before finally connecting).

I had reported weird issues like this by email sometime back because it used to be all would fail and/or a bunch of errors and it wouldn't reconnect. They fixed half the problem, but left off the reconnect on failure. I had reported it after they fixed it, but they said it was all they could do. The other issue I have is when the connection gets dropped and I drag and drop a file nothing happens the first time. It is like I never dropped it. Then something flips internally and it realizes it has to reconnect, so the next attempt at Drag and Drop works. It is better than it was, but still not 100%.

change the mode from passive to Active had no result same issue files will pause then fail and say retry in xx:xx
then they would retry and transfer ok.
so my 3 or 4 workers open would result in 1 or 2 would be doing all the transferring continually

Mine only seems to fail that first connect/reconnect. If I have a lot of files in the queue and retry the failed thread before the other files complete then all four of my threads work fine for remaining files. So, once all my threads work then they continue to work until I disconnect or get disconnected then the first will fail again.

If yours fails then you retry and it goes then fails again with other threads going then your host may limit your number of connections. If you have 3 threads selected then SmartFTP is likely using 4 connections with one for a base command thread plus your workers. If 4 workers it is likely using 5 too.

n2rga: SmartFTP has not received any data within the last 60 seconds (timeout value) from the server. This is typically a network issue. You said the problem occurs for all servers you have tested, it is most likely on your side somewhere: NAT router, buggy software firewall/AV product, etc.

What if all his/our servers do this (in bold)

[12:00:27] SmartFTP v4.0.1165.0
[12:00:27] Resolving host name ""
[12:00:27] Connecting to x.x.x.x Port: 21
[12:00:31] Connected to
[12:00:31] 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
[12:00:31] 220-You are user number 5 of 1000 allowed.
[12:00:31] 220-Local time is now 11:00. Server port: 21.
[12:00:31] 220-This is a private system - No anonymous login
[12:00:31] 220-IPv6 connections are also welcome on this server.
[12:00:31] 220 You will be disconnected after 15 minutes of inactivity.

That would cause this to occur at 16min even with NOOP. The problem is that SmartFTP isn't detecting the disconnect or indicating it was disconnected until the first failure. If after 60sec of no commands it times out then SmartFTP should indicate a connection drop and set whatever flag it needs to internally so operations know they have to reconnect...and reconnect (This is the missing step). Much like clicking refresh on the folder does. Right now the first connection fails and times out then something internal is set so the other threads know they need to reconnect, but the first thread got the memo too late so sits there until retry. Same thing with drag and drop. If there is no connection it doesn't connect, it just ignores the drag and drop like it didn't happen, but something is flipped so it knows the next time it needs to connect. Whatever is "flipped" gets flipped too late and doesn't cause the previous option to connect and retry, so we have to drag and drop again or retry the thread again manually.

The disconnect because of inactivity message you see in the browser is irrelevant. The transfer queue in SmartFTP uses separate connections for the file transfers. It means that you can even close the Remote Browser and the transfers in the queue will not be affected.

The 15min timeout still applies to all connections. And, if the browser connection is dropped the other threads/connections are also dropped since my window has sat idle while I edit pages and nothing in the queue either.. They may still complete current transactions, but they still need to reconnect once they are idle for 15min. SmartFTP obviously sees something happened since the 2nd drag and drop or retry of the thread works. The issue is that it shouldn't take a manual 2nd try on our part for it to work. If it sees there was a drop in connection, we still want the transaction to occur, so it should do whatever is needed then to complete it and not ignore us like we really didn't mean to tell it to copy the file.

Roger: If you are seeing a problem with SmartFTP, please create a new thread instead of taking over an existing one. Thank you.

Even if it is the same problem? Sorry if it appears I took it over or anything since I did post pretty quick here. I post on a lot of other forums with what I'd consider stuck up people and posting duplicate threads for the same issue gets you yelled at and wastes space. I was only confirming n2rga's findings and that I have the same issues. All of my threads I have to retry have his same timeout/Client closed connection log, and we both have to manually retry the connection. From his posts it sounds like he knows what he is doing and since all his sites, all my sites, and even on different PCs do the same thing...I'd say there isn't a problem with our firewalls, etc. Especially since manually retrying it works fine. I furthered the observation that Drag and Drop has the same problem. The base problem for all is that SmartFTP isn't retrying/reconnecting on its own and we have to initiate it again.

Thank you roger for confirming but I beleave you might have a different issue Only way to find out is you start a new thread and we can see the outcome. We would not want support to confuse our issues at least I wouldn't.
That being said I would like to continue my support thread here.
Thank you i hope you understand
this has been happening for about a year now.
Windows was reinstalled a month ago had same issue before.
I switched from optonline to verizon fios same issue before.
all new equipment on the new setup.
So I don't think its a new work issue
I own the server I transfer too.
When I work on other peoples setup the same thing happens.
I think its time to try another ftp program and see if it happens with that. I will return