PDA

View Full Version : Large file will not transfer


Cablevision
10-11-2005, 03:22 PM
Thank you for your help - we are attempting to use your product to upload 5-6 gig files from a Leitch editing system to a 360 systems broadcast server. They do not tranfer,
please help.

* FlashFXP v[3.2.0 ].[ ], build [1080 ], [ ]registered, [ X]unregistered, [ ]pirated
* OS [X ] WinXP, [ ] Win2K, [ ] Win98, [ ] WinME, [ ] Other
* Running behind NAT/router [ ] Yes & Model [ ], [ X] No, [ ] Not sure
* Running firewall [ ] Yes, Name [ ], Ver. [ ], or [X ] No
* Running Antivirus [ ] Yes, Name [ ] or [X ] No
* Network [ ] xDSL, [ ] CABLE, [ ] Dail-Up, [ LAN] Other


WinSock 2.0 -- OpenSSL 0.9.7g 11 Apr 2005
[R] Connecting to 360 Systems -> IP=10.10.10.3 PORT=21
[R] Connected to 360 Systems
[R] 220 ProFTPD 1.2.10 Server (Image Server FTP Server - 360 Systems) [10.10.10.3]
[R] USER anonymous
[R] 331 Anonymous login ok, send your complete email address as your password.
[R] PASS (hidden)
[R] 230 Anonymous access granted, restrictions apply.
[R] SYST
[R] 215 UNIX Type: L8
[R] FEAT
[R] 211-Features:
[R] MDTM
[R] REST STREAM
[R] SIZE
[R] 211 End
[R] PWD
[R] 257 "/" is current directory.
[R] TYPE A
[R] 200 Type set to A
[R] PASV
[R] 227 Entering Passive Mode (10,10,10,3,128,243).
[R] Opening data connection IP: 10.10.10.3 PORT: 33011
[R] LIST -al
[R] 150 Opening ASCII mode data connection for file list
[R] 226-Transfer complete.
[R] 226 Proxy Transfer Complete
[R] List Complete: 1 KB in 0.19 seconds (7.1 KB/s)
[R] TYPE I
[R] 200 Type set to I
[R] PASV
[R] 227 Entering Passive Mode (10,10,10,3,128,245).
[R] Opening data connection IP: 10.10.10.3 PORT: 33013
[R] STOR nj 27.avi
[R] 150 Opening BINARY mode data connection for nj 27.avi
[R] 226-STOR Failed::Attempt to queue more data (23684) than ByteQ has available (13291)
[R] 226 Transfer complete.
Transferred: nj 27.avi 5.69 GB in 50.36 seconds (118,419.9 KB/s)
[R] TYPE A
[R] 200 Type set to A
[R] PASV
[R] 227 Entering Passive Mode (10,10,10,3,128,248).
[R] Opening data connection IP: 10.10.10.3 PORT: 33016
[R] LIST -al
[R] 150 Opening ASCII mode data connection for file list
[R] 226-Transfer complete.
[R] 226 Proxy Transfer Complete
[R] List Complete: 1 KB in 0.16 seconds (8.5 KB/s)
Transfer queue completed
Transferred 1 file totaling 5.69 GB in 50.63 seconds (118,419.9 KB/s)

bigstar
10-11-2005, 06:25 PM
[R] 226-STOR Failed::Attempt to queue more data (23684) than ByteQ has available (13291)

Based on this line from the ftp server, it seems like the file is either too big or there isn't enough room to store a file of that big. You might contact the company who makes "360 systems broadcast server" and see if they can offer a solution.

Cablevision
10-11-2005, 08:18 PM
Based on this line from the ftp server, it seems like the file is either too big or there isn't enough room to store a file of that big. You might contact the company who makes "360 systems broadcast server" and see if they can offer a solution.

We checked the available space - there was plenty - if I may ask what does this exactly mean :Attempt to queue more data (23684) than ByteQ has available.
What is the ByteQ? Is that the destination drive?
Could there ever be something encoded in the file that keeps it from transferring?
Why does it always stop tranferring at the same point in the file?
Leitch (the file encoding software) said they are using openDML files - does this matter?

Thank you again.

bigstar
10-11-2005, 08:32 PM
I'm not really sure, that line comes directly from the server. I've never seen that specific message before and it's rather confusing. You'll need to ask the company who makes the server.

It would be very unlikely that something encoded in the file causes it to abort. unless the ftp server parses the file during upload and it encountered some sort of encoding error. Again you'd need to referr to the company who makes the server.

I don't think it matters that they're using openDML files.

Cablevision
10-12-2005, 07:40 AM
Thank you - we hope we can find a solution - your products interface is great.

MxxCon
10-12-2005, 10:52 AM
[R] 220 ProFTPD 1.2.10 Server (Image Server FTP Server - 360 Systems) [10.10.10.3]so it looks like ProFTPD server..or faked reply?

however quick search on google didn't find anything similar to[R] 226-STOR Failed::Attempt to queue more data (23684) than ByteQ has available (13291):confused:
nothing even on "Attempt to queue more data" (http://www.google.com/search?q=%22Attempt+to+queue+more+data%22)

Cablevision
10-12-2005, 11:54 AM
Thanks for your input - we are contacting the server company - it may be that the server only accepts type 1 avi's and openDML avi's are type 2 - I think....in any case I really don't think this is a FlashFXP issue - thank you for the support.

MxxCon
10-13-2005, 03:07 PM
unless that company has some fancyass special ftp server that processes avi files(i never heard of such thing), i highly doubt filetype or it's content makes any difference.
just something to consider before needlessly pointing fingers :)

Hetfield
10-13-2005, 03:35 PM
Well i do know that RaidenFTPd processes all media file types (it says which avi it is, which mp3 etc) and i can imagine that there is a script to accept or deny certain media types. Allthough i agree with you, that it's highly unlikely.

Cablevision
10-13-2005, 04:05 PM
Gentlemen - I have confirmed with 360 Systems that their server does indeed process the dv25 content wrapped in a type 1 avi wrapper - only type 1 - our non-linear editor creates dv25 content with a type 2 avi wrapper according to the openDML spec (this allows them to put timecode et. in the file). The server should say "no I'm sorry I can't possibly ingest this avi type 2 file" but it doesn't - it starts to tranfer then dumps you out - making it appear as if it's the FTP clients fault.
The reason that they process the file is because they change the wrapper to an MXF file which is the "new standard" making all these diverse devices all talk the same language. The issue is that it's a standard that everyone hasn't adopted yet.
Thanks again.

Hetfield
10-13-2005, 04:06 PM
Allrighty, thank you for your nice explanation :)