jstarrdewar

OK I'll work up an example but it'll probably be on Monday, since everything's on my work computer.

The following code also avoids the issue without modifying ContentDisplay: var content:ContentDisplay = LoaderMax.getLoader(url).content; var movieClip:MovieClip = content.rawContent as MovieClip; content.rawContent = null; //work with movieClip, then call dispose(true) on the loader But I think it looks a bit convoluted.

It's the latest version. I downloaded it last night right before I posted to make sure that you hadn't already addressed the issue. The trouble seems to be that rawContent is not getting set to null. I tried to manually set it to null by doing this: loader.rawContent = null However I got an error that the rawContent was a read only property. I didn't try setting the ContentDisplay.rawContent to null though, because I wasn't storing a reference to the ContentDisplay object. Here's the whole function with my modification: public function set rawContent(value:*):void { if (_rawContent != null && _rawContent != value) { if (_rawContent.parent && _rawContent.parent == this) { removeChild(_rawContent); } else if (_cropContainer != null && _rawContent.parent == _cropContainer) { _cropContainer.removeChild(_rawContent); removeChild(_cropContainer); _cropContainer = null; } } _rawContent = value as DisplayObject; if (_rawContent == null) { return; } addChildAt(_rawContent as DisplayObject, 0); _update(); }

I'm not sure if I'm misusing the SWFLoader's rawContent or not: The use case is that I am accessing the rawContent as a MovieClip, storing it in an instance variable, and then adding it to the stage. Later on when I'm destroying things for garbage collection, I remove it from the stage. At the same time, I call dispose(true) on all of my SWFLoaders, indiscriminately (I'm not accessing rawContent from all of them in the same way). When I do that, I get a null object reference on line 383 of ContentDisplay. I solved the problem by making the following modification: if (_rawContent.parent && _rawContent.parent == this) I just wanted to know what your opinion of this is. Is calling dispose(true) instead of dispose() useless in this case?

Sorry Jack, Deadlines were looming, so I just had to revert the library and didn't have time to break out the problem code for you (I only upgraded because I wanted to use the addCuePoint function). I was hoping the description would be enough to go off of. Anyway, your latest version (1.741) fixed the issue. Thanks a million for your rapid response, as usual! Oddly, in the release notes it says the problem affects Player 9, but I am building against Player 10 with Flash Builder and Flex 4.0 and testing in Player 10.1, so it could have something to do with my specific videos, but the problem persisted past Player 9.

Hi Jack, I just updated from the 11/04 version to 1.73 (11/18) and I ran into an issue with VideoLoader. I'm not getting a complete event if autoplay is set to false, although the progress event is working fine. Here is my configuration: rootLoader(LoaderMax) appends several groupLoader(LoaderMax) objects which in turn append one or more clipLoader(LoaderMax) objects which append the videoLoader(VideoLoader) objects as well as various other kinds of loaders, if needed (In this case it is failing even if there is only the one videoloader). I call load() on groupLoader. I am listening for LoaderEvent.CHILD_COMPLETE on the groupLoader. This all worked flawlessly in the 11/04 version. Now, when autoplay is true, I get my child complete event, but of course it causes all of the preloaded videos to play at the same time, which is no good. If autoplay is false, which is how I had it, I don't get any child complete event. I tried attaching a complete listener to the videoloader directly, but it didn't seem to work either.

Hi Jack, Sorry it took so long to test it out; it works fine now. I was just running with that line commented out for a while. Thanks for fixing it so quickly. I tested the bonus-all swc. I really think you have a good model going; it's well worth the money to support it, but if there's a show-stopping bug I can still jump in to the code and find a solution, or just revert part of the library back to an earlier version. Plus, I have learned an awful lot of ActionScript from you, thanks to your excellent comment coverage and documentation. I wish more Applications would follow that model, even big ones. There're several bugs in FlashBuilder, for example, that I bet wouldn't be too hard to find; plus it doesn't keep up with Eclipse.

I guess I didn't notice that, because my clips get added to the stage at the same time as I call playVideo. Maybe there could be a little firstplay logic so that VideoLoader doesn't add the Video to the ContentDisplay until the video is supposed to play? Although I suppose that doesn't help those who might want to deal with the Video object directly.

I have confirmed that if I comment out line 438 my problem goes away: _video.attachNetStream(null);

It's the change on line 436. If I just copy and paste the lines from version 1.3 into 1.42, everything works fine. Revert to the original 1.42 and it breaks. I did this 6 times just to make sure. This works: if (_pauseOnBufferFull) { _pauseOnBufferFull = false; this.volume = _volume; gotoVideoTime(0, false); _ns.pause(); } This doesn't work: if (_pauseOnBufferFull) { if (this.metaData == null && getTimer() - _time < 10000) { _video.attachNetStream(null); return; } else { _pauseOnBufferFull = false; this.volume = _volume; gotoVideoTime(0, false); _ns.pause(); _video.attachNetStream(_ns); } } I was thinking that the NetStream wasn't getting reattached to the video, but I see it happening in the videoPaused setter. I also tried adding _video.attachNetStream(_ns) to the playVideo method, but no luck there.

Yes, the older swc is the working one. The swc that's been causing the problems came from the bonus-all folder and is dated 9/6/10 11:55 (I also took the swc out and compiled against the source code from the latest bonus-all folder with the same results -- the Changelog lists the version as 1.42). I'm trying to isolate which of the changes is causing the problem now.

I just went through subversion and reverted the greensock.swc to an older version, which was current as of August 11th. Unfortunately I was using the swc, so I don't think I can figure out exactly which version of LoaderMax it was. However, that fixed the bug. It works perfectly now. I'll see if I can track down the exact version where the problem showed up. I'm almost certain, however, that it appeared in between VideoLoader version 1.3 and version 1.32, which you released on August 12th, because I remember I had used one of the loaderVars objects you added in 1.3. I was in the middle of a complicated refactor, so I thought the bug was in my code and not yours, which should teach me not to go about upgrading libraries in the middle of refactors :-/

I am having a similar issue or the same issue. I am using version 1.42. It happens with a very short video, in both flv and f4v formats. It's 4 seconds, 635 kb. It also happens semi-randomly. Once in a while it will work fine. I am actually loading several clips of this approximate length and size, and on each run, a few will work and a few won't. Which ones work, and which don't changes every run. Longer clips never seem to have the same issue, and I'm not sure what the cutoff is yet. Using the flash debugger, I inspected the VideoLoader instance and found that, although the clip was playing and I could hear the video, and the VideoLoader.content property was properly added to the stage, the VideoLoader._video.videoWidth property == 0, and the videoHeight property also == 0. I happen to have a click handler that fires VideoLoader.gotoVideoTime(0), and when I click it, the next time the video plays, I see it and videoWidth == 848/videoHeight == 480, as it should. If I programmatically call VideoLoader.gotoVideoTime(0) without the click handler, it still isn't visible, and it still reports videoWidth/videoHeight == 0. I tried setting the size of the video explicity with the width/height parameters of VideoLoaderVars. I also tried modifying VideoLoader so that it instantiates the Video Object like so: _video = _content = new Video(848, 480). That made no difference. I put a trace in at line 543 in the _metaDataHandler and traces the width and height. They trace 848 x 480 long before I ever attempt to play the video in the first place (I have autoPlay set to false). I can't post the videos on the public forum, but I PM'd links to them to you directly. Tomorrow, I'm planning to break down a few test cases to see if I can isolate the problem further. A few other things I tried were manipulating the Video object and netstream directly, by adding the Video to the stage and using netstream.seek(). Neither had any effect, except that my click handler no longer caused the video to revert to its proper size and display if I didn't have VideoLoader.gotoVideoTime(0) in there and used netstream.seek(0) instead.