bum51's dashboard

My expectation is that this is probably because you are trying to direct to an unavailable location. First, make sure that the location is available from a browser.

Say you're doing this locally, and you are at :
http://localhost/

then you are trying to access :
../../swf/soundmanager2.swf (or "../../swf/" when applying to SM)

then browsers will resolve to :
http://localhost/../../swf/soundmanag...

Which doesn't exist.

Try putting it in a sub folder or in the same folder and see if that helps.
Alternatively if it is in a subfolder the root of the domain, you can replace "../../" with "/". So you would have
/swf/soundmanager2.swf (or "/swf/" when applying to SM)

which will always resolve to the root domain, and you would end up with
http://localhost/swf/soundmanager2.swf

from whatever page/folder you're currently at instead.

Otherwise I expect that more details are needed (like a testcase).

I would think that another option would be to have the page player reference an instance of soundmanager on page load. Then when you load each frame it can check for the parent page and soundmanager. That way you only have to find the reference once per page load, and if no parent soundmanager exists, then load up the scripts on the local page and run it from there.
This method would have the added benefit that if you navigate away from the page in one of the iframes then the top level never has to know about it. The page can either look for a parent or won't, and no harm done.
In fact, this could probably be done with a little tweaking to the soundmanager init function so that you don't have to change all the references elsewhere. All you would need is to insert a little custom check for a parent page and parent soundmanager, if it then fails, it would automatically fall back on itself and create the flash object.

Client side apps don't generally have access to view folder contents. You CAN enable this in apache I believe, but it would be much much easier to make a server-side script to compile a list of available songs and send that to the client.
Don't have an example on me, but I know that the php filesystem objects certainly allow that kind of action. Just about any server-side scripts do.

Dagnamit! I just witnessed it happen again :(

See that's where it's still weird. I'm not trying to multishot anything, I mean I do play the sounds multiple times, but never at once. In fact, in the while events I have stuff in there so that if the sound playing isn't the "current" sound, then it will stop itself.
And it doesn't seem to matter whether it's the first time the sound is loaded or the 50th. It's just intermittent.
And just to note, when it happens, the values don't seem to change at all. (duration and position certainly don't update ever, didn't check on the bytes/bytestotal)

So I'd just like to present an update on this issue. I'm still not entire sure that it's fixed, but I haven't seen it happen in a while since I made a tiny change so I'm updating you now anyway.

Not sure why this would work, however I was previously using autoLoad=false and not defining the autoPlay attribute in the defaultOptions.
I have now defined autoPlay=false and it seems that the issues is gone.

The only thing I can come up with that would make any sense is that it was trying to play the sound somehow without loading it, and then the flash thought that the original instance of the sound was playing already, so when it finally loaded and played, it thought that it was a multishot sound, and so the while events would not fire.

I've looked through both my own code and the soundmanager JS and have not found anything that would in any way cause this. I don't have much experience with ActiveScripting but I checked that out and it all seemed good as well.

As I said, I have no idea why this works or would even make any difference as soundManager even defines autoPlay: false anyway.

I do still believe that it somehow ties into multishot, as every other event fires just fine and my code all uses the same events, so if it were breaking once then it would probably break every time.

Another thing I'd like to note is that if I played a sound, and it failed, then I unloaded and re-loaded then it would sometimes have fixed itself. Sometime if it were fine in the first place then it would break the second time and so on.

With any luck, it was actually a flash issue that has been resolved by an update of some sort, because I'm really running out of explanations here :D

I would like to note however that using the prefixes results in the same, but the first issue won't exist, so it's probably better if you do it that way if you use the prefix method as it's a bit safer regardless. – bum51, on July 06, 2009 17:24

I previously had a similar issue with soundmanager and found that if you turn your id into a string like so:

for (var i = 0; i < array.length; i++)
soundManager.createSound({id: i+"", ...});

then it creates the value into the object part of the list instead of the array, and will accept any value.

In essence this way you get a hashtable instead of an array.

There are 2 issues I know of using it this way...
The first: you can't use the
soundManager.sounds.0.play()
syntax.
However, instead you CAN use
soundManager.sounds["0"].play()

The other issue is that if you try to use
soundmanager.sounds.length
then it will never show the correct number of sounds, however since you obviously already have an array of sounds then I wouldn't think that this will matter that much.

Actually in my case I only actually want this for some debugging ;-)

I absolutely love this idea. My only suggestion would be letting the coders choose the fallback order.
For instance, I want to be able to use waveform and eq data where possible, so I would want to have an order of flash then html5 but for those who don't, you might want to be able to set html5 first in case it would run faster (I believe that the html5 standard is also supposed to support seamless repeats, so that would certainly be nice).
It would also be nice to do it that way in case you know that say, most of your clientele will be using IE.
Plus, the HTML5 standard technically only supports OGG formats I believe at the moment (though browser makers obviously aren't going to be happy with just that as mp3 is a much more popular right now, so I expect they'll generally implement it, but some purist browsers won't)

On top of that allowing specific fallback orders according to file type would be nice as well. However that could make it very messy I think.

EX. (cleanest I came up with)

sm2.fileTypes = {
"mp3":["flash","html5audio"],
"ogg":["html5audio"],
"flv":["flash"],
.....
}

And then should be able to "override" the file type for a given sound object.

The biggest problem (which would also be a nice bonus at the same time) I see with that is that it would require soundmanager to change the way it functions for each file type. Meaning that you could get a mix of flash and html5 on the page.

Unfortunately flash/javascript does not have access to the filesystem for legitimate security concerns, so no you can't do this.
The best alternative I can think of would be to have a server on the client machines and then give them a full-copy of the app with the files on the server.
There may be a hack in one (or more) browsers that allows it but if you find it then they will patch it.

Otherwise what you are looking at is a standalone application, which could easily be accomplished through something like Adobe Air.
I have not tried SM with Air, but it might be worth looking into for such an app.

Hahaha, I hadn't even considered that! My entire implementation is dynamic and we don't even use "A" tags. It's all divs and spans where the songs are concerned and it's not even in the source because it's all loaded via ajax. You can still get the keys out of say, firebug, but so many of our users don't even know what firebug is that it's safe enough for us.

Having myself reconsidered the idea of the http headers, I expect that it would end up being convenient, but after a while if the user base for any website is to grow then it would have to be removed for compatibility with non-flash or non-js browsers.
Example:
iphone (rapidly growing popularity for browsing); no flash, therefore you should be able to click on the link to download it, however if we add a special http header then it would not be accessible via a regular "get" access. Of course you could check the special header AND the referrer, but after a while it ends up with really jumbled code when you need to hard code every single header that you may use.
In essence, with the idea of backward AND forward compatibility on the web (html5) it's probably a bad idea to implement something that would be dependant on that, though for now and the next year or two it will probably be a perfectly acceptible form of security.

Plus, the http headers are just as easy as post variables to fake with all the developer tools available these days. Let alone the thousands of hacking/pirating tools ;-)

Nicholas has my method to a T.
One extra little tidbit would be that you don't even need to have the sound files directory in the http accessible folders. You could have them in a completely separate location on the hard drive that apache doesn't allow access to, and then the "getmusic.php" file would be able to access them regardless. This way you can even protect against admin priviledges.

And of course for the HTTP headers thing, you could add that directly to the getmusic script. It should only be a problem of telling it to expire immediately so that as soon as you unload the sound it vanishes. Hadn't thought of that one, good call!

Almost exactly correct, you can also access the files if you guess the right key without being logged in (as there's one for each user that IS logged in) but if you make it a big enough key (md5 the timestamp or something) then it's very difficult to guess.

Yeah, I've actually stripped the code down to using console.log for debugging rather than my regular event handlers, so I doubt it's that. I would agree with you that it didn't recognize the playstate, except that I wouldn't think that the whileloading event depends on that and it's got the same issue.

It IS however possible that it's happening when the file is played more than once in a single session, as I reuse the sound objects if they need to be accessed more than once (but I unload them after each time they completely play through).

I haven't found any consistent way of watching for that error, it's actually happened on one of the first 5 sounds (none of which were the same) in one session when I was testing. As I've said, it's very intermittent.

And yes, I'm using Flash 9. The SM debug info seems to be exactly the same as it would normally be. I've also been using debugging flash in one of my environments and it doesn't seem to throw any errors either. I'm fresh out of ideas on this one which is why I'm posting, because I haven't seen anything go wrong with SM in quite a while but I can't find anything that would cause it in my own code :(

Here's what I've done to secure my website:

1) in your database have a "logged-on" users table, with a special (session specific) key for each one.
2) when logging in, assign a key, then save it to the table with a timestamp
3) pass the key with the url as a GET parameter.
4) update the timestamp when accessed and still logged in

this way:
-after a certain amount of time you can delete (or ignore) the old logged in records so that no one can get real urls without having logged in
-if you have session issues (php seems to crap out if you try to use regular session variables) then the users can still access their songs
-you can "hide" all of the sounds through a non-http accessible folder, then stream using whatever language you're using

the only thing here is that you have to make absolute certain that you provide the keys when accessing the sounds.

It's still impossible to hide it completely, but at least it would force people to have an account and log in.

Hahaha, sure that'd be great! But for the sake of mild anonymity, I'd like credit as either "bum51" or "Steak" (if you don't want to put "bum51" on your site ;-) ) no real names for me :)

haha, woops! – bum51, on May 28, 2009 23:01