Testing download links
You can test any buyer's actual download link(s) yourself from your E-junkie Transaction Log. Just go to Seller Admin > View/Download Transaction Log (or View/Download Free Downloads Log for free links you've sent manually or via our Updates service), then click on the buyer's Transaction ID or the Item Name of any digital item in that order (note that the Transaction ID link would redirect to your Common Thank-you Page URL, if you have one set up). That will bring up the thank-you page we generated for that buyer, where you can test their download links. Note that your own test would count against the number of download Attempts you permit on that link. If you have no problems using the buyer's download link, that would rule out any problem at our end.
Please see this help page for information about link expiration.
Lately we have seen increasing reports and other indications that some nonstandard third-party software can interfere with our download process. These problems generally involve download accelerator/manager software (typically provided as a browser toolbar or extension), or some types of antivirus software, particularly if it includes a link scanner or other real-time Web browsing protection features.
You can ask affected buyers to temporarily disable such software if they're using any, or try using a different browser program which may play nicer with that software, and then try their download again. If you already scanned the file as virus-free before uploading, you may wish to reassure them of that, and you can recommend that they re-enable their antivirus scanner once the download is complete and, if they wish, scan the downloaded file for viruses before opening it.
Download connection issues
First, bear in mind that any download can only be as fast and reliable as the slowest, flakiest link in the chain, which is usually the buyer's own computer and ISP connection.
While broadband connection speeds are rated in bps (small-b bits per second), computers typically report download progress in Bps (big-B Bytes per second). At 8 bits per Byte, this means the maximum download rate a buyer sees would be 1/8th their maximum rated connection speed, likely a bit less due to networking overhead, so more like 1/10th in real-world conditions -- e.g., a typical 1.5 Mbps consumer-grade broadband connection could expect to see download transfer rates around 150-180 kBps at best.
There may also be temporary issues with the buyer's ISP or a network routing issue ("Internet traffic jam") anywhere along the route across the Internet between our download server and the buyer's ISP, or their computer could have malware such as a virus that's hogging all the available bandwidth on their connection or causing their computer to misbehave, or other problems may affect the behavior of their computer or connection.
Many consumer-grade ISP connections advertised as "high speed" only provide their maximum rated speed under ideal conditions and/or for brief bursts at the very start of any download connection. This initial-burst speed is suitable to accelerate routine Web browsing, as most Web pages and the images and other content embedded in them are generally rather small files, but larger files would only see that max speed as the download begins, which quickly gets throttled down to a much slower speed as the download size exceeds anything that would normally be viewed as part of a Web page. Most "bandwidth test" sites only test transfer rates using a fairly small file that would be unlikely to encounter the throttled-down speeds that some ISPs may impose on longer-term downloads in progress.
Download server performance
We use Amazon S3 to store and serve downloads on a long-term basis, which is about as high-performance and robust a download service as one can get at the current state of the art. After you upload a file, or after the first download of a remotely-hosted file stored on your server, within 15 minutes we would have a copy of that file synced up to our Amazon S3 provisions, from where all subsequent downloads of that file would be served, as long as we detect the original file has not changed since its last download. However, downloads within that initial 15 minute window (or in the unlikely event of an outage at Amazon S3) would be served from our Tucson datacenter, which may result in less than ideal download speeds, as we need to throttle the bandwidth allocated to such downloads in order to keep the rest of our service available to the Internet at large -- i.e., we can't allow these early downloads to saturate all our servers' available bandwidth, as that would make our site, Admin panels, and Cart service unresponsive.