VideoHelp Forum

+ Reply to Thread
Results 1 to 2 of 2
  1. Member
    Join Date
    Aug 2009
    United States
    Search Comp PM
    I have an .MKV video file on an FTP server that I would like to to download. When I try and download it via FTP it plays fine using any number of players, including MPC:HC, except that it stops at 59:35. It is supposed to be roughly 1:45:00 or so. The file is about 8.5GB and I have been transferring it via BitKinex. Here's the kicker. I have limited access to remote in to the server, but enough to run an md5 checksum that passes. After I download it to my local machine, however, the md5 fails.

    There are 2 things that I think could be related to the issue that people on this forum may be able to help me with:
    1.) Could filesize be playing a part here? Do you think 59:35 is the mysterious 4GB cap? (Even though I am using NTFS on all my drives?)
    2.) My FTP clients (all that I have tried) automatically attempt to download the file using Binary. Is there any textual information in the container/header/etc that would require this to be downloaded using ASCII?

    I only ask because each time I make a change to the way I do this I have to wait 10+ hours before I know if it worked, so if anyone has any advice I truly appreciate it.

    Also, I have downloaded multiple .MKVs using this same method previously with no issues. Some of which were slightly over 4GB.
    Quote Quote  
  2. Banned
    Join Date
    Oct 2004
    Search Comp PM
    If your FTP server is a Windows box, there's no telling what is going on here. Any sort of weird Windows problems or Windows related ftp issues could be to blame. I don't trust Windows at all for ftp and don't recommend its use for ftp servers.

    Binary downloads are ALWAYS correct. ALWAYS. It doesn't matter what the source is. ASCII downloads are wrong for things like video files.

    I'd suggest you try to verify that the file on the server is really correct and that it plays beyond the 59:35 mark. Assuming that the md5 checksum is correct in no way proves that the file will actually play correctly. You could have a corrupt file, take an MD5 checksum, and then have a correct checksum for a bad file.
    Quote Quote  

Similar Threads