dan_default
dan_default

Reputation: 53

Duplicate audio files in preloadjs manifest for LoadQueue

I am populating a manifest array for use by preloadjs's LoadQueue class. In the manifest, I am referencing sources to both audio and image files while creating unique ids for each. This all had been working great.

However, as the audio/image files are being selected from a CMS database (Wordpress custom post types), it may be the case that the same audio may be selected more than once. In other words, the same audio file may appear in the manifest more than once. When this happens, a very odd bug occurs where the last IMAGE reference in the resultant LoadQueue instance returns "undefined". It doesn't matter where the duplicate audio occurs in the manifest array, its always the last IMAGE object in the LoadQueue instance that returns undefined.

Duplicate image files do NOT cause a problem.

Is this a bug in preloadjs? (yes, it is of course wasteful to load more than one copy of the same audio file, but in my use case, we are talking about small files and a finite number of posts)

var manifest = [];

for (var i = 0; i < game_pieces_data.length; i++) {

    manifest.push({id: "sound" + i, src: game_pieces_data[i].audio_url});
    manifest.push({id: "image" + i, src: game_pieces_data[i].image_url});
}

preload = new createjs.LoadQueue();
preload.installPlugin(createjs.Sound);
preload.on("complete", handlePreloadComplete, this);
preload.loadManifest(manifest);

function handlePreloadComplete() {

    var bitmap;

    for (var i = 0; i < game_pieces_data.length; i++) {

        bitmap = new createjs.Bitmap(preload.getResult('image' + i));

        // bitmap.image.width <- will return undefined for last item of
        // the loop if one of the audio files is a duplicate?
    ...
    }
}

EDIT: I've determined that LoadQueue's "complete" event is firing before the final "fileLoad" event fires (the last image). This is the reason for the final image being undefined when asked for in my handler for the "complete" event. Again, this only happens when there is a duplicate audio file.

EDIT2: To further narrow down the issue, I've created a manifest that is only loading audio files and traced the "fileload" and the "complete" event. For every additional duplicate audio file, the number of "fileload" events fired for that file increases by 1 (2 dups = fileload fires 3 times for that file, 3 dups = fileload fires 4 for that file...etc). Additionally, an extra copy is added to the LoadQueue instances array of files (accessed by getResult).

However, the "complete" event will fire after the length of the manifest is reached, hence additional fileloaded events being fired after the complete event. The harm in this comes when you have a manifest with mixed files. In my case, my image files are getting pushed to the end of the queue by the extra duplicate audio files being made. And since "complete" fires correctly at the end of the length of the manifest, it fires before any image files being pushed to the end of the queue can be loaded causing errors in code expecting those file to be there after the queue completes.

I am working around this by creating 2 LoadQueue instances, one for the audio and one for images. When the audio queue "complete" fires, I create the image one and load those from a separate manifest. This is not idea however as it appears that there are now multiple useless duplicates of duplicate audio files in memory. And this number increase exponentially with each additional duplicate that may be selected in the CMS.

Upvotes: 1

Views: 366

Answers (0)

Related Questions