11 / 11
Jun 2014
We've recently started hosting our video files at Amazon S3 instead of with e-junkie. Most of the files appear to work fine, but we're experiencing some inconsistencies. About 1 out of 3 video files (all hosted in the exact same way on S3) produce this error for our customers:



"This file is served directly by the seller. At this moment seller's server has failed to respond. Please try again later."



I saw this discussion about a similar issue: http://www.e-junkie.com/bb/topic/239 and the suggestions were to:



NatashaSenPlease check the following:



1. Try the link (which you have entered in E-junkie admin) in a browser and see if it works.

2. Make sure you don't have an .htaccess file blocking us in your remote folder where you have the files stored.

3. Make sure that the link to the file you entered in E-junkie admin is to a regular website and not to file hosting service as we can't read files from those links.

4. If that all is fine, ping our server from your server. If you are unable to reach our server from yours, it means there is an issue in the backbone somewhere which is beyond our control.





What's strange is that all the S3 URLs work in browsers, but a subset of the same URLs don't work when run through the e-junkie admin. I could understand if all the URLs worked the same away, but it's 3 of 9 (in our current testing) that are having an issue.



All the files in question have the exact same permissions and file naming conventions on S3. Do you have any ideas about why this may be happening? Any help is appreciated.

  • created

    May '09
  • last reply

    Jun '14
  • 10

    replies

  • 1.9k

    views

  • 5

    users

  • 10

    links

Nevermind. We figured it out. Here's what we discovered...



You CANNOT have spaces in Bucket names on Amazon S3. If you do, the URL will work in a browser for downloading, but will not work in e-junkie.



Changing Bucket names can be accomplished with http://www.bucketexplorer.com/.

Aha, thanks for the followup tip!



As a general rule, it's best to avoid using spaces in any folder path or file name that you'd expect to use in a URL, and just stick to using only letters, numbers, dashes-and_underscores.

8 months later

I have video files stored on AudioAcrobat.com.

The text links to the videos work fine when I click on them from AudioAcrobat.

I entered that link in the "Remote Product File" blank, and saved everything.



I had e-junkie send me a free download link to see what my customers will be getting. When I click the link to open the video files, my computer says it is an Adobe Reader 7.0 PDF file -- which it is not.



Several of my customers are reporting problems opening their video files. When I tested the product links earlier, this didn't happen. AND the customers with Macs can't download them at all.



Any suggestions?

We issue all downloads as a plain binary-data files, so if buyers are saying their computer thinks its an Adobe Acrobat PDF file or whatnot, it's their computer doing that, nothing to do with our end at all.



Also, when buyers click your download links, they should be choosing to Save the file (rather than Open it). Once they've Saved the file, then they can Open their own copy. You may want to add that explanation to your thank-you/download pages:

http://www.e-junkie.com/ej/help.custom.thankyou-page.htm

2 years later

I know this is an old thread, but I Googled the same phrase as the error message the original poster had and I'm having the same issue as him =



*Currently have 9/13 products that work properly, but 4 of them simply do not.

* No spaces in their name

* Verified the files download properly from Amazon S3

* Checked and double checked the product links and S3 links etc, everything seems to be lined up properly.



No matter what - after purchasing these 4 files, I get the same error as the original poster.



=(

I sent a customer support ticket. Even after completely wiping the file off Amazon and rebuilding a product from scratch I'm still getting this issue.



Also of note, on the final "Click to Download" page, when I "Right Click > Save As" it is attempting to download an html file and not the product. This might have something to do with why it isn't working?

I found the issue after discussing it with customer support. If anyone else happens upon this, the issue is that there is a 2gig limit on filesizes when using E-Junkie.



I've made a case that this needs to be more obvious, as I've never seen this documented anywhere along the process :(



So, at any rate, if anyone searches for this issue like I did and is having the same problem, make sure you aren't trying to do files over 2gig in size, and instead use the bundle options outlined here:



http://www.e-junkie.com/ej/help.package.htm



I hope E-Junkie adds this information somewhere more obvious to save headaches like mine with all the time spent uploading their large files and then getting to do it again :frowning:

We've had max. file size limits documented on this FAQ page:

http://www.e-junkie.com/ej/faq.downloads.file-size.htm



However, in light of the trouble you encountered, I have also added our max. file size limits where appropriate to the main help page for our file download feature:

http://www.e-junkie.com/ej/help.file-downloads.htm



BTW, the download links we provide are not a direct link to the download file itself; the link submits a form which then triggers a download to the user's computer, so it should not be possible to "Right-click > Save As..." -- in fact, I couldn't get any browser I tested to give me a "Save As..." option by right-clicking on the link, except for Chrome which was clever enough to submit the form and trigger the download properly anyway.

1 year later

Are you serious? 2GB? :(



I can't possibly think of why there is a limit on a file served with S3.



Why is this limit there? We're about to launch a product and find this out the hard way.



Completely unacceptable.

Unfortunately, the 2 GB per-file limit is not arbitrary. We discovered some years ago that downloads barely larger than 2 GB were running into mysterious problems, and ultimately our sysadmin concluded those problems were in fact due to a server-side hard limit imposed by the maximum value a 32-bit signed integer can represent: 2,147,483,647, which in bytes is 2 GiB (2.147 GB). Thus, bypassing this limit would require a major, comprehensive overhaul of our system from 32-bit to 64-bit architecture.



Although downloads are ultimately served from our S3 provisions whenever possible, the file must initially be cached in our local system before we can sync a copy of it to S3, and the earliest downloads would be served from our local system before that sync is completed; moreover, the local copy would be served as a fallback measure in case of any issues with S3 itself or with the network routing between S3 and our Tucson datacenter.



One approach you might consider is breaking up a larger file into chunks of 2 GB or less, setting up each chunk as a separate Single File Download product, then setting up the product you actually sell with "Package files from other products" to have it bundle links from the single-chunk products.



Also bear in mind how long it would take to download files that large, considering that outside of major metro areas, broadband service may top out at only 1.5 Mbps or so:

http://www.numion.com/Calculators/Time.html



Sellers with extremely large files to provide often use a disc-fulfillment service that can automatically duplicate and mail out data DVDs on-demand whenever an order comes in, rather than expecting buyers to babysit a download potentially for hours -- this help page lists the disc fulfillment services known to integrate with E-junkie:

http://www.e-junkie.com/ej/tips.integration.cd-dvd.htm



Finally, if you still prefer to provide your product data as a download and don't wish to use our bundling feature for that, we can recommend using us with the Continuata advanced download management service, which can support far larger files than we can, along with advanced features such as multi-part concurrent downloads that automatically reassemble into a single file upon completion, easy pausing/resuming of downloads in progress, and more. Integrating them with E-junkie is a simple matter of configuring your product with the "Send transaction data to a URL" option enabled, so you can paste the Payment Variable Information URL provided by Continuata into that product's settings, so we can notify them when the product is purchased. Find out more about Continuata here (see Products > Connect Downloader in particular):

http://www.continuata.com/