Multi part transfers (Download) not working... ver. 6.0.2001.0

Hello mb.

I updated to the brand new version 6.0.2001.0 earlier today. Restarted my desktop and fired up SmartFTP.  I like the changes *(see below for some critique).

As the topic says; Multi part transfers (Download) not working.

I've checked the Properties and the setting is enabled for X amount of parts (10 in my case) if the file is over X amount if KB (300 MB in my case).  I also tried by overriding the option in the Properties of the file (1GB + in size) and set it to a lower amount (4 parts), to no avail.  Please advise.
 
Edit: I'm downloading via SFTP
 
 
*Regarding the new design/layout/ribbon interface:

Please re-add the connect/reconnect/disconnect buttons and functionality. I hardly ever close SmartFTP and prefer to manually reconnect/connect as needed and disconnect (rather than wait for the timeout).
 
 
 
Thank you for your time.

>multi part
This has been corrected. The next build (1-2 days) comes with the fix.
>connect/disconnect
The remote browser no longer has a dedicated connection assigned. Actually it is no longer "connection aware". Therefore such functionality won't be possible any longer. What we may consider adding in a future release are more grained connection pool settings. E.g. automatically disconnect idle connections after x seconds.

mb wrote: >multi part
This has been corrected. The next build (1-2 days) comes with the fix.

>connect/disconnect
The remote browser no longer has a dedicated connection assigned. Actually it is no longer "connection aware". Therefore such functionality won't be possible any longer. What we may consider adding in a future release are more grained connection pool settings. E.g. automatically disconnect idle connections after x seconds.
 
>multi part
Fantastic! Thank you. :D
 
>connect/disconnect
 
Yes, that idle disconnect would do and a Refresh or directory change triggers the re-connect as before/now. In the meantime, I'm just closing the connections(s) manually as needed via CurrPorts.
 
Thank you for the consideration about further implementations and control. :)

mb, thank you very much for the fast fix with 6.0 Build 2003. Multi part downloading back to working order. :)

Sorry to report mb.
 
Build 2004 has broken multi part downloads. In addition, with Build 2003, the Size column showed 'unknown' and multi part downloads stopped working.
 
A restart of SmartFTP did not correct this behavior. It was fine for 5 files prior.
 
After installing Build 2004, the Size column (this is the first test) is back to showing the size of the files.
 
But..multi part download is not working as described in the first post of this thread with the latest build (2004).
 
Environment:
Windows 7 Ultimate x64
Kaspersky IS 14.0.0.4651(g)
105MB Broadband (Fibre)

We need a bit more details on how to reproduce the problem. There were no changes related to multi part transfers between build 2003 and 2004. The problem was probably always there but did not happen before.

Ok, out of 7 files, with sizes from 300MB, 750MB to 1.33GB, only one of those files (the 3rd in queue) started correctly as a Multipart download and finished correctly with no errors.
 
Looking at the log for the other files, the multi part command is not being triggered, downloads are sent as a single part.
 
I've set the threshold at 100KB for each of my servers and then adjusted to 10 parts from 2 parts for the Default setting to test (this was after the 3rd in queue successfully downloaded as a multi part).
 
The next files in queue all downloaded as a single file regardless, so that test setting/configs made no difference.
 
This issue only cropped up the same day I upgraded to version 6.x.x - that same day I already downloaded several large files without issue (using version 5.0.1354.0 (64-bit).
 
There has not been any Windows updates or other software installs/updates. The only odd thing I noticed after the installer finished, there was not a request to do a system restart, even though it said it would need to do one because of Explorer being in use. I restarted just to be sure.
 
I'm going to do some temp file cleanups, restart the system, run a reinstall of SmartFTP 6.0 Build 2004 and restart system again and test. I'll reply later/tomorrow with the feedback.

How do you verify whether multi part transfers are used or not? It is not as easy to verify this in the logs anymore unless you set the number of workers in the queue to 1.

I always make sure the number of Workers is set to 1 (90% of the time I download in multi part) when multi part is activated for files larger than 800KB (my threshold). TO be sure, I start the queue manually. I know when multi part is used because of the blank file that is created along with the temp file, both with identical names of the file. That is 'filled' until the Endposition is reached for each part/segmented file. In-addition, the log for a particular file states multipart download = 10 will be used.

Correction: I said: "I know when multi part is used because of the blank file that is created along with the temp file" - should read: .sections file.
 
 
mb, here is the scenario, as tested on my end.
 
 
I uninstalled version 6.0.2004.0 (64-bit). I restarted the system. I did a mild Registry cleanup to remove missing classes etc that are left over from the uninstall of version 6.0 build 2004/other versions.
 
I installed version 5.0.1354.0 (64-bit). Installer requested no restart of system.
 
I opened/started SmartFTP version 5.0.1354.0 (64-bit), my server details + local file bookmarks/fav locations were all preserved as expected. :)
 
I connected to the same server, downloaded the same 7 files I mentioned from the post yesterday. All downloaded as multi part, as expected, no extra configs or such done/needed.
 
Below is an edited log of one of the files. As you'll see, there's a time stamp where Multipart is listed as triggered/activated.
 
I hope this can help you track down the issue with version 6.xxx in regards to multi part downloading.
 
 
 
<blockquote class="ipsBlockquote">
 
On file transfer starting:

[18:21:28] Key Exchange Algorithm: xxxx-xxxx-xxxxxxxx
[18:21:28] Server "xxxxx-sha2-xxxxxxxx" host key fingerprint: REMOVED
[18:21:28] Key exchange completed.
[18:21:28] Requesting service "ssh-userauth".
[18:21:28] RTT: 337.164 ms
[18:21:28] Authentication request. Method: none
[18:21:29] Received authentication banner message.
[18:21:29] Server supported authentications: publickey,password
[18:21:29] Authentication request. Method: password
[18:21:29] User authentication successful.
[18:21:29] SSH session established.
[18:21:29] Detected Server Software: OpenSSH
[18:21:29] Opening channel 0.
[18:21:29] Channel successfully opened (Local=0, Remote=0).
[18:21:29] Requesting subystem "sftp" (Local=0, Remote=0).
[18:21:29] Sending FXP initialization. Protocol version=6.
[18:21:29] SFTP protocol version 3
[18:21:29] Getting properties (Date modified, Size) of "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type"
[18:21:29] Getting attributes of "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type".
[18:21:30] Attributes successfully obtained.
[18:21:30] Multipart Transfer. Number of Workers = 10
[18:21:30] Getting properties (Date modified, Size) of "C:\FTP-Backups\xxxx\xxxx\home\xxxx\xxxx\xxxx\FileName.type"
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Resolving host name "somewhere.here.com"
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Connecting to 000.00.000.000 Port: 22
[18:21:30] Connecting to 000.00.000.000 Port: 22
</blockquote>
 

<blockquote class="ipsBlockquote">
 
On file transfer ending/completion:

[18:32:32] Key Exchange Algorithm: xxxx-xxxx-xxxxxxxx
[18:32:32] Server "xxxxx-sha2-xxxxxxxx" host key fingerprint: REMOVED
[18:32:32] Key exchange completed.
[18:32:32] Requesting service "ssh-userauth".
[18:32:33] RTT: 353.993 ms
[18:32:33] Authentication request. Method: none
[18:32:33] Received authentication banner message.
[18:32:33] Server supported authentications: publickey,password
[18:32:33] Authentication request. Method: password
[18:32:33] 9822127 bytes transferred. (1.16 MB/s) (00:00:08)
[18:32:33] Closing file handle.
[18:32:33] User authentication successful.
[18:32:33] SSH session established.
[18:32:33] Detected Server Software: OpenSSH
[18:32:33] Opening channel 0.
[18:32:33] File successfully transferred.
[18:32:33] Channel successfully opened (Local=0, Remote=0).
[18:32:33] Requesting subystem "sftp" (Local=0, Remote=0).
[18:32:33] Sending FXP initialization. Protocol version=6.
[18:32:33] 19628032 bytes transferred. (979 KB/s) (00:00:19)
[18:32:33] SSH channel closed by client.
[18:32:34] 7012191 bytes transferred. (941 KB/s) (00:00:07)
[18:32:34] Closing file handle.
[18:32:34] SFTP protocol version 3
[18:32:34] Downloading "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type". Start=2975147627, End=2978092610
[18:32:34] Downloading file "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type".
[18:32:34] StartPosition=2975147627, EndPosition=2978092610.
[18:32:34] File successfully transferred.
[18:32:34] 30932831 bytes transferred. (899 KB/s) (00:00:33)
[18:32:34] Closing file handle.
[18:32:34] File successfully transferred.
[18:32:36] 633438208 bytes transferred. (931 KB/s) (00:11:03)
[18:32:36] SSH channel closed by client.
[18:32:36] 15171584 bytes transferred. (511 KB/s) (00:00:28)
[18:32:36] SSH channel closed by client.
[18:32:37] 75300864 bytes transferred. (910 KB/s) (00:01:20)
[18:32:37] SSH channel closed by client.
[18:32:37] 2944984 bytes transferred. (0.98 MB/s) (00:00:02)
[18:32:37] Closing file handle.
[18:32:37] File successfully transferred.
[18:32:37] 15368031 bytes transferred. (712 KB/s) (00:00:21)
[18:32:37] Closing file handle.
[18:32:38] File successfully transferred.
[18:32:38] 3571631 bytes transferred. (617 KB/s) (00:00:05)
[18:32:38] Closing file handle.
[18:32:38] SSH channel closed by client.
[18:32:38] 5975829476 bytes transferred. (8.52 MB/s) (00:11:08)
[18:32:38] Getting properties (Date modified) of "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type"
[18:32:38] Getting attributes of "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type".
[18:32:38] Attributes successfully obtained.
[18:32:38] Setting properties (Date modified) of "C:\FTP-Backups\xxxx\xxxx\home\xxxx\xxxx\xxxx\FileName.type"
[18:32:38] Getting properties (Size) of "/xxxx/xxxx/home/xxxx/xxxx/xxxx/FileName.type"
[18:32:38] Using cached properties
[18:32:38] Getting properties (Size) of "C:\FTP-Backups\xxxx\xxxx\home\xxxx\xxxx\xxxx\FileName.type"
[18:32:38] Source File Size=5975829476, Destination File Size=5975829476
[18:32:38] Operation End
</blockquote>

We are unable to reproduce the problem. Sorry.

Ok, mb.
 
Just to note, version 5.0.1354.0 (64-bit) is still going strong, no issues. I can at least feel satisfied that it's not on my end, at least with version 5.0.1354.0.
 
I'll wait for version 6.0. to mature a bit before testing again as I believe the issue lies with its changes/under the hood triggers and/or the connection sharing between Remote Browser & Transfer Queue + removal of the connect/reconnect/disconnect buttons & functionality. Some where in those codes. ?
 
After all, the first 2 versions of 6.0, out of the gate had the multi part transfer issue,  odds are...
 
Thank you for your time, I'll follow-up on this at a later time and let you know the outcome with a newer build.

Hi, thank you for the update mb. I'll do a test later today and report back.

I'm finally back with a report on the multi part download issues I had in the earlier 6.0.x. versions, prior to build 2017.
 
I'm happy to report that version 6.0 Build 2017 is working as expected and has been for the past few days with approx. 10 gigabytes downloaded (various files/sizes above 800MB) and zero issues with multi part at x10 segments. In fact, I see a slight increase in my download speed (could it be a 'placebo effect' ?) and everything is smooth in the overall operation and daily usage.
 
Thank you for your efforts in tracking down the issue, mb. I think version 6 will be the best version yet!
 
Cheers.