JavaScript/Flash timing causing player to load without controls (mainly IE 8) Created Aug 13, 2009

Thanks for this thread and your work on this. I am having this same issue in ie 7 and ie8 and in your two examples I am able to replicate.

Thanks for reporting this. I will investigate and try to fix it ASAP.

Anssi

For me the player works fine on both of those pages, meaning that I cannot reproduce the bug using the steps you listed.

Will have to find another Windows computer where to test this.

Anssi

Hello Anssi, has there been any progress with this? Are you actively looking into this? I need to know because I really can't go live with this player if it doesn't work sometimes for IE 7 and 8.

As noted by sixfoot it seems to be the case that it has been this way since the release of 3.1.1. I notice onhttp://www.islamweb.net that it works fine (3.1.0).

Thank you Anssi in advance for your time.

Have not been looking into this in the past 3 days. It's hard because i don't have a machine where to reproduce this. And also it looks like a bug in IE or in the Flash plugin for IE 8.

Anssi

The best way to reproduce is to have a really fast connection (maybe local to machine if necessary) and a really fast computer.

Me either. Did 7 attempts on the first-frame.html - demo. Could not reproduce the bug. I have IE8 with Flash 10 (debug version)

I think we can all agree that clearly there is a problem especially looking at this forum and here:http://flowplayer.org/forum/8/21736.

What is your connection speed? I am on a T1 connection. Have you tried on a faster connection as suggested by sixfoot?
Did you try IE7? For me IE8 doesn't happen every time, however on ie7 and ie6 it does every time.

With your 7 attempts did you close the browser each time and then re-open it?

Thanks Tero.

I can confirm this issue exists for me.
I have a quad core windows 7 machine but we've got reports from multiple users of this issue.

I have flash version 10,0,22,87 installed I could patch but not everyone will.

I've got a work around buy checking if the player is loaded, attempting to load it if it isn't and checking again later.

   function playerload() {
    if (!player.isLoaded()) {
        player.load();
    }
    else {
        //try again in a second
        setTimeout('playerload()', 1000);
    }

Basically I'm just poking it every second until it loads. Works but causes a 1 second delay on starting the video on IE8

Thanks for the workaround. Are you putting that in the clip or completely outside all the player set up and callign it initially with just a single line playerload() call?

Looking good.

Here's my recommendation for Anssi even if he can't duplicate:

1. Wait for Stage.Width and .Height to be > 0. (Don't do a tight loop in code; check every 5-6 ms.) The alternative is to set up a listener for the stage resize event first thing, and then go from this event.

2. Insert a delay of at least 35-50ms. I'd go for the longest delay tolerable. 50ms is just 1/20th of a second, and hardly noticeable to people.

3. Then, run the remainder of the setup code for Flowplayer.

#1 comes from a verifyable glitch in Flash. Flash will refire its Stage dimensions until both are not zero. If you log or trace this to text on the Flowplayer canvas you can see that often (with JavaScript object loading) you'll get at least one misfire, then the correct staging dimensions. At this point, apparently, Flash has set up things internally, and you can proceed.

FWIW, you can't trace this unless you run the code in the browser and use dynamic JavaScript. I'd not use a debugger of any kind, in case that influences things. Just a simple string displayed in a dynamic text box.

I'm not sure it ever happens with a Mac, but the way I find it is to run locally. For others testing this out, this means setting up a security folder for Flowplayer so you can run it from your own machine.

It would be interesting to tell if the same happens with SWFObject. Anyone willing to try it out?

Thanks gmccomb, i'll try your approach.

Anssi

I've now added a wait timer that waits until stage.width and stage.height are both > 0. I did not add the 2nd delay yet - i'd rather go without it if we can avoid it.

The latest dev version is now in this page:http://flowplayer.org/demos/plugins/streaming/first-frame.html

If this did not solve the issue, could you please post the player log output here. I cannot reproduce this here so the output i get does not help. The log goes to the Firebug console (and to Safari and Chrome consoles).

That seems to have fixed for me!

Doh! And now that pagehttp://flowplayer.org/demos/plugins/streaming/first-frame.html is broken again.

Same bug appears again?

Yes but slightly different this time. Now a refresh does not always fix it, and sometimes it works the first time I load it in the browsing instance. Same as far as no controls, but slightly worse because it is less predictable.

Bummer.

Oddly enough, I wasn't seeing the timing error at all before, and now with the first-frame demo I see issues five times out of 10. Something else must have surfaced up with the changes made to the dev code.

Like I said in the other thread, this is an insidious bug. Even YouTube gets stung by it. On reload of some videos I was watching caused their player to stall out (endless buffer wheel, thumb not moving, and so on). The stream was otherwise fine, but the player somehow skipped an initialization step on reload.

I've implemented the 2nd wait. Is it any better now?

Anssi

Yes, appears better. I am on a slower connection today, but it does appear to be working.

Works fine, I'm unable to reproduce the bug with the new demo (tested on MSIE6 native and MSIE8 with 10.0.32.18 )

BTW, MSIE8 also has the console that works with Flowplayer debug output.
The console output is

[LOG] time 16:47:29.229 :: org.flowplayer.view::Preloader : Preloader added to stage, stage size 0 x 0
[LOG] time 16:47:29.260 :: org.flowplayer.view::Preloader : 14
....
[LOG] time 16:47:30.26 :: org.flowplayer.view::Preloader : 98
[LOG] time 16:47:30.88 :: org.flowplayer.view::Preloader : init
[LOG] time 16:47:30.229 :: org.flowplayer.view::Preloader : Launcher instantiated
[LOG] time 16:47:30.229 :: org.flowplayer.view::Preloader : stage size 500 x 375
[LOG] time 16:47:30.229 :: org.flowplayer.view::Preloader : init

It looks like it works for me as well. Great!

What version of flowplayer will this fix be release in? 3.1.3?

This will be in 3.1.3. The current development version which also has this fix is available here

Anssi

As I noted to gmccomb below, this does not fix the issue. IE works fine now and Firefox does not. I think this is a great player, however I am looking really stupid at my company cause the player is not working. Please please please fix this.

I hope I don't sound to jerky, but this is has been an issue for quite sometime and is NOT getting fixed.

Here is a test... Open it up in FF. It showed up 2 out of 10 times.

http://www.sonoranbloom.com/test/flowplayervid.aspx

Thanks.

>I have flash version 10,0,22,87 installed

Just as a BTW, this (and all previous versions of 10 and 9) are exploitable. Be sure to update.

can you show us how you have it setup?

On the new-new fix of 8/28, now I'm getting a blank player 70-80% of the time. This is with Firefox 3.0.x, and on IE the player initializes properly each time. That's opposite what usually happens, so I wonder if whatever is happening on the single-frame page is the result of this timing bug. Might be something else.

FWIW, I never do get an initial splash image showing. When the player comes up the player is always empty. From the description of the page looks like an initial image 64ms into the stream is supposed to be shown.

Ok, gmccomb, the same thing is happening to me. IE is working and now Firefox is not. We are needing to push this player out and it is not working.

Can we get this fixed????????????

Ack!

I tried your new sample and same thing for me: Flawless (as far as I could tell in the 15-20 load tries) on IE, a good 30-40% failure rate on Firefox. So, in fixing one thing, looks like something else got broken.

I'm using FF 3.0.12 on XP, Flash 10r32.

I'm not involved in Flowplayer development, but I do know from working on a much simpler player of my own that this timing bug just about made me want to give up and go back to Windows Media. When you start messing with timing in Flash things seem to go haywire. It's a fine balancing act, as we've seen.

Not to get you over to the competition or anything, but are you able to run your same stream with JW Player? Are we sure this is a player issue, and not a streaming issue?

Hi gmccomb, thanks for your response.

I just tried JW Player via the wizard with this info:

Streamer set to:
rtmp://174.129.251.255/vods3

File set to:
flv:amazons3/trivita.video/top25GOS768.flv

It worked flawlessly.
So through good and necessary consequences, it seems as if Flow Player is the issue.

Thanks.

=rw=

Well that answers that.

Has it been determined this issue is mostly/entirely limited to rtmp, or is it shown to also affect http progressive and/or pseudo-streeam?

It turned out that there were difficulties loading the plugins with Firefox. The problem occurs for me only on Windows (not on my Mac) and when navigating to the page from some other page. Was using this page in testing:http://flowplayer.org/demos/plugins/streaming/first-frame.html

I've fixed this now so that it does not load the plugins in parallel but in sequence so that the next plugin download starts only when the previous one is finished. This seems to fix the issue.

Let me know how it works now. Again the latest version is here.

Anssi

Seems to work! 5 for 5 on both browsers for me. Thanks!

Works on all versions of IE6, IE7, IE8, Chrome (2.0.172.43).

I am not able to get it working that great in FF. In fact I was getting this result every time I refreshed. If I hit back then forward on the browser it would then load fine.

Page for reference:http://www.sonoranbloom.com/test/flowplayervid.aspx

To make sure I wasn't crazy or missed something I made a new file and changed the player swf back to 3.1.2 and the rtmp swf back to 3.1.1 and firefox(ffv 3.0.13) works fine.

Page for Reference:
http://www.sonoranbloom.com/test/flowplayervid3.aspx

I'm getting identical behavior on both of the sonoranbloom sample pages. Initially the buffer spinner may appear upper-left (looks like a stage sizing issue on initialization), then the player loads.

I am:

* Unable to reproduce the bug on either sonoranbloom example page;

* Unable to reproduce the bug in the first-frame.html example.

I'm testing on IE7 and FF 3.0.12 on XP, and FF 3.5.2 on Vista.

This final issue is now fixed and out with our current 3.1.3 release.

Anssi

Actually, I just downloaded 3.1.3 and noticed the same error a few others were getting with the loading graphic being in the top left and the controls not showing up. Even after several refreshes, it was not fixed. This seemed to happen on the load of a second video on my site (different pages) during the same browser instance.

Haven't followed the thread for some time, but tried the freshly released version.

The bug-induced visual effect has changed, but the bug itself is still here. I'm reproducing the bug as such:

1) Clear the browser cache.

2) Run any demo with configured plug-ins, for example http://flowplayer.org/plugins/streaming/bwcheck.html

The org.flowplayer.view.Preloader debug log entry is (I'm listing the log from my own sample page):

[LOG] time 19:32:58.869 :: org.flowplayer.view::Preloader : Launcher instantiated [object Launcher]

3) Reload the demo page. All page components, including the swfs must not be rechecked from the remote server. This is important note.
4) Run the demo again. The "loading circle" sign will be at the upperleft corner and will last forever.

!!!!!
Note that the org.flowplayer.view.Preloader debug log is empty.
org.flowplayer.view.Launcher is empty too, because the Launcher is not instantiated by the Preloader.
!!!!!

5) Clear the browser cache again (no need to close the browser).

6) Run the same demo again, it will work fine. Then you may go to the step 4 and with the same negative effect.

Personally, I found the "cure" that prevents appearance of this bug in every situation I can try. My solution is to append '?rnd='+Math.random() to each plugin reference
within Flowplayer's configuration thus making all urls unique and preventing the cache use.

Also, I still personally think that the root cause of the issue is Flash event handling specifics (see previous' thread posts). By introducing delays one just tries to implement some timeouts for some kind of internal activities instead of actually listening to events.

Look here:
http://www.actionscript.org/forums/showthread.php3?t=136345

At least for the latest build the buffer spinner and no video/controls might be specifically related to Protected Mode in Win7/8 under Vista and Win7.

If you have this setup, try temporarily turning off protected mode, then restart IE.

>Also, I still personally think that the root
>cause of the issue is Flash event handling
>specifics

I think the point of the thread (and the guy's solution) is that the events are not occurring under some circumstances. That's why he overloads Init to also serve as complete, and doesn't remove the listener until he's sure his app has been fully loaded.

Secondarily, the staging setup error most commonly associated with this glitch is that Flash may fail to set Stage height/width on load. Flash itself will refire the Stage resize event until the values are non-zero, but many Flash apps are written in a way where things get set up the first time the event is fired.

This topic is discussed in several threads on the SWFObject board, as 99% of the time it only comes into play when Flash is used with dynamic publishing, which is the case with Flowplayer when using flowplayer.js.

>At least for the latest build
>the buffer spinner and no
>video/controls might be
>specifically related to
>Protected Mode in Win7/8
>under Vista and Win7.

My setup is not so fashionable. I tested with MSIE6 on Win2000 Advanced Server and with MSIE8 on WinXP-SP3.

>Secondarily, the staging setup
>error most commonly associated
>with this glitch is that Flash
>may fail to set Stage height/width
>on load.

I mentioned this 3 weeks ago at http://www.flowplayer.org/forum/8/21736#post-24757
The url I referenced was
http://stackoverflow.com/questions/547408/rectangle-doesnt-get-drawn-on-root-object-on-refresh-in-ie

All of these are stabs at the dark, really, and point up different aspects of what is probably the same bug (or set of bugs) internal to Flash. That means some solutions will work while others won't depending on the manifestation of the bug, and how specifically the Flash app is written.

For example, this statement is flat-out wrong (or at best incomplete):

"On refresh, stage.{SIZES} are set to 0 in IE."

The bug affects more than IE. It can happen on first load. It's just that it appears to happen more in IE, and the chances of hitting it are higher when you keep clicking the Reload button. I've seen it in FF, Chrome, Safari, and probably Opera, first load, 7th, 12th, you name it.

Caching may be in issue in some circumstances, but since I've seen it (in FP and other players) on first load events after cache is cleared it can't be solely a cache problem.

It seldom (if ever?) happens if you don't use JavaScript to load your SWF. Someone on SWFObject forum said they've encountered it with standard OBJECT embedding, but in six months of testing all kinds of FLV players I've never seen it outside of JavaScript loading.

>For example, this statement
>is flat-out wrong (or at best
>incomplete):
>"On refresh, stage.{SIZES} are
>set to 0 in IE."

Of course, if you take this statement out of context of the whole message, it is "at best incomplete". Otherwise, the whole discussion is proposing the variation of what you are writing here at http://www.flowplayer.org/forum/8/24973#post-25458

>1. Wait for Stage.Width and
>.Height to be > 0. (Don't do a
>tight loop in code; check every
>5-6 ms.) The alternative is to
>set up a listener for the stage
>resize event first thing, and
>then go from this event.

However, I think that the further discussion about "flat-out wrong" statements somethere is offtopic here.

> It can happen on first load.

What is the definition of "first load"? Primed browser cache? Empty browser cache? Primed intermediate proxy cache? What page components are in the cache? Any transparent HTTP accelerators? Antivirus? Personal firewall? Do you know that the traffic may flow through caching proxy server which is invisible to clients?

Personally, I've found the original issue on Firefox, then successfully reproduced it on MSIE. Moreover, I saw similar preloader-related issues in every possible browser in non FLV-player context of flash programming (with SWFObject). I never saw it on true first load. It is my personal experience, however.

Absolutely positively seen it on first load. I spent days investigating this for a couple of other players, including my own.

I've run tests at FedEx/Kinkos of content in private areas of my Web site. No way the content would be cached on their system. Once or twice first access of a given test (I had several dozen, all using different content and metrics) I encountered the timing bug.

I say the comment is flat-out wrong because he's making a broad statement that I know doesn't hold up scrutiny, and by itself isn't correct. In my tests I've been able to get IE from version 6 to display correct Stage dimensions on reload. Much of it depends on connection speed.

Saying that IE always behaves this way or that gives one the impression the issue is easy to work around. In fact IE DOESN'T always behave this way, and never (in my experience) behaves this way with straight OBJECT embedding. These variations make tracking down the problem hard to deduce.

I'm sure some of this behavior is due to caching. I'm sure some of this behavior is due to some interaction between ActionScript in Flash and JavaScript on the page. I'm sure some of it is due to programming styles and coding practice, number and sophistication of other SWFs that must be loaded (compounding timing issues), and so on.

I think it's an interesting point you raise about avoiding the issue by randomizing filename calls, but obviously this can't be a long term solution. Same as there will always be someone's machine that'll be so slow (or whatever) that any reasonable delay in initializing following loading will still not work. We all know Flash publishing isn't 100% foolproof.

Anyway, I think Anssi has enough of the new issues in 3.1.3 to reexamine the changes, especially in light of the new findings regarding consistent error when using IE7/8 in Protected Mode.

I found that flowplayer-3.1.3.min.js doesn't add random number to the url of the SWF while embedding. The older flowplayer-3.1.2.min.js does so embedding player's main SWF like this: http://<somehost>/util/fp/flowplayer.comm-3.1.2.swf?0.38339078127716

The newest version of the jQuery Tool's flashembed (which is the base of the flowplayer.js) has new configuration parameter - cachebusting.

http://flowplayer.org/tools/flashembed.html

Previously, this setting was not configurable and it was always enabled.

http://flowplayer.org/forum/20/21090

In newest version of the flashembed (flowplayer.js) this setting is configurable, but it is disabled by default. It looks like all abovementioned development and testing was made with older flashembed and it worked then. It works again with either:

• specifying cachebusting: true like this:

  
  flowplayer("player", {
  	src: "/swf/flowplayer-3.1.3.swf",
  cachebusting: true,
  	version: [9, 115],
  }, {
  	clip: "http://blip.tv/file/get/KimAronson-TwentySeconds6421.m4v"
  });
  

  
  
• switching back to flowplayer-3.1.2.js (using 3.1.2 javascript with 3.1.3 swf).

This solution doesn't solve the core of the problem (event handling while preloading cached objects, in my opinion), but it prevents the bug from appearing.

Wonderful! That'll help in the short term.

Do remember, though, that cached content is just like local content or content served from a very fast connection. One of the observations made in this and the previous thread is the bug appears more often if you have a fast connection.

Moving forward, as we test our stuff it would be a good idea to do so locally (as a stress test), using either a localhost server or local Flash security zone.

Even with the 3.1.2 or 3.1.4 js, I can still recreate this or maybe its a similar problem on my own site by putting IE8's Developer tools into "Always Refresh From Server" mode. I'd say the player loads correctly less than half the time. Usually without controls and/or without the background image.

I have a really hard time recreating these issues on the demo pages because most of them do not auto load the player but use a splash image place holder instead.

The problem seems to remain. It has slightly different symptoms depending on browser/version and method of embedding. All exhibit it though, incl,uding stating embedding using an OBJECT tag.

Want to second that. We tried using OBJECT tag embedding, and the problem still occurs.

An easy way to reproduce it is to set the problem page as your home page, and keep opening new tabs repeatedly until you see it without controls loaded.

We've been running into the same issue with IE mostly. We have the player configured to autoplay - we're actually psuedostreaming however.

The controls don't render - if you refresh the page or set a clip via the API it plays fine.

After installing the debug version of flash the issue seemed to be less prevalent. Obviously this isn't a solution for our clients.

It's hard to repro consistently when you want it to and seems to be machine related which would add weight to the timing arguments.

Is it just me or are there a lot of glitches with Internet Explorer 8? Seems like everywhere I go on the web, people are having problems viewing websites with IE 8

Hi I have the latest version and flowplayer will not display for me in IE 7 or 8 on three different computers. THe "Refresh" option doesn't work for me. Try this link in Firefox and IE. Works in FF. However, if I try to add any autoPlay or autoBuffering code it does not show up in either browser.

Thanks

What (unfortunately) does work avoids flowplayer all together. That is the following code taken from this link:
<OBJECT ID="MediaPlayer" width=320 height=310 classid="CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95" codebase=http://activex.microsoft.com/activex/controls/ mplayer/en/nsmp2inf.cab#Version=5,1,52,701" standby= "Loading Media Player" type="application/x-oleobject">
<PARAM NAME="FileName" VALUE="video/ceramica.avi">
<PARAM NAME="AutoStart" Value="True">
<PARAM NAME="ShowControls" VALUE="True">
<PARAM NAME="ShowStatusBar" VALUE="True">
<EMBED type="application/x-mplayer2" pluginspage=http://www.microsoft.com/Windows/MediaPlayer/" SRC="video/ceramica.avi" width=320 height=310 name="MediaPlayer" autostart="True" ShowStatusBar=1 ShowControls=1 >
</EMBED>
</OBJECT>

What I read is that IE requires the Object tag and Firefox requires the Embed tag. I don't know if this is true or not, but modifying the above to my file displayed the file in both IE and Firefox.

I don't know how to modify that for flowplayer.

The problem where the player does not initialize correctly is still present in 3.1.5 under Firefox for the Mac.

The problem is that stage.stageWidth and stage.stageHeight are zero in many cases. The timer fix that Anssi mentioned in 3.1.3 (above) still doesn't fix the issue, and when we've traced it, we discovered that the timer was simply hung in a loop waiting for the stage size to change, and it never did. This was easily reproducable at one of the sites which virally embeds our playerhttp://iste-eduverse.org, so it was easy for me to add special tracing to the player and debug this.

This problem is pretty well documented.

There is an Adobe JIRA bug report for it:http://bugs.adobe.com/jira/browse/FP-434

And this is a good discussion by people experiencing the problem:http://www.stevensacks.net/2009/01/20/firefox-3-mac-flash-bug-stagewidth-and-stageheight-are-0/

Suggested fixes have been:

• Add a timer and wait until the stage is set. (Does not appear to work reliably).
• Setting stage.scaleMode to force a resize, then waiting for the resize event. (Tried this extensively, did not work reliably).
• Using Event.ENTER_FRAME and waiting for the stage size to be set before proceeding (seemed to work best for us).

Here is what we did to the code:

• Removed the timer code completely along with Event.COMPLETE triggering of init(), plus other multiple init() references. This may not have been necessary but it eliminated many of the uncertainties about timing issues by removing multiple entry points to init() and helped us focus on one solution.
• onAddedToStage sets up an event listener for Event.ENTER_FRAME.
• When onEnterFrame has a non-zero stage size, it calls init() (this is the only place init is called in our code.)

This seems to work reliably in Firefox for the Mac, Safari for Mac, IE8 and IE7.

There are still some issues. On Firefox for the Mac, players "below the fold" do not actually initialize until you scroll down to view them. This is a bit odd and I wish I knew how to do this intentionally because I like the idea of knowing when a player has been viewed vs. simply being rendered. But, it appears that only Firefox on the Mac exhibits this behavior. Safari does not and Windows browsers do not. It does work very reliably however, despite the "late rendering".

The "preloading rotation animation" does not work well at all. This is because the stageHeight and stageWidth definitely are not available until later in the loading phase. I believe that there is no way to reliably get these numbers at the point they are needed. So, one possible option (we did not bother with) is to see if the height and width of the application container could be derived some other way, such as using loaderInfo. Fortunately, the animation does not appear at all in most cases, and when it does it appears as a white object on a white background in our case.

The whole Preloader.as file looks like it could use some real testing and scrutiny, as the entire AS3/Flex community appears a bit befuddled about the exact behavior of objects during the preload phase and there is no definitive information from Adobe.

I am not posting any source code here because of licensing issues, but I have it available in our svn.

Thanks for the information. Do you know if your fix also solves this "wmode horror issue":http://flowplayer.org/forum/8/27052 ?

Anssi

Same problem here.

According to the log files, there happens something strange:

it generates about 25 % - 80 % 404 errors, when our site is loaded (black area instead of player), if we reload the page,
it does work.

We use a "fast" connection (10 MBit/s).

We use a CDN and currently I'm waiting to receive the raw log files to investigate this further.

It really looks like a serious bug, because JW Player does work without any problems.

I just tried our test build with wmode="transparent" and it appears to work fine. However, I wouldn't say that I have tested this very thoroughly, only under Firefox for Mac and Safari for Mac. Both appear fine however.

If you email me at "garyw at treet.tv" I will be happy to email you our version of Preloader.as. You can take a look at it and see if it helps with progress.

based on garywiz description i changed preload.as to following version.
this version works fine in FF/IE under Windows and Linux.

/*
 *    Copyright (c) 2008, 2009 Flowplayer Oy
 *
 *    This file is part of Flowplayer.
 *
 *    Flowplayer is free software: you can redistribute it and/or modify
 *    it under the terms of the GNU General Public License as published by
 *    the Free Software Foundation, either version 3 of the License, or
 *    (at your option) any later version.
 *
 *    Flowplayer is distributed in the hope that it will be useful,
 *    but WITHOUT ANY WARRANTY; without even the implied warranty of
 *    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *    GNU General Public License for more details.
 *
 *    You should have received a copy of the GNU General Public License
 *    along with Flowplayer.  If not, see <http://www.gnu.org/licenses/>.
 */
package org.flowplayer.view {
    import flash.display.DisplayObject;
    import flash.display.MovieClip;
    import flash.display.StageAlign;
    import flash.display.StageScaleMode;
    import flash.events.Event;
    import flash.events.ProgressEvent;
    import flash.events.TimerEvent;
    import flash.utils.Timer;
    import flash.utils.getDefinitionByName;

    import org.flowplayer.util.Arrange;
    import org.flowplayer.util.Log;
    import org.flowplayer.util.LogConfiguration;

    public class Preloader extends MovieClip {
        private var _log:Log = new Log(this);
        private var _app:DisplayObject;
        private var _initTimer:Timer;
        private var _stageTimer:Timer;
        private var _rotation:RotatingAnimation;
        // this variable can be set from external SWF files, if it's set well use it to construct the config
        public var injectedConfig:String;
        private var _ready:Boolean = false;

        public function Preloader() {

            var logConfig:LogConfiguration = new LogConfiguration();
            logConfig.level = "error";
            logConfig.filter = "org.flowplayer.view.Preloader";
            Log.configure(logConfig);
            _log.debug("Preloader") ;

            stop();
            stage.scaleMode = StageScaleMode.NO_SCALE;
            addEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
            stage.addEventListener(Event.RESIZE, onResize);
        }

        private function onAddedToStage(event:Event):void {
            removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage);
            addEventListener(Event.ENTER_FRAME, onEnterFrame);
        }

        private function onEnterFrame(event:Event):void {
            if (stage.stageWidth > 0) {
                removeEventListener(Event.ENTER_FRAME, onEnterFrame);
                stage.removeEventListener(Event.RESIZE, onResize);
                init();
            }
        }

        private function onResize(e:Event):void {
            stage.removeEventListener(Event.RESIZE, onResize);
            removeEventListener(Event.ENTER_FRAME, onEnterFrame);
            init();
        }

        private function init(event:Event = null):void {
            log("init()");

            nextFrame();

            log("stage has size " + stage.stageWidth + " x " + stage.stageHeight);

            if (_app) {
                log("init(), _app already instantiated returning");
                return;
            }
            if (_rotation) {
                _rotation.stop();
                if (_rotation.parent) {
                    removeChild(_rotation);
                }
            }
            prepareStage();

            try {
                var mainClass:Class = getAppClass();
                _app = new mainClass() as DisplayObject;
                addChild(_app as DisplayObject);
                log("Launcher instantiated " + _app);
            } catch (e:Error) {
                log("error instantiating Launcher " + e + ": " + e.message);
                _app = null;
                if (! _initTimer) {
                    log("starting init timer");
                    prevFrame();
                    _initTimer = new Timer(300);
                    _initTimer.addEventListener(TimerEvent.TIMER, function(e:TimerEvent):void { init(); });
                }
                _initTimer.start();
            }
        }

        private function getAppClass():Class {
            try {
                return Class(getDefinitionByName("org.flowplayer.view.Launcher"));
            } catch (e:Error) {
            }
            return null;
        }

		private function prepareStage():void {
            if (! stage) return;
            stage.align = StageAlign.TOP_LEFT;
            stage.scaleMode = StageScaleMode.NO_SCALE;
        }

        private function log(msg:Object):void {
            _log.debug(msg + "");
            trace(msg + "");
        }

        private function stageHasSize():Boolean {
            return stage.stageWidth > 0 && stage.stageHeight > 0
        }

        private function get rotationEnabled():Boolean {
            var config:Object = stage.loaderInfo.parameters["config"];
            if (! config) return true;
            if (config.replace(/s/g, "").indexOf("buffering:null") > 0) return false;
            return true;
        }
    }
}

My only comment would be why init() is called both in onResize() and in onEnterFrame()? Did you determine that there are circumstances where onResize was called first and the onEnterFrame was no longer needed? In my experience, onEnterFrame was sufficient, but that doesn't mean that your testing environment yielded different results, as the Flex preloader logic is a bit hard to predict.

The preloader has been now rewritten to rely on the ENTER_FRAME event. You can see the code here. The rotation animation has been disabled for now as you can see in the commented code.

Here is a page that uses this version.

Please let us know how this works! You need to take the 3.1.6-dev player and the controls plugin and also all other plugins that you use from this page.

The problem seems to be much reduced. I never get ablak screen. However:

The loading animation is still there (I double checked that the new 3.1.6-dev version is loaded). On Netscape I occasionally only get the loading cirle and no movie. Rarely though.

On IE I sometimes get the video with the wrong size vertically (it has the same size as the controls and not the video size). Vertical placement of the compressed video playback seems random, but usually in the upper part of the window. 3 times out of 4 the video plays back as it should.

Sorry, IE seems works fine with a proper window.onload event triggering the flowplayer JS. Copy/paste error on my test page.

Netscape still occasionally does not get past the loading screen with the circle animation.

The slower the machine the likelier it seems to stick on the circle-animation. I got close to 100% failure on an older machine running Firefox with 3.1.6-dev.

Are you sure the 3.1.6-dev binary is the correct one? It certainly still includes the circle animation.

Could someone summarize that long (yet very useful) thread?

Why not realying on loaderInfo's Event.COMPLETE?
Isn't it the same as in (l.71) "loaderInfo.bytesLoaded == loaderInfo.bytesTotal"?

Is it very reliable to "cascade event listeners"?(i.e. Event.ADDED_TO_STAGE calls a method that registers a listener for Event.ENTER_FRAME). Why not just registering that listener at the constructor level? But then why "stop()" in the constructor (l.47)?

With my (simple) tests the events triggered seem to be in the following order. I expect things to be a little different maybe but for example I don't think ENTER_FRAME could never be triggered before ADDED or ADDED_TO_STAGE (any situation this is not true?).

• ADDED: called a couple times and usually "stage" may not be defined.
• ADDED_TO_STAGE: called once and stage is defined (all the time?)
• loaderInfo's INIT: called once
• loaderInfo's COMPLETE: called once
• ENTER_FRAME: called multiple times if not "stop()"-ped. However, calling stop() before the movieclip enters that state is useless I found out.

I tested when using a SWF directly and when loading it inside another SWF.
Does anyone have a different lifecycle?
Does anyone have any references to an event/state lifecycle in such situations?

luc, the issue that is affecting the workability of various approaches is not the event lifecycle. The event lifecycle itself is relatively predictable. The unknown has to do with working around the Flash bugs by understanding exactly under which circumstances the stage height and width will be reliably set on various platforms, browsers and circumstances, then choosing the right event model to accomodate the bugs in the player. (They may not be bugs, really, but simply complex undocumented interactions during initial rendering.)

From my experience, ENTER_FRAME is the only place where the stage information appears to be truly reliable, and the code should be simplified to eliminate extraneous events and keep the preloader code as streamlined as possible.

That's kinda where I was getting to, meaning time-based solutions are not reliable, vs. say event based ones.
I understand the complexity as I'm running into the same problem with a Google In-Video Ads Flowplayer plugin (where the stage/root are null for example).

Thanks garywiz!

>From my experience, ENTER_FRAME is the only place
>where the stage information

Have you found this is the case even if you don't force a resize on load?

I think the sticking point here is that - at least in my experience - stage dimensions may never be set correctly if you don't toggle a resize at least once. Exactly when do you do that, so that the dimensions are correct when enter_frame is called.

(Also, I have noticed that when the enter_frame event is called in fact the stage can be incorrect the first several loops.)

There aren't a lot of initialization events in Flash, such as "Okay, I'm ready, now you can load your video and everything else." From what I can see of the init events in Flowplayer those are generated at certain loading steps, and are not related to Flash events. Except for enter_frame and added_to_stage, which others are supplied by Flash itself?

We had a similar problem, but since a Flash Player Update (10,0,42,34) the problem is gone.

Maybe you should try to force a Flash Player update and test it again?

Is this working for everyone now, as I still get these problems in IE6 using the latest Flowplayer files.

No, it's still broken. Details on my setup here.

I am still running into this issue with IE (any version) where about 60% of the time the custom controls don't load in time and instead of the custom skinned controls I get white ones. I was wondering if anyone has fixed this other then recompiling Flowplayer with custom code? Thanks.

Here is a link to my version which you can test in IE. It works fine in other browsers.
http://www.ixikos.com/flowplayer

Not sure whether this nitpick changes anything, otoh IE is known to be nitpicky as well. You have:

controls: {
  scrubber: 'false',
  url:"buttons_periscopic.swf"
},

Unquote false as it is a JavaScript keyword.

Hey thanks for going over my html with a fine-tooth comb and catching that. Changed that and still no good. It works about 95% of the time on IE8 on my home comp yet on my laptop with IE6 I amm lucky if it works more then 30% of the time.

If anyone could point me to a forum topic where this was either solved or if there is a workaround I would greatly appreciate it. Thanks.

The example on that page doesn't work for me. The player loads but the video doesn't. It says "300: Player initialization failed: ReferenceError: Error #1065"

* Flowplayer 3.1.5
* Firefox 3.5.8 64-bit (also tested with 3.6.3 32-bit)
* Flash 10.0 r45
* 64-bit Ubuntu Karmic 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux