• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

FTPP transfer to Humax suddenly dog slow

A

aesmith

Member
Hi,

I've used the function regularly, typically to transfer BBC iPlayer downloads for programs where we missed the live broadcast. Can't remember exactly the last time, but would have been in July if not later. Everything was normal then. FTP client is Filezilla Portable v3.23.02 running on Windows 7.

Now today, using the same method, FTP is taking forever - something like 90 minutes to copy 36 meg. Looking at the FTP client logs it appears it can transfer only one chunk before losing the connection and having to log back in.

Error: Could not write to transfer socket: ECONNRESET - Connection reset by peer
Error: Connection timed out after 20 seconds of inactivity
Error: File transfer failed after transferring 524,288 bytes in 20 seconds
Status: Disconnected from server
Status: Connecting to 192.168.1.200:21...
Status: Connection established, waiting for welcome message...
Status: Insecure server, it does not support FTP over TLS.
Status: Server does not support non-ASCII characters.
Status: Logged in

Any ideas about anything that might be wrong at the Humax end to cause this? This evening I'll test with a different FTP client (Mac).

Thanks, Tony S
 
Possible. The PC is on wireless, whereas the Humax is cabled direct to router. It's something else I can check this evening. However the PC doesn't have trouble talking to anything else, including the Humax web interface. Having said that I've just gone onto the web interface and told it to update everything to current version, and now I can't get onto the web interface at all. The device isn't dead, it's still online via the remote scheduling web side, and the FTP is still crawling along with the same repeated "File transfer failed after transferring 524,288 bytes in 20 seconds" errors. Now up to 56meg in one hour 50 minutes.
 
Just tried continuous ping from PC to Humax, no drops and no particular change in round trip time during the bursts of FTP transfer. (I'm away from home, remotely controlling the PC so can do some stuff but not everything).
 
Full reboot of the Humax from power off brought back everything except the FTP function. I didn't get a chance to test with the Mac, but on consideration I don't see how it can be an underlying network issue, considering that only FTP seems to be goosed, and that it behaves in that very standardised way - transferring exactly 524,288 bytes before dropping the connection.
 
Are you using the crap Humax FTP server, or the CF betaftpd package (if you install it, turn the Humax server off: Menu >> Settings >> System >> Internet Setting)?
 
I've been using betaftpd ever since I installed the custom firmware. One thing I need to check is that the built-in ftp service is still switched off. It was, and as I said FTP from PC to Humax was working until very recently, so something has changed.
 
aesmith said:
I've been using betaftpd ever since I installed the custom firmware. One thing I need to check is that the built-in ftp service is still switched off. It was, and as I said FTP from PC to Humax was working until very recently, so something has changed.
Click to expand...
Sometimes betaftpd seems to stop functioning. I have noticed this sometimes when trying to create new directories. Try force-reinstalling the package, either through webif>diagnostics or from a Telnet session.
 
MontysEvilTwin said:
Try force-reinstalling the package, either through webif>diagnostics or from a Telnet session.
Click to expand...
How exactly does that fix it? It's only 3 files, and they're either there and usable or they're not and it won't work at all.
Reinstalling is completely pointless and won't do anything apart from waste someone's time.

If the server stops, you can check it and restart it from either the WebIf Services page or the command line "service" command.
 
prpr said:
How exactly does that fix it? It's only 3 files, and they're either there and usable or they're not and it won't work at all.
Reinstalling is completely pointless and won't do anything apart from waste someone's time.

If the server stops, you can check it and restart it from either the WebIf Services page or the command line "service" command.
Click to expand...
I don't know what is happening but try this, if you like, with betaftpd logged in as root:
Create a new folder in, for example, the mod folder
Betaftpd will crash
Look in webif > service management
Webif will report the service as running, but it isn't
Toggle the betaftpd service switch on and off: this may restart the service, but it doesn't always work. If it doesn't start the service again, the easiest way to get it working again is by force reinstalling (webif > diagnostics) which takes about 20 seconds (not a lot of time wasted) and is quicker than rebooting.
Probably unrelated, but if you try and delete the folder by ftp it fails, but if it contains any files these will be deleted. This is presumably permissions related, but it is odd behaviour to delete the files but not the folder.
 
MontysEvilTwin said:
I don't know what is happening but try this, if you like, with betaftpd logged in as root:
Create a new folder in, for example, the mod folder
Click to expand...
I did.
Betaftpd will crash
Click to expand...
It didn't.
Webif will report the service as running, but it isn't
Click to expand...
Obviously the process IS still running if it says it is. Did you check with ps ?
It might not be accepting requests, but this is not the same thing as crashed or not running.
Toggle the betaftpd service switch on and off: this may restart the service, but it doesn't always work.
Click to expand...
Really? Why not? Do some analysis.
If it doesn't start the service again, the easiest way to get it working again is by force reinstalling (webif > diagnostics) which takes about 20 seconds (not a lot of time wasted) and is quicker than rebooting.
Click to expand...
All that does is exactly the same thing as stopping and starting the service. Read the .prerm and .postinst files if you don't believe me.
if you try and delete the folder by ftp it fails,
Click to expand...
It works here, if the folder is empty. If it isn't, I get a "550 Directory not empty" message, as expected.
but if it contains any files these will be deleted.
Click to expand...
I tried that and they didn't.
This is presumably permissions related, but it is odd behaviour to delete the files but not the folder.
Click to expand...
Everything runs as root, so it's not going to be permissions related.

I don't know what's up with your box, but it's not the general case otherwise other people would be complaining about it too.
 
prpr said:
I did.

It didn't.

Obviously the process IS still running if it says it is. Did you check with ps ?
It might not be accepting requests, but this is not the same thing as crashed or not running.

Really? Why not? Do some analysis.

All that does is exactly the same thing as stopping and starting the service. Read the .prerm and .postinst files if you don't believe me.

It works here, if the folder is empty. If it isn't, I get a "550 Directory not empty" message, as expected.

I tried that and they didn't.

Everything runs as root, so it's not going to be permissions related.

I don't know what's up with your box, but it's not the general case otherwise other people would be complaining about it too.
Click to expand...
I can reproduce my observations on a second box. I have no idea why our observations are different. Could be the client software? I am using ES file explorer on Android. I could try Filezilla on Windows but as it is a problem no one else has reported, and I use samba or NFS for file transfers rather than ftp there is probably little point in me doing this. My observations seem irrelevant to this thread and no one seems to have a viable solution for the OP.
 
Thanks everyone. I tried removing and reinstalling betaftp with no change. Also using root instead of humaxftp login. Some of the tests specified above ..
- Created subdirectory below "mod" , /mnt/hd2/mod/FISHFACE
- File transfer below say 100k bytes work OK to that directory
- File transfer of large files shows same error sequence of transferring 524,288 bytes at a time between disconnect/reconnection
- Delete my temp directory

None of appears to have crashed betaftp or stop the service running.

I haven't been able to get physical access to the Humax, as the TV was always in use when I was at home. However I can confirm that the built-in FTP is disabled because when I removed betaftpd it wouldn't accept ftp connections.

Once I get access I propose to do the following, unless someone suggests otherwise ..
- Test with different ftp client, and/or different LAN connection to confirm the problem is not at the client end.
Assuming that doesn't help me find the solution ..
- Remove betaftpd
- Shutdown Humax and install latest firmware (currently running 3.00)
- Reinstate betaftpd
 
Just as an aside, using Filezilla I could delete my temporary directory (/mnt/hd2/mod/FISHFACE) even though it contained files, Filezilla logs show it deleting the files first "behind the scenes"

However if I try to delete a directory created by the Humax within My Video, it always fails with the error "550 Directory not empty", even if the directory is in fact empty. I've always thought of this as just a little annoyance, but should I be able to delete directories remotely like that?
 
MontysEvilTwin said:
I can reproduce my observations on a second box. I have no idea why our observations are different. Could be the client software?
Click to expand...
Your observations fit with the standard Humax FTP server rather than betaftpd. That one crashes at the drop of a hat.
 
aesmith said:
Just as an aside, using Filezilla I could delete my temporary directory (/mnt/hd2/mod/FISHFACE) even though it contained files, Filezilla logs show it deleting the files first "behind the scenes"

However if I try to delete a directory created by the Humax within My Video, it always fails with the error "550 Directory not empty", even if the directory is in fact empty. I've always thought of this as just a little annoyance, but should I be able to delete directories remotely like that?
Click to expand...
There will be some hidden files in the directory that your FTP client isn't showing. There's probably an option to show hidden files in Filezilla somewhere. With a series recording folder, there will be a file called .series.
 
af123 said:
There's probably an option to show hidden files in Filezilla somewhere.
Click to expand...
There is under Server>Force showing hidden files. Unfortunately on my system (Windows 7) I still cannot see the .series file. However I can see .htaccess on my web site...
 
Last edited:
Had a chance to do some testing at last. FTP from the Mac to Humax works OK. FTP from PC to Mac works OK. Only FTP from PC to Humax has a problem. Comparing Wireshark captures the difference seems to be the that PC (either Filezilla or built in FTP) doesn't immediately acknowledge the control message prior to data transfer. For example PC sequence at that point ..
Humax -> PC (control) "Response 150 Opening BINARY mode data connection for 'SOURCE.mp4'"
PC starts data transfer immediately
After around 200ms PC sends outstanding Ack on control channel
Humax resends that last control message "Response 150 Opening BINARY mode data connection for 'SOURCE.mp4'" with same Seq number, ie it's a TCP retransmission
This time the PC immediately ACKs
However from that point onwards no ACKs are received from the Humax on the data channel, which eventually times out and both connections are torn down
​
Conversely with the Mac the control message receives an immediate ACK over the control TCP session.

So it seems to be a deficiency in Windows FTP stack. I can see the same pattern with the PC -> Mac transfer, however it appears that the Mac is quite happy with that delay.

Same behaviour with either betaftpd or the Humax built in
 
Quick update on this one, my Windows hard drive failed. I was able to clone the drive to new hardware, and unexpectedly this fixed a few things, including FTP to the Humax.
 
You must log in or register to reply here.
Back
Top