Flash Preloading Errors? Turn Off gzip.

While finishing up a project a couple months ago, I ran into a problem trying to preload a SWF. Everything worked fine in my development environment. I was throttling my bandwidth using Charles to test things, and the preloader was working as expected. But when I posted it to staging my Flash preloader was broken. My loading bar was animating backwards and my percentage was coming back as infinity.

So what gives? Well, the staging environment was serving SWFs with gzip compression and this was messing up the bytesLoaded and bytesTotal properties that my preloader SWF was trying to read from the main SWF. Different browsers reacted differently too. Some saw bytesTotal as 0 (IE), which is what gave me the infinity percentage (dividing bytesLoaded / 0 will give you Infinity), while others reported bytesTotal as the same as bytesLoaded (Firefox). Hard coding a fake bytesTotal was my temporary fix.

To check to see how your server is sending your files, you can use Charles to inspect your web traffic. Here’s the one that was breaking because of gzip compression:

A SWF served with gzip compression will cause preloading errors.

A SWF served with gzip compression will cause preloading errors.

And here’s what it should look like:

A SWF correctly served without gzip compression.

A SWF correctly served without gzip compression.

I originally thought the issue was with the SWF being served with the wrong MIME type of “text/plain” but changing that didn’t fix my problems. The moral of the story is to check these server settings before wasting a Saturday (Gasp? Working on a weekend?) trying different versions of a Flash preloader and waiting for staging to build the site after each try.

This entry was posted in Flash. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

12 Comments

  1. Natan
    Posted May 28, 2009 at 2:35 pm | Permalink

    Hi Thanks very much for this info
    I wasted alot of time trying to find out what was the problem with my code
    Did you find anyway to bypass this problem without using external swf?

    Thanks
    Natan

    • Posted May 29, 2009 at 7:09 am | Permalink

      I’m glad I could help, Natan. And thanks for being my first commenter.

      I used two SWFs in this project because I used SWFAddress for deep linking in Flash. To achieve this, SWFAddress adds a # to the URL which will mess up your preloading if a user goes directly to a deep link. This is discussed in the SWFAddress forum (search for c.swf). Basically, the # forces SWFs in the page to fully load before displaying and adding a intermediary SWF is the fix.

      That said, I don’t think the second SWF is necessary. Your main SWF should be able to display its own preloader if it’s set up correctly.

  2. Tabitha
    Posted July 16, 2009 at 7:49 am | Permalink

    Thank you thank you thank you! I was having this exact problem on a client site and finally stumbled upon your blog. I used the program you mentioned (Charles), and sure enough…gzip compression! As soon as that was turned off, everything worked fine. You have saved me.

  3. Posted July 21, 2009 at 3:10 pm | Permalink

    Thanks! I had a few people get this nagging issue as well. I had noticed it was returning fouled up file sizes, but how the heck you found it was encoding it differently is wonderful…

    • Posted July 22, 2009 at 7:14 am | Permalink

      No problem, Josh.

      Back in the day when they released the FLV file format, I had to configure IIS to serve these new videos with the video/x-flv MIME type. That’s why I used Charles to see what was up. And that showed the wrong MIME type along with the other discrepancy of the gzip in the Response Compression.

      It seems like some people turn gzip on for everything thinking it will save bandwidth. But compiled SWF files are already about as compressed as they are going to get (the same goes for some image and video files I think). So you’re just wasting processing power/time to compress these files.

  4. flash begginer
    Posted August 2, 2009 at 5:54 pm | Permalink

    hello,

    I don’t speak English very well, sorry.

    I have this problem but not sure how to turn off gzip.

    can you help me?

    I’m a begginer.

    thank you

    • Posted August 3, 2009 at 12:39 pm | Permalink

      Unfortunately, I’m not an Apache expert. I just asked the client to have their server admins fix it.

      Try some searches for mod_deflate and mod_gzip. I think the gist of it is that when you configure one of these compression modules, you can add file types to an exclusion list, or you can specifically tell it what types to include in its compression.

      The exclusion list will look something like this:

      1
      2
      SetEnvIfNoCase Request_URI \
      \.(?:gif|jpe?g|png|swf|flv)$ no-gzip dont-vary

      If you can’t change it server wide, you can do it in a specific directory with an .htaccess file, but I’m not much more help there either.

  5. Posted December 12, 2009 at 3:44 am | Permalink

    You saved me dude !!!
    i also found that you can disable server gzip compression using .htaccess file
    http://www.flash-db.com/Board/index.php?topic=19252.0

    Thanks bro for giving me clues on this issue ^^

    Cheers from France !

  6. Posted December 13, 2009 at 8:52 am | Permalink

    Yep, same here – THANK YOU!
    (But IE8 still shows the bytes instead of the % – I’m on it…)

  7. Posted January 20, 2010 at 12:07 pm | Permalink

    Well it sounds very difficult to me.

  8. Posted February 22, 2010 at 6:59 am | Permalink

    awesome job figuring out this issue, debugging this on a project of mine was a pain. thanks!

  9. Roosevelt
    Posted March 10, 2010 at 10:38 pm | Permalink

    Total n00b here! I have this problem but I am in a hosted enviornment (e.g. i don’t have the ability to turn off gzip). How do I fix this problem. Again total n00b here so if you can be detailed and I’d be forever in your debt!

    Thanks in advance!

One Trackback

  1. By Flash : Pre-loading Issues « CrossFlight Studio on December 16, 2009 at 12:11 pm

    [...] was fine however. Now I was really confused. So I did a bit of research…Apparently, I’m not alone. The issue seeming stems from files being served up with GZIP compression before being sent to the [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>