Why llPreloadSound doesn't work

As of build: 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release)

This function only works when the sound has never been played/preloaded by the client.

This is why it fails.... The first time the sound is preloaded - it gets cached. And will play as you might expect - however when you quit SL - SL deletes the cached file..... BUT not
the GUID in the index. Consequently - when the client is restarted and a script tries to preload the sound - the preload will not take place because it "sees" the entry in the index file & thinks the sound has already been preloaded. The sound file itself however, is not in the cache because it was deleted the last time the client exited.

I will have been a SLitizen for 3 years in Feb 2009. And this problem still hasn't been fixed.

The fix is easy - remove the sound file GUID's from the index when SL exits. Or leave the sound files in the cache when SL exits.

Im Usin the same code in my new tool and it works fine the sounds triggers even after restart using the same viewer as you.Why is your cache deleting every time u restart thats not normal you probably need to look in that direction to solve your problem.

When I look at the files in my cache directory before I logout - there are plenty of guid.dsf files. When I exit - they disapear. Why? I have no idea - I tried looking for a "delete cache on exit" pref someplace but I couldn't find one.

It is possible that the client is compressing the cache into another file someplace. That might explain the problem. That is - if the client is slow at decompressing - I would hear dead air until the decompression finished. But I have a 3.3GHz machine, 800Mhz FSB & matching memory. I would hope that llPreload would decompress the files if they're already downloaded. But it doesn't.

Today - I took a look at the "Statistics" viewer & saw that after I played a song for the first time, relogged & played it again I could see that the song fragments were not being downloaded the second time. - No bandwidth was being used the second time & lots of bandwidth was used the first time the song was played. So then I wrote a loop that just did llPreloadSound on all the fragments. Nothing appeared in my cache & I also saw no activity on the bandwidth monitor. & finally, in my loop, I replaced llPreloadSound with llPlaySound & then the fragments did appear at intevals of 10 seconds. And then the song would play without skips.

This is probably completely off-topic, but, what is the difference between llPreloadSound and llSoundPreload? Does it actually handle the cache files differently, or are they really the same thing? The only difference I have noticed is that llSoundPreload doesn't have a time delay.

The difference is that llSoundPreload() was deprecated many eons ago.

LOL. Deprecated, huh? Deprecated and rendered non-functional, or deprecated and still working ("deprecated" is different from "obsolete" in CS terminology)? If still functional, does it work BETTER?

If you feel this is an error, please file a jira report.

Deprecated as in "tomorrow" it may do anything at all or nothing at all. Deprecated as in "one day" it will fail to compile.