I was unable to confirm this, but perhaps it can add some light and set a course of action for jDownloader users and developers. In the past I had a lot of issues with my ISP caching downloads (without me setting a proxy), because they have an HTTP transparent proxy whether I like it or not. These downloads may abort due to RS/MU issues and become incorrectly cached on the ISP's proxy. Then, every new attempt to download the file comes from the cache instead of RS/MU, and of course it will fail at the exact same point (90%? 80%? it doesn't matter), this being INDEPENDENT of jDownloader (i.e., it happened to me with regular browsers as well). The problem goes away after my ISP's cache expires and the file download is attempted again, or some other condition changes.

Now, what can we do about this?

We as users can:

1) Configure jDownloader to use a proxy server outside our ISP's network; this new proxy most probably will not have that file incorrectly cached (although it may do that after our new attempt).
2) Wait at least 24 hours for our ISP's cache entry to expire, and try again.

jDownloader could (if added that functionality):

1) Force no-cache and bypass cache headers on the HTTP request (some ISP proxies may ignore even this, although they shouldn't).
2) Add random parameters to the HTTP query (like ....&jdown=1234) in order to force the ISP's cache to interpret it as a different request and thus bypassing the incorrectly cached file (this may not work with all downloading sites).
3) Allow the user to change jDownloader's user agent string (many ISP caches take the user agent as part of the cache key), and let the user see if it works for her.
4) Correctly identify errors coming from network problems or file size inconsistences and display a different error message so the user doesn't go crazy looking for errors on her disk, anti-virus, Windows, Doors, Carpets, etc.

Just my two cents.

Guille