zip files corrupting

Hey Greg,

Our plugin uses PHP to protect and serve downloads. If the download stops abruptly, the first step is to delete and upload the file again. Also, check the PHP/Apache server logs to see if any errors are listed during the same time period when you test. If you are not sure where the logs are, then after testing contact your web host and ask them to share with you.

Thanks for your quick reply Harish. This issue is baffling at present. Cannot see anything relevant in the logs and am also communicating with the host provider, although nothing obvious discovered at this stage.

I upload the file using FTP directly to the target directory. I do not upload it using Download Monitor, I manually enter the path to the file location after it is FTP’d.

This is the same approach I’ve used for all downloads for years and which work AOK except for these large files. I tested a small zip file and it works AOK. So it seems only very large files are impacted, the one tested is 206 MB and DM serves 205 MB instead, resulting in an invalid ZIP file.

As mentioned, downloading the same file via a browser using the direct URL works AOK, so it cannot be the source file, it has to be related to the PHP serving process. However, the host provider and I are not aware of any php.ini settings which impact the download process.

There is likely to be a simple explanation… once it is known!

Cheers,

Greg

Hey Greg,

Until then I’d suggest setting up the “Redirect to File” option for the download and testing again.

Hi Harish,

Thanks very much for the “Redirect to File” suggestion, which does work around the problem! ??

The symptom I don’t understand, when not using redirect to file, is why Chrome reports 205MB when using Download Monitor (DM) and yet a direct https link reports 206MB, which is correct and the downloaded file opens just fine.

In both cases, the Chrome browser downloads the reported amount of data (i.e. the download stats shown in the download display area in the bottom bar of the browser), it’s just that when using DM without redirect to file, the file size reported is incorrect.

How could using DM influence the initial file size reported by the browser?

Kind Regards,

Greg

Hey Greg,

Since the file size is large and a direct download requires our plugin to use PHP to serve it, due to memory or process time restriction the file can get corrupted or stopped midway of being served. It’s hard for us to guess what the reason might be as all servers are set up differently and you will need to test your server logs to get more details.

Thanks Harish, I appreciate your comments.

The main observation which doesn’t make sense to me is the fact that the browser reported download size when using DM is always and consistently incorrect for these large files, in this case by 1 MB, i.e. 205 MB instead of the real file size being 206 MB.

How could it be a memory or timeout issue when the browser immediately reports the wrong file size immediately at the beginning of the process?

The browser always downloads exactly the amount of data as reported at the beginning of the download process initiated by DM. It is not stopping at any point during the download because the browser downloads exactly what it displays it’s going to do… download 205 MB displayed using DM and not the correct 206 MB when using direct https.

The fact the browser reports an initial 205 MB file size and not 206 MB when using DL is likely the key clue to finding the cause.

Do you know which part of the DM download process is responsible for reporting the initial file size to be downloaded? Do you know where can I review/research this process?

Thanks,

Greg