Loading same file multiple times on website demo about mechvibes HOT 8 CLOSED

It looks like the docs folder was removed in this commit 80f13a1

from mechvibes.

I'm not sure what the docs folder has to do with this, but this is because it is almost the exact same code as what runs in the app. The app operates this way to ensure that when the same sound is expected to play twice at once, the first one doesn't get cut off or not played at all. A solution to this would of course be an audio pool, but that adds complexity, and does still have the possibility of overflowing if you press keys too fast or if the sounds in the pack are longer.

P.S. as you can see in your screenshot, your browser is correctly using cached versions when using repeating files, which means there isn't wasted bandwidth.

from mechvibes.

Ok , i finally found the issue.

Let me explain, under the meme tag, i was trying to play Vine Boom and it was stuck on loading (Firefox Mac OS X ).
When i checked network tab a lot of files were loaded i thought this could be an issue and raised it here.

As you have explained the cached version is being used i can see this could not have caused the issue,
after some debugging i saw the audio played on chrome but not on firefox.

I went through the code and saw for this particular sound checkIfAllSoundLoaded() callback was not being called.

But Why ? all the code looked fine to me.
After some more debugging i finally found the issue !

This codec used in the file is not supported in Firefox !
also it looks like the .mp3 file is actually a .mov

• Output

Vine.mp3: ISO Media, Apple QuickTime movie, Apple QuickTime (.MOV/QT)

So this is what's happening in the end.

The resolve is never being called on the promise hence it will never be able to run anyting after await !
Which is the code responsible to removing the loading class and the loading state being set to false.

$(this).text("Loading...");
current_pack = await loadPack(pack); // code won't reach below this if promise won't resolve
// lock in new pack
$(parent).removeClass("loading").addClass("testing").addClass("cached");
loading = false;

Now it's okay if one sound loading fails but this also make loading state stuck hence no other pack can be tried 😞 .

Solution

I would suggest to use the loaderror event to show error to user and reset the state if we have such issue.

from mechvibes.

@PushpenderSaini0 This is still a website issue right? Not an app issue?

I do see that improper container encoding is definitely an issue I'll need to look into solving, as a .mov disguised as a .mp3 is a very bad thing, so I'll look into detecting this on the server side.

But I'll have to review the website code to see if this is fixable or not, as in howler.js, the library we use in the app, it's not fixable, as howler doesn't seem to properly inform us when an error occurs. I think this is due to the webaudio api though, not howler.

from mechvibes.

This is still a website issue right? Not an app issue?

Yes this is just a website issue !

Howler doesn't seem to properly inform us when an error occurs.

Can you try the loaderror event ?
I was able to get a call on this even when loading this mp3

from mechvibes.

Howler doesn't seem to properly inform us when an error occurs.

Can you try the loaderror event ? I was able to get a call on this even when loading this mp3

I likely can, since it's a website issue. I was saying that I can't do this in the app, because howler only calls loaderror on certain loaderrors, not all loaderrors.

from mechvibes.

@PushpenderSaini0 Please try now. I've added errors to all three load requests which fall back onto a try/catch near the await loadPack() call

from mechvibes.

Thank you, @NotLazy for fixing this. 🚀

• It's working as expected !
• Shows loading error, and does not block other packs !
  

from mechvibes.