ggritmon

I didn't. I called dispose() on the XML that initiated that loader. Ideally, the VideoLoader that XML instantiated shouldn't be disposed of just because I disposed of the XMLLoader.

I figured out the issue. I have an AssetManager class which sorts the loaded elements into various other managers (VideoManager, XMLManager, etc). To garbage collect, I dispose(true) and unload() any loaders which I no longer need after filing their content, like XMLLoader. For obvious reasons, I must keep VideoLoaders around since they contain the API for video playback. The problem was that when the main assets.xml was complete, the garbage collector called dispose(true) and unload()...which (I guess) does so on all the Loader children as well (ie: everything, including videos). As a result, the videoLoaders were dumped and their properties null. I added a conditional which says not to dispose() of any XMLLoaders which contain children. Does that seem like the best approach?

I trace the _ns & _sound values at the bottom of the _refreshNetStream() method, and they are valid. I don't see _dump() called after this point, but the values become null after this point.

Unfortunately, very simple sample FLAs aren't reproducing the error. I don't have the time to pinpoint the exact cause, but I will continue to report my findings & see if anything raises a red flag. When the VideoLoader child is reported complete, the _sound & _ns values exist. When the XML finishes loading all its children & is itself loaded completely, I am seeing _dump() and _refreshNetStream() both get called. Unfortunately, after this point _ns & _sound no longer exist. I've tried this with both flv & f4v files & get the same result.

I see. I was looking under the documentation for SWFLoader, which didn't mention that. Worked like a charm, thank you! (P.S. I totally agree with defaulting to 'child' like it does)

Greensock, domain applies to the security domain. I believe this poster (and myself included) would like to know if there's a way to control loaderContext.

I love the ability to have all my assets in a single XML that then is loaded using XMLLoader, but I need to be able to set the context of my SWFLoader to ApplicationDomain.currentDomain (so I can access the classes within). While I can instantiate the entire domain & add it to the vars of a new SWFLoader in AS, I can't set it as part of an XML node, and by the time I know about it in my AS, it's already being loaded.Is there a way to continue loading my SWFs via XML but also set the domain to SAME?

Just downloaded the latest (1.895)...didn't resolve the issue

How can I tell if I'm using the latest version? /** * VERSION: 1.881 * DATE: 2011-08-15 * AS3 * UPDATES AND DOCS AT: http://www.greensock.com/loadermax/ **/

I never call dispose on it, and I set LoaderMax autoDispose to 'false'. It looks like already by the time LoaderMax has fired onLoadComplete the VideoLoader is gone.

As usual, when I simplify things down to a demo, everything works fine.

After loading a series of assets of varying types, I construct a GreensockVid instance (my own class) for each VideoLoader & add them all to a VideoManager instance. Unfortunately, when starting a GreensockVid, I get the following error: TypeError: Error #1009: Cannot access a property or method of a null object reference. at com.greensock.loading::VideoLoader/set volume() at com.greensock.loading::VideoLoader/set videoPaused() at com.greensock.loading::VideoLoader/playVideo() at com.h5g.video::GreensockVid/start() ... The VideoLoader instance is added to the video manager as soon as its onChildComplete fires: this._videoManager.addItem(new GreensockVid(targetVid), targetVid.name); My video start method is pretty straight forward: public function start():void { this._vidLoader.playVideo(); this._vidLoader.rawContent.attachNetStream(this._vidLoader.netStream); } I'm not sure what's causing this problem. I was wondering if maybe the VideoLoader is automatically disposing of it's properties when it's only reference is the instance within the GreensockVid?

I understand that LoaderMax is smart enough not to call load() if the asset is already loaded...the problem is that it's not registering it as loaded, so the progress of the full LoaderMax package never reaches 100%.

No, I didn't. I assumed that the SelfLoader realized it couldn't exist without itself already having started loading. Also, it was appended to another LoaderMax which was told to load(), so shouldn't it have started loading as a result of that?

Sorry about not zipping the MP3 first. Further investigation has revealed that Flash assumes all MP3s were encoded at 44100hz. Once I reencoded the audio assets, everything worked as expected. That's an awful big bug for Adobe to just keep in Flash for who-knows how long.

I am having a similar issue with Sound duration, even after completely preloading the Sound. Turns out that Actionscript's built-in Sound.length is not reliable. I tried using the MP3Loader and got the same inaccurate result. Perhaps it's an issue with smaller files, since they load too quickly for load speed to be enough information. Please see attached MP3. The sound is under 3 seconds, but is being reported at almost 4. I have been unable to find a resolution to the issue, but it seems like just the sort of thing the LoaderMax library would resolve

It appears the SelfLoader doesn't check whether the target 'self' is already loaded, so if I instantiate SelfLoader after the SWF has already finished loading, my preloader will simply never complete. Is this a known issue?

First off, thanks so much for the quick & constant communication. You rule. 1) If you dispatch a VIDEO_STOP event, then a user could listen to either or both. As you mentioned, having stopVideo() do nothing but stop the video would be the same as pauseVideo, so make it do something else. No reason you couldn't make the method take some optional parameters. stopVideo(reset:Boolean=true, clear:Boolean=true); 2) I agree that asking you to fix an issue I can't reproduce is not the best of requests. I will keep my eyes open for the issue to return & create an example as soon as that happens. Thanks for all the effort you've already put into this.

1) I totally understand & respect the desire to not bloat the API. My point is that stop() is a fairly common video functionality that is absent from the current API. I can assume that pause() and seek(0) do the same thing, but am unsure what other timers/event handlers/etc you may have going on that may be unnecessary when what I am actually doing is putting the video entirely into standby mode again. In addition, stopping a video means the video is 'over' just like the video completing does. Calling stop() could result in an instant VIDEO_COMPLETE event, allowing handlers to differentiate it from a pause and continue with anything they may have been waiting to do until the video ended. 2) The NetStream event issue is definitely a bug in their API. In this case, I really noticed the problem when I was playing very short videos (2 or 3 seconds). I added a listener for VIDEO_COMPLETE and had it (conditionally) restarting the video immediately. The second request for the video kept triggering an immediate VIDEO_COMPLETE. Everything worked as expected once I added the logic I mentioned to the VideoLoader class. Naturally, I just tried to create an example file for you and everything worked perfectly using the out-of-the-box VideoLoader...reproducing issues can sometimes be such a pain. I've attached my modified version of VideoLoader anyway. If I come across the issue again I will be sure to follow up with the exact code.

The VideoLoader is a great feature of the LoaderMax package, but has a few issues which prevent it from being usable as a video player. Please let me know if you ever get a chance to update the following issues. Thanks in advance! 1. REQUEST: The VideoLoader could use a stopVideo(). If I want to stop a video, so that the next request to playVideo() starts from the beginning, I need to instead call pauseVideo() followed by gotoVidTime(0). 2. BUG: The VIDEO_COMPLETE event triggers prematurely when on the local machine. I encountered this issue when building my own players as well. Essentially, "NetStream.Play.Stop" only means the video has ended if "NetStream.Buffer.Empty" or "NetStream.Buffer.Flush" directly preceded it. If not, the player needs to play out the rest of the buffer before the video is over. My logic looks something like: // Inside NetStream handler switch (event.info.code) { case "NetStream.Play.Stop": //Video End...Ready END Event; if (_lastStatus == "NetStream.Buffer.Empty" || _lastStatus == "NetStream.Buffer.Flush") { dispatchVidEvent(VidEvent.END); }else{ _endAfterBuffer = true; } break; case "NetStream.Buffer.Empty": case "NetStream.Buffer.Flush": if (_endAfterBuffer){ _endAfterBuffer = false; dispatchVidEvent(VidEvent.END); } break; } _lastStatus = event.info.code;