Baffled!

C

ColinS

Member
I have this one particular .ts recording of a TV programme that's causing me grief. Every other single programme that I've copied onto a USB disc and then FTP'ed out plays perfectly with VLC every time, no problems.

With this particular recording:
1) it plays from the HDR HDD (obviously)
2) it plays from the HDR USB-HDD
3) when it is FTP'ed from the HDR USB-HDD elsewhere, it just doesn't play properly. Looks either like it isn't sync'ed or as if it had been recorded from a signal that's fallen over the digital cliff!

Now, as it happens, this is the same .ts file that also gives a 'connection timeout' at the end of the FTP transfer, despite the byte-count matching the original file size. Could it be that the displayed filesize refers to the video stream only and that some critical part of the wrapper has not been copied due to the FTP timeout and so VLC can't play it properly?

I would like to get to the bottom of this one, not just for this particular file, but for any others that might display the same problem. See my FTP thread for that aspect of the problem, if you're interested.
 
You sound like you know what you're doing so excuse me for stating the obvious.
I've seen this kind of problem when files have been transferred in ASCII mode versus BINARY. Worth checking, although if you're using FileZilla then it should use binary by default anyway.
 
af123 said:
You sound like you know what you're doing so excuse me for stating the obvious.
I've seen this kind of problem when files have been transferred in ASCII mode versus BINARY. Worth checking, although if you're using FileZilla then it should use binary by default anyway.
Click to expand...
Nothing is ever as obvious as it seems, and you are absolutely right to question any assumptions on my part. I will check, but, as you say, whatever the default is (for I have not actively changed it), it works for every other file I've copied in this manner except this one! You'll understand why I'm quite baffled by this at the moment.
 
ColinS said:
Nothing is ever as obvious as it seems, and you are absolutely right to question any assumptions on my part. I will check, but, as you say, whatever the default is (for I have not actively changed it), it works for every other file I've copied in this manner except this one! You'll understand why I'm quite baffled by this at the moment.
Click to expand...

Hi Colin,

I found that the FTP server in the Humax does NOT support resume. So if I turn the HDR on but don't have the TV on and then start transfering a file using Filzilla the HDR can automatically turn itself off before the file has fully copied. If I then turn the HDR back on and try to resume the transfer it will not let me.
Did your Humax turn itself off while you were transfering your file?
 
af123 said:
You sound like you know what you're doing so excuse me for stating the obvious.
I've seen this kind of problem when files have been transferred in ASCII mode versus BINARY. Worth checking, although if you're using FileZilla then it should use binary by default anyway.
Click to expand...
Well, you were abolutely correct about Filezilla: the Transfer type was set by default to Auto; however that resulted in a Command: TYPE I from FTP, i.e. Image (binary data). To send ASCII would require a TYPE A command instead. See the trace over on my other thread.
 
David_Brown_UK said:
Hi Colin,

I found that the FTP server in the Humax does NOT support resume. So if I turn the HDR on but don't have the TV on and then start transfering a file using Filzilla the HDR can automatically turn itself off before the file has fully copied. If I then turn the HDR back on and try to resume the transfer it will not let me.
Did your Humax turn itself off while you were transfering your file?
Click to expand...
David, thank you, an interesting suggestion. However, I did have the TV on at these times (watching the *copying) and I don;t believe it did turn itself off. In any event the whole of the file size is transferred successfully. Although Black Hole has correctly said that there is no _proof_ that these 'internal' copies from HDR HDD to HDR USB complete successfully, I have now done this countless times with the same file, and on a random basis I believe that at least one copy would be successful! The fact that none of them are suggests it's something to do with this particular file, but I'm really baffled as to what, especially when, whatever it is, the HDR itself can cope with it and play it from the USB, but VLC can't.
 
Just so that everyone else knows, I've now tried a few different approaches. I managed to attach the USB HDD using an eSCSI connection and mounted the Ext3 volume. A copy of the file made directly disc to disc (rather than using FTP) still does not produce a playable copy. VLC still cannot play it properly even if I connect directly to the file on the mounted Ext 3USB HDD, rather than (a copy of a copy)!
That suggests that there is something 'not quite right' about that original copy from HDR HDD to USB; but considering that this a) does not prevent it playing properly when that USB copy is accessed by the HDR and b) it's this recording and only this recording which to date displays this problem, I'm just as baffled as I was when I started this thread.
I'm not really bothered so much about this particular recording, but what if it happens to one that I really do want to keep?! That's what's so frustrating about it, and prevents me from just deleting the **** thing!
 
Its sounding to me like the file had some sort of problem while being recorded.
If for example, the humax added a byte of null data to the backend of the file, maybe that would be why the ftp is timing out as its not recieving that last byte of null data.
Its also possible that the humax itself compensates for these errors which is why it plays back fine.

This is just pure guess work on my part, but it sounds logical.
 
ChrisDaniels said:
Its sounding to me like the file had some sort of problem while being recorded.
If for example, the humax added a byte of null data to the backend of the file, maybe that would be why the ftp is timing out as its not recieving that last byte of null data.
Its also possible that the humax itself compensates for these errors which is why it plays back fine.

This is just pure guess work on my part, but it sounds logical.
Click to expand...
You may be right Chris. It could be something like that I guess.

Looking back that this part of the FTP trace:
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
I wonder if the 'Connection Timed Out' error actually refers to the 'Opening data connection for directory list' rather than the (existing) data connection for the (now complete) file transfer. The error code decodes as follows:
  • 1xx or 3xx - Error or Incomplete reply
  • x5z - File system - These replies relay status codes from the server file system.
So, at the end of (an otherwise) successful transfer of the file, the HDR file system is unable to open an data connection (it timed out) to send back a directory listing to the FTP client, and it reports this error as part of the status of the overall transfer, causing the client to try to resume the transfer, as it isn't 'smart' enough to distinguish between the two things. Then because the HDR FTP server does not implement REST(art), the net effect is the client offers to do another transfer (overwrite? it asks) of the file again, even though every single byte is there.

We could guess that perhaps the HDR was 'busy' at the time, but randomly on multiple attempts to do this, you might expect one to be successful, but not (so far in the multiple attempts) in this case.
 
Have you tried any other media players apart from VLC? I have noticed some odd distortions on the opening frames of some ts files from the Hummy: some players are more forgiving of these glitches than others. I find that PotPlayer will often play files that defeat VLC. Splash Player (lite = free) also seems particularly forgiving. It may be VLC having a minor tantrum, rather than any reproducible problem with the file.
 
fenlander said:
Have you tried any other media players apart from VLC? I have noticed some odd distortions on the opening frames of some ts files from the Hummy: some players are more forgiving of these glitches than others. I find that PotPlayer will often play files that defeat VLC. Splash Player (lite = free) also seems particularly forgiving. It may be VLC having a minor tantrum, rather than any reproducible problem with the file.
Click to expand...
No, not yet, but I will give that a go. Thank you for the suggestion.
 
fenlander said:
Have you tried any other media players apart from VLC? I have noticed some odd distortions on the opening frames of some ts files from the Hummy: some players are more forgiving of these glitches than others. I find that PotPlayer will often play files that defeat VLC. Splash Player (lite = free) also seems particularly forgiving. It may be VLC having a minor tantrum, rather than any reproducible problem with the file.
Click to expand...
Thank you Fenlander, you were spot on. It turns out it must be VLC throwing a tantrum, as you suggested it might be. Downloaded the Splash Player Lite at your suggestion and it played first time. I have to say that the Splash Player is quite impressive, particuarly the quality of the image. Only disappointment is that it doesnt seem to be able to use the substitle stream within the .ts wrapper like VLC.
Now that I know that it's VLC with the problem, I'll try to log a bug with them and see it they can sort it out.
Many thanks again for solving the problem. Sometimes the obvious is staring you in the face and you can't see it.
 
Glad it worked. Splash Player is also very light on resources - it's the only player I've found that will reliably play 1080p on my old laptop. It does have some glitches, as you say, but I'm giving serious thought to paying $20 for the Pro version as the image enhancement feature (sharpening by another name) is a big improvement. Splash Player also has a commendably friendly interface - unlike VLC!
 
fenlander said:
Glad it worked. Splash Player is also very light on resources - it's the only player I've found that will reliably play 1080p on my old laptop. It does have some glitches, as you say, but I'm giving serious thought to paying $20 for the Pro version as the image enhancement feature (sharpening by another name) is a big improvement. Splash Player also has a commendably friendly interface - unlike VLC!
Click to expand...
Yes, me too. Very impressive indeed. It would have been a great tip even if I hadn't had a problem with this file. And talking of VLC and friendly in the same sentence, I did log a bug to them but couldn't attach the file as the max they allow is only 256 Kb! They then closed it sharpish because they aparrently couldn't relate the word "This" as in "This file ...", back to the "VLC undable to render the .ts file of a recording from a Humax HDR" of the ticket title, and asked me to define "this":rolleyes: I resisted the temptation....
Anyway, I suspect Splash Player's not finding the internal subtitles is probably something to do with the PIDs or whatever used within the wrapper. I've dropped them an email, so hopefully they'll be a little more user-friendly than VLC.
Many thanks again.
 
Bum. I just downloaded Splash Player Lite on the expectation that it would act as a DLNA client, but either I'm getting it wrong or it doesn't.
 
Aha! I've now got XMBC running and streaming fine. So with Splash to play HiDef (non-streamed) and XMBC for everything else, all bases covered!
 
You must log in or register to reply here.
Back
Top