Any FTP experts here?

C

ColinS

Member
Hi,

I'm using Filezilla (active mode) to move recordings from my external USB storage on the HDR-Fox T2 to my Media Server for long-term archiving.

In general, I have no problems at all; most files copy without incident. However, with the larger (.ts) files, this sometimes happens:

Status: Connected
Status: Starting download of /media/drive1/The Unforgettable/The Unforgettable Frankie
Howerd_20110704_2001.ts
Command: CWD /media/drive1/The Unforgettable
Response: 250 File action is successful. Proceed.
Command: PWD
Response: 257 "/media/drive1/The Unforgettable" is current working dir.
Command: TYPE I
Response: 200 Port command successful
Command: PORT 192,168,16,4,13,224
Response: 200 Port command successful
Command: RETR The Unforgettable Frankie Howerd_20110704_2001.ts
Response: 150 Opening data connection for directory list
Error: Connection timed out
Error: File transfer failed after transferring 697,679,872 bytes in 223 seconds
Now, 697,679,872 is _exactly_ the full file size on the USB-1 disc of the HDR. So this is not a data transfer timeout, but something else at the end of the transfer?

It then offers to recopy, as the Fox doesn't implement the recovery mechanism:
Command: REST 697679872
Response: 502 Command not implemented.
Error: File transfer failed
Status: Starting download of /media/drive1/The Unforgettable/The Unforgettable Frankie
Howerd_20110704_2001.ts

Anyone got any ideas why this might be happening? The downloaded files play OK though (well, with one exception - see my other thread!)

Thanks.
 
Presumably you have copied these files to the external drive in the first place in order to decrypt them, and now you are moving them somewhere else.

The first question which comes to mind is: how do you know the first copy process was successful? The Humax doesn't tell you. If the file you were copying was larger than 4GB and the external drive is FAT, you have a problem straight away.
 
Black Hole said:
Presumably you have copied these files to the external drive in the first place in order to decrypt them, and now you are moving them somewhere else.

The first question which comes to mind is: how do you know the first copy process was successful? The Humax doesn't tell you. If the file you were copying was larger than 4GB and the external drive is FAT, you have a problem straight away.
Click to expand...

Well, nothing in life is certain, but I think I know that the first copy rocess was successful as it is playable by the HDR _from_ the external USB HDD and doesn't display any issues with doing so.
As you can see in the trace supplied, the filesize is nothing like 4Gb, it is ~697Mb, and the external drive was formatted by the HDR itself and is in Ext3 format.
 
ColinS said:
Well, nothing in life is certain, but I think I know that the first copy rocess was successful as it is playable by the HDR _from_ the external USB HDD and doesn't display any issues with doing so.
As you can see in the trace supplied, the filesize is nothing like 4Gb, it is ~697Mb, and the external drive was formatted by the HDR itself and is in Ext3 format.
Click to expand...
OK, forget what I said. I didn't read your first post properly :oops:
 
Ezra Pound said:
You could try using the built in FTP client in Internet Explorer or Windows (File) Explorer, Detail here :-

http://hummy.tv/forum/threads/foxy-...or-the-hdr-fox-t2-now-released.240/#post-2914
Click to expand...
Ezra, I did manage to try this: I set up an FTP network place, and copied the .ts file directly from the USB drive of the HDR to my laptop. The FTP copy was successful all 697,679,872 bytes. However, it still won't play properly.:confused:
At least this elimated the particular FTP client as the cause ....
 
Black Hole said:
When you say won't play properly, what does it do?
Click to expand...
OK. When VLC initially loads the file (before it starts to play), the first image shows the filename across the bottom of what looks pretty much a plain green screen with some large random noise-like pixel blocks. There is no recognisable image at all; by comparison, at the same point using the HDR (whether on HDD or USB) the corresponding image is recognisably the start of the programme titles on a _blue_ background. As it then attempts to play the file, all the images are just colours like this with various other-coloured random pixel blocks, no recognisable images anywhere. You can move the cursor to any point in the file and the images will look like this. If I leave VLC to try to play it, it eventually hangs up and is no longer responsive; the process has to be deleted.
 
Not just a few stutters then. I've found that my TV and a media player box produce a few artifacts when decoding USB files from the Humax, whereas VLC on the PC is fine.

Sounds like your file is corrupt. Definitely not a HiDef source (I don't suppose it is with that file size)? Check the Enc flag isn't there in the Humax media list.
 
Black Hole said:
Not just a few stutters then. I've found that my TV and a media player box produce a few artifacts when decoding USB files from the Humax, whereas VLC on the PC is fine.

Sounds like your file is corrupt. Definitely not a HiDef source (I don't suppose it is with that file size)? Check the Enc flag isn't there in the Humax media list.
Click to expand...
Well, I would agree that it is somehow corrupt, but then if it's _that_ bad, I don't know how the Humax manages to play it from the USB disc without so much as a single dropped pixel!! It's baffling, as I said somewhere else! Yes, it was (and still is) an SD recoding and definately had no Enc flag. With Raydon's Foxy I've managed successfully to copy (as a test) a 45min/3Gb HD programme, and not a dropped pixel there either.

On the other thread I've also looked again at the above trace, and I think that the original timeout error is to do with the server filesystem trying to open another data connection to the client to send a directory listing back to the client at the end of (an otherwise successful) file transfer. The 'failure' is therefore 'misleading' in that respect I believe.

As far as playing it (or trying to) is concerned, I'm only using the 'media server' as a 'file server' here and VLC on the PC is decoding it itself. just exactly as you have done, and like you, for all other recordings, it's not only fine but exceptionally good! On the other thread I've also recorded that I was able to both a) do a disc-to-disc copy (i.e. no FTP) from the decryted Humax file and b) to get VLC to open the Humax decrypt file directly from the disc, but neither were any better.

So, to come full circle to your original observation, I'm inclined to think that 'something is not quite right' about the decrypt file produced by the Humax when it copied to USB. Of course, because this doesn't appear to affect the HDR it's also possible that 'something is not quite right' about the original recording too, and this 'error' is simply being propagated. However, I bet the VLC people would love to know how it (HDR) manages to 'ignore' this problem, when it appears to give VLC difficulty!
 
I agree with your conclusions, and I had overlooked that the Humax could play the USB file. One might surmise that if ONLY the Humax can play it, it is privvy to information (possibly contained in the other files in the set) that VLC etc does not take account of. However, this is very lacking as a working hypothesis because it makes no attempt to explain why it is THIS file and no other.
 
Black Hole said:
I agree with your conclusions, and I had overlooked that the Humax could play the USB file. One might surmise that if ONLY the Humax can play it, it is privvy to information (possibly contained in the other files in the set) that VLC etc does not take account of. However, this is very lacking as a working hypothesis because it makes no attempt to explain why it is THIS file and no other.
Click to expand...
Yes, well, I was about to say I would simply archive the set (of 4) and forget about it, as we have all taken it as far as we can for the moment, I believe, but then I thought of one last thing: I will delete the original recording and bring it back from a) the USB disc, and then b) the FTP'ed version and see what it makes of those. I suspect a) will be OK, but it'll be interesting to see what happens with b).

Oh and I've picked up another small query as a result of some of these 'trials', but I'll ask it elsewhere. Feel free to answer it. I'm learning more about this new box all the time.
 
OK, so now found the time to do these final 2 tests. Results:
a) Plays OK after restoration from the USB HDD
b) Also plays OK even when FTPed directly to the My Video directory of the HDR HDD.

So, is the aility to play the .ts file a consequence of the sidecart files?
1) deleted .thm - thumbnail vanishes, but gets recreated after playing; plays OK
2) deleted .hmt - recording info vanishes e.g. channel, running time; plays OK; .hmi file created (to hold last played position in the file?)
3) deleted .nts (but .hmt present) - won't play - 'Recording failed: unknown error"
4) deleted all files bar the .ts; plays OK

So, whatever is wrong and preventing VLC from playing this file, it would appear to be contained solely within the .ts BDAV wrapper ....

And the HDR is able to ingore whatever this is, and still play it when VLC (1.1.11) cannot.
 
You must log in or register to reply here.
Back
Top