Your best friend for file transfer.

Fetch application logoFetch

Stalled Downloads, FXPing, Etc (11 posts)

  • Started 9 years ago by davedit
  • Latest reply 9 years ago from Jim Matthews
  • davedit Member

    Hi, I was having a couple of issues with Fetch that I was hoping to get help with. Apologies if these problems are not Fetch's fault...

    1) Stalled downloads... Alright, I know this has been covered a lot, but it still happens to me. I've tried the Obscure option "Contact server during long transfers", but I still get stalled downloads. Oddly enough, this option actually has an adverse effect. I only get stalled downloads if the files are big (it seems to be a time issue... how long it takes to get the file). Now when I have the obscure option UNCHECKED, I can successfully download 50mb files and keep going to the next file. However, if I have the obscure option CHECKED, the 50mb file stalls. I've got no idea why this is... I've asked the system admin, and he told me the server is not running Windows NT 4 Service Pack 6, but rather Linux.

    Something else I noticed is that my downloads never stall if the server is on port 21. Any other port and it stalls if the download is too long. This isn't just the case for Fetch, but for any FTP program I've tried (barring any Windows programs). Any ideas?

    By the way, would there be a way to make Fetch automatically stop stalled downloads after X amount of time, and continue with your queues, and if so, could it possibly be implemented as an Obscure option or something?

    2) FXPing... or direct server to server transfers. With Fetch, I can never do a direct server to server transfer when I'm trying to send to a server on port 21. Port 21 to port 21, or some other port to port 21, it never works, only indirect. I get this error:

    425 Can't open data connection.
    ftp_xfer: -30000 (state == XFER_GET_TRANSMITTING)

    However, direct server to server transfers work great from port 21 to any other port, or any other port to any other port. Most other FTP clients I've tried that support direct server to server transfers are the same way, except for one exception. I can successfully do a direct server to server transfer from any other port to port 21 using an old version or RBrowser Lite (3.3.6... although I cannot in their newest version). I cannot figure out for the life of me why that is.

    3) Etc... Eh just a small question. In 5.0.2, any error dialog boxes that came up caused a massive CPU spike that sent my processor usage and temperature through the roof. I'm yet to get an error dialog box in 5.0.3b1 as I just started testing it yesterday, but I was curious if this was a known and/or resolved issue.

    Thanks in advance!

    Posted 9 years ago #

  • davedit Member

    Regarding the error dialog boxes causing CPU spikes, I finally got one, and was happy to see that there was no spike!

    Posted 9 years ago #

  • Jim Matthews Administrator

    The most common cause of long stalled transfers is a bug in most home network routers. FTP sessions use two connections, a control connection and a data connection. During a long transfer the data connection is busy but the control connection is idle, and some routers take that as a signal to close the control connection after 5 minutes or so. Once the control connection is closed the transfer can not complete.

    The Contact server during long transfers option tries to work around this bug, but only works some of the time. As for why you don't see stalls on port 21, it could be that your router is smart enough to not drop idle port 21 connections. Just out of curiousity, what router brand and model do you use? I've had good luck with Apple's Airport Extreme Base Stations.

    We have some ideas for improving the handling of stalled transfers that we hope to implement in future versions.

    As for the direct server to server transfers, could you post a transcript of a successful transfer with RBrowser, and an unsucessful attempt to transfer the same file with Fetch?

    Thanks for checking the CPU spike with 5.0.3b1; we've fixed quite a few bugs for this release, and I'm glad that was one of them.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 9 years ago #

  • davedit Member

    Thanks for the explaination on FTP connections.

    My router is a pretty old Linksys Etherfast Cable/DSL Router, model BEFSR41. My ethernet cable goes straight from the modem to the router. I do have a Base Station hooked up to the router as well, but I don't have to go through that unless I'm using wireless, which I don't when I do the transfers.

    Odd though, I wonder why Contact server during long transfers would cause me to stall quicker than not having it on...

    Haha, I checked the transcript when I successfully FXPed in RBrowserLite, but I don't think this will be much help, it didn't tell me much:

    <--[8]NOOP

    -->[8](29)
    200 NOOP command successful.

    <--[12]NOOP

    -->[12](29)
    200 NOOP command successful.

    <--[8]NOOP

    -->[8](29)
    200 NOOP command successful.

    As for an unsuccessful attempt in Fetch:

    425 Can't open data connection.
    ftp_xfer: -30000 (state == XFER_GET_TRANSMITTING)

    Posted 9 years ago #

  • davedit Member

    Err, I mean I'm connected directly to the router.

    Posted 9 years ago #

  • Jim Matthews Administrator

    I'd actually need to see the complete transcript from both RBrowser and Fetch; if you'd rather not post them here you can send them to bugs at fetchsoftworks dot com.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 9 years ago #

  • davedit Member

    Alright sent.

    Posted 9 years ago #

  • davedit Member

    You know, I was noticing that FTP transfers never stall regardless of port when using a web browser (at least with Camino and Safari). Any idea why this might be?

    Posted 9 years ago #

  • Jim Matthews Administrator

    It could be that those web browsers don't care whether they receive a "transfer finished" reply from the server, which is what Fetch is waiting for when it stalls. I'd have to look at packet traces to be sure that was the difference.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 9 years ago #

  • davedit Member

    Ah I see, thanks. Is there an advantage to waiting for a "transfer finished" reply from the server?

    Posted 9 years ago #

  • Jim Matthews Administrator

    The main reason to wait is that then you have confirmation that the transfer succeeded. Another is that it lets you continue to use the connection to the server.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 9 years ago #

Reply

  • Or nickname, if you prefer.
  • This will be kept confidential.
  • This is to ensure that you’re a person, not a spambot.