LoaderMax Problems with a media proxy server [SOLVED]

[Lixus]

Hi everyone,

 

i've got a question regarding LoaderMax, maybe someone has had a similar problem... (This is no crossdomain.xml issue)

 

I'm developing a Flash website with AS3 / FlashDevelop and rely on the LoaderMax class, mainly for loading Images and SWFs. The website runs well on all servers we tested, but not on the live server of our customer where it is supposed to be. If you open the site on the live server in Internet Explorer or Google Chrome, it crashes the Flash-Plugin completely. This happens when the loading progress begins.

 

This live server is a rather complex structure of servers which i don't completely know. What's important is that the URLs of the files i'm trying to load are being redirected to another URL with a "302 moved temporarily" status.This seems to be the main problem because now my loader tries to load every single file up to 4 times (according to the FireBug network monitor). Here are the network logs for one file, for example: (logo.png, 49 KB)

 

1 | 302 Moved Temporarily | 344 Byte | Original Server

2 | 200 OK | 6.7 KB | Proxy Server

3 | 302 Moved Temporarily | 344 Byte | Original Server

4 | 206 Partial Content | 42.3 KB | Proxy Server

 

Sometimes, the second and the last access are both "200 OK" aith the full 49 KB.

 

This was inside Firefox, where the site actually loads and shows up. The problem occurs in IE (all versions) and Chrome.

Is it possible that this somehow kills the ActiveX Plugin and the Chrome one, and might this have something to do with LoaderMax? Did anybody ever have a similar problem?

 

Thank you in advance!

Cheers,

Felix

[GreenSock]

First off, the 4 loads sound normal if your file is in a LoaderMax queue because the first load is for the file size audit (and since the file moved, it must make the second request at the new location) and the 3rd/4th are the requests for full load - see http://www.greensock.com/loadermax-tips/#10

 

A few questions for you:

 

1) Are you using the latest version of LoaderMax? There was a bug discovered in certain browsers (like Chrome) that caused them to incorrectly use the cached partial load from the file size audit as the full load, but that was worked around in more recent versions. Again, the bug wasn't in LoaderMax - it was the browsers or the Flash Player, but it was worked around in recent versions of LoaderMax so make sure you're up to date.

 

2) Have you tried using a standard Loader for the problematic content? If so, did it work as expected? The goal here isn't to have you use standard Loaders (there are known bugs in Adobe's Loader) but it helps to identify if the issue is LoaderMax-specific or not.

 

3) Can you post a very simple example that reliably replicates the issue? It's VERY helpful in terms of troubleshooting if I can publish a file, add trace() statements, poke around and experiment. I need to see the problem.

[Lixus]

First of all, thank you for your answer!

I set auditSize to false in the LoaderMax and set the estimatedBytes for each loader, but this did not solve the problem...

 

To answer your questions:

 

1) The version of the LoaderMax i'm using is 1.52. I just noticed the latest is 1.761. I'll definitely try that new version!

2) I didn't, yet... I will try that. I will also try loading the file directly from the remote server, shipping around the 302 redirect.

3) The problem is that this only happens on this one specific server to which i don't even have direct FTP access... But i can PM you a link to the preview where you will see the problem.

 

Here is the code i'm using to load the assets:

 

private function loadMainAssets(event:Event = null):void
	{

		loader_main = new LoaderMax( { maxConnections : 1, auditSize : false } );

		loader_main.addEventListener(LoaderEvent.IO_ERROR, function(e:LoaderEvent):void { trace("error occured with " + e.target + ": " + e.text); } );
		loader_main.addEventListener(LoaderEvent.ERROR, function(e:LoaderEvent):void { trace("error occured with " + e.target + ": " + e.text); } );
		loader_main.addEventListener(LoaderEvent.CHILD_FAIL, function(e:LoaderEvent):void { trace("error occured with " + e.target + ": " + e.text); } );
		loader_main.addEventListener(LoaderEvent.OPEN, loaderOpen);
		loader_main.addEventListener(LoaderEvent.COMPLETE, loaderComplete);
		loader_main.addEventListener(LoaderEvent.PROGRESS, loaderProgress);


		try{ loader_main.append(new ImageLoader("gfx/logo.png", { name:"logo", estimatedBytes: 50194 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new ImageLoader("gfx/cursor_new.png", { name:"cursor", smoothing: true, estimatedBytes: 2919 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new ImageLoader("gfx/cursor_new_hover.png", { name:"cursor_hover", estimatedBytes: 2802 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new ImageLoader("gfx/menu_bg_1.png", { name:"menu_bg_1", estimatedBytes: 34604 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new ImageLoader("gfx/menu_bg_2.png", { name:"menu_bg_2", estimatedBytes: 31109 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new ImageLoader("gfx/menu_bg_3.png", { name:"menu_bg_3", estimatedBytes: 37859 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new SWFLoader("gfx/assets.swf", { name:"assets", autoPlay:false, estimatedBytes: 1189071 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new SWFLoader("gfx/videoplayer.swf", { name:"videoplayer", autoPlay:false, estimatedBytes: 27372 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new SWFLoader("gfx/worldbuttons.swf", { name:"worldbuttons", autoPlay:false, estimatedBytes: 44907 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new SWFLoader("gfx/thumb.swf", { name:"thumb", autoPlay:false, estimatedBytes: 7734 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new SWFLoader("gfx/ui.swf", { name:"ui", autoPlay:false, estimatedBytes: 20516 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new SWFLoader("gfx/agerating.swf", { name:"agerating", autoPlay:false, estimatedBytes: 6499 } )); } catch (e:Error) { trace(e); }
		try{ loader_main.append(new XMLLoader("xml/dkcr_" + regio_language + regio_country + ".xml", { name:"xml", estimatedBytes: 26000 } )); } catch (e:Error) { trace(e); }

		try{
			loader_main.load(true);
		} catch (e:Error) { trace(e); }
	}

 

I think the easiest, but dirty solution is to directly load the files from the URL they're being redirected to. I'm beginning to think it's a bug in the content delivery network software that makes the redirects...

 

Thank you again!

[GreenSock]

Yeah, I'd definitely recommend updating to the latest version and then let us know what you find after addressing #1/#2.

[Lixus]

OK, it's running now!

What really did the trick was setting auditSize to false. I did this even before i posted the original post, but somehow the CDN did not deliver the updated file to me.

It's still strange though that loading the file headers first in combination with the redirect caused the plugin to crash... Sadly, it's not easy reconstructable since it only happens in this particular server environment...