I have two theories
Text appears to be loaded as bytes. Loading this many files as bytes instead of text might be causing trouble. Another possibility is that using this many requests at once (we don’t limit the number of requests at one time) doesn’t work for some browsers. Perhaps it’s a combination of both.
Is there a test project (private links are okay) I could use to reproduce the problem? Local host works though, you said?
Yes, almost working fine for all browser, like I said from 10x try maybe only 1x error or no at all (IE and Firefox).
Chrome always okay.
And I already message the private links my test project.
I just made a commit that may help
It uses text-based loading for TEXT assets, in the course of rewriting all of this, Assets.loadText was going through bytes first, which isn’t as optimal for the browser.
I made another change (as well) which may help forward more error information if an asset does not load.
If this doesn’t resolve it, the next step will be to throttle our asset loading so we limit the number of active requests at once
Can you give me a link to get the update file? Because the latest version of openfl still 4.9.0.
You can download and replace the file manually, if you want:
After update AssetLibrary.hx, I still get the same error like before : (test it with win 7 64Bit, IE Browser)
Also, I already upload the new project that already using update AssetLibrary.hx again. Same link.
Tracking here:
I tried to update it with openfl 4.9.1 and lime 4.0.1. But I still get same error on IE.
Also I tried it localhost sometimes get same error too.
I’ve added a queue in development builds, this should probably help fix this issue
Please give it a try if you can 
Thanks!
Thank you for the update. But It’s still get same error on IE while online testing. you can try it with the same link.
I just uploaded a test that appears to be working for me.
Could you give it a try?
http://www.openfl.org/test/assets/
Thanks 
Yes, it’s work. Is there any update?
Okay, either this is caused by the fixes I have made in the development builds, or it’s due to a different server, but let’s assume its the development builds 
Now that I know that it helps with this issue, hopefully a new release will come soon!
Do you mean a queue in development build above? Or there is a new update again?
Because I already try to update the lime/_backend/html5/HTML5HTTPRequest.hx and upload it to different server but I still get the same error.
Then perhaps we’re running into a memory limit, or some other issue? Or its specific to the server?
It’s hard for me to debug a problem I can’t compile and reproduce 
Link from me, is it work on your IE or not? I can send my source code to you if you need it.
That would be great, if you don’t mind. It would really help!
On your server (with your build), I can reproduce using IE, but not Firefox.
On our server, I cannot reproduce with either browser.
I’m confused as to whether this is caused by 1.) transferring too many files at once, 2.) transferring too many files (whether they occur at once or not) or 3.) something else I’m not thinking of
In the old version of Lime, the images were preloaded like this:
Now it looks like this:
Perhaps you could try removing the progress and error event listeners, or trying onload instead of a load event listener, or removing the crossOrigin value, and see if these make any difference
Is there any constant when it fails to load, whether it is an image asset, or sound, or text asset that does not load?
Could we be reaching a general memory limit?
I just added throttling to HTML5 image loading
Hopefully this helps!
Last update HTML5 image loading (2 files - HTML5HTTPRequest.hx and Image.hx) I think solve the preloader issue on IE.
I’ll try to make a full testing on all browser.
Thank you very much for your help
