I have created a photo gallery that has 96 images in it. When I browse the gallery using the Next button, everything works fine until I get to image #49 or #50 (sometimes #49 works and sometimes it doesn't) and then I start getting "Image Not Found (404)" messages for the remaining images. This is with IE9. If I try the exact same page in Safari, all 96 images display correctly.

I have tried the page in IE9 using Compatilibity Mode and without it. It makes no difference. I am running FloatBox 5.2.1. I didn't see anything specifically about this problem in any of the newer releases of FloatBox but I'm wondering if upgrading will fix this or if anyone else has seen this problem and may have a solution.

The web page that is failing can be found at:
http://davelevy.net/family/photo_gallery/20120625-Vacation-Cam1-EOS/TrainMtnVacation.html

Any suggestions would be appreciated.

Thanks!

Those are really big images and there's an awful lot of them. I think you are just overwhelming poor old IE with too much data associated with a single page. The images are typically more than 1MB (8Mpx) in size and there's close to a 100 of them in the one gallery. IE appears to simply give up trying to load all of that after a while and throws an error while attempting to do so. Floatbox interprets the error as a file not found.

It looks like you need to cut down both the size of the gallery and the size of the images. It is also certainly the case that you want to set preloadAll to false. Asking the browser to preload 100MB+ of images at each page view is certainly asking for trouble. Other than restricting preloading, I don't think there's much Floatbox can do for you in this case. It is IE that is failing to handle the volume of data and I think you just need to experiment to find a gallery size that IE can handle by restricting image size and count.

Thanks for the intersting information. I'm not totally convinced that it is just a browser capacity issue. I reduced the size of all the picutres significantly (by as much as 70% in some cases) but the floatbox control continues to correctly process only the first 50 images. It would seem that if I cut the size of all the pictures by 50% that I should be able to load at least one more picture but that is not what the testing results are showing.

I am going to upgrade the newest version of floatbox this evening and try it again. I'll post the results of tests after the upgrade.

Indeed, there is something more mysterious going on with that page. I see that preloadAll is still in effect on the page. I'd still like to see that set to false to see if that change will have a positive effect.

I actually think, but can't be certain, that there's something wrong with your server's delivery of the images that's tripping up IE, but no other browsers. Also, it's not consistent across IE instances. For example, my latest attempt has image 1 all transparent, 2 and 3 ok, 4 to 23 all transparent, 24 to 27 ok, 28 to 38 all transparent, 39 to 81 not found (404), 82 ok, 83 to 96 not found. I can see from IE's developer panel that the problematic images are reporting as loading just fine but are coming in as only 5 or 6 KB while the successful ones are coming in around 400KB each. A flush of my IE9 cache and reload of the page results in a completely different, but similarly screwed up, pattern.

One reason why I suspect something odd with the server is that I've never seen nor heard of similar behaviour from any other site.

Let's get rid of preloading. Upgrading to 5.3.4 is certainly a good idea, but my bet is it will behave the same. Also, do you have a local server where you build a dev/test instance of this site? If it behaves fine on that local site but screws up from the hosted instance, this would give pretty strong evidence to my theory that there's something subtly weird with the host's delivery of images.

If necessary, I don't mind trying to replicate this problematic page on my test server - images and all. But its your content and images, so please let me know if you don't want me to grab it.

As you suggested, I put preloadAll:false in my global options and reloaded the page. It changed things a bit but it still fails. Now, instead of it failing on picture #49 or #50, it fails on the 49th or 50th picute I load no matter where I start at. So, if I start on picture #40, I can navigate using Next until I get to picture #90 and then it fails. If I refresh the page, then it wil show picture #90 and wrap around to #1 and fail on picture #43 (50 pictures after #90; that is #90-#96 and #1-#43.).

It could possibly be some kind of limitation on the server-side of things but I'm just not sure how. The server is being provied by a commercial provider and I've not had any kind of problems when I used to use plain thumbnails and hyperlinks. The problem only appears at this mysterious "50 picture" limit when I try to use the floatbox gallery.

In any case, I will continue playing with different options and do the upgrade later this evening. If you think of anything to try or whatever just update this post and I'll pick it up when I get time. Thanks for looking into it!

Regards,
Dave

I upgraded to the latest release and, as you suspected, it didn't change anything. So, to test the theory of a server problem, I uploaded the entire folder that has all the pictures and the page to another server that I manage. This hosting is provided by GoDaddy (the other one is through a provider named Gate). The GoDaddy site also uses floatbox but it is a little older version. Once the upload completed, I accessed the page from the new location and it failed in the same way although it failed after only 36 pictures.

Clearly there is something wrong. I suspect it has something to do with how I am using floatbox or how it is being coded on the page. I just don't have a clue what it might be. I'm pretty sure I am coding it like the samples that I found in the Demo area but I will double-check everything.

In any case, having to break the galleries into smaller pages isn't something that I want to do at this point. I have bunch of other work to do so I will lay this down for a bit and come back to it later. Hopefully by then one of us may have come up with some new idea on what to try :-)

Regards,
Dave

You probably think I've been off sipping margaritas on the beach, but in fact I've been working on this pretty much full time.

There's a conspiracy of two problems here; one lies with Floatbox and the other belongs to IE.

The Floatbox problem is that when it preloads an image, it retains that image in memory. Given a large enough number of large enough images, this retention can consume all available memory and cause unpredictable browser failures. All image loads go through the preloader, so this memory consumption occurs whether preloadAll is active or not. This is a long-standing problem in Floatbox that goes right back to the earliest versions. I'm glad your giant gallery brought this to my attention so I can fix it.

The IE problem is that it has inadequate garbage collection and will eat itself by failing to release memory allocated to img elements that are no longer in use or referenced.

I have both these problems fixed in the code for the next version. I also have a callback function that can be used in the current version to retrofit the fixes. The callback works only with the current, most recent, release - version 5.3.4, build 2012-06-19. Try adding the following to the head section of your document:

<script type="text/javascript">
fbPageOptions = {
    preloadAll: false,
    afterItemStart: function() {
        fb.forEach(fb.data.XW.ZZ, function(path, img) {
            if (img.nodeName) {
                fb.data.XW.ZZ[path] = {
                    width: img.width,
                    height: img.height,
                    src: img.src,
                    XO: img.XO
                };
            }
        });
        if (self.CollectGarbage) self.CollectGarbage();
    }
};
</script>

Thanks again for making me aware of the issue.

It works! The work-around you supplied fixed it up very nicely! I'll keep an eye out for the next release.

You definately have earned a margarita now! Good job!