llPreloadSound() - does it preload unnecessary data?

[Vegro Solari]

Supposing a script called llPreloadSound() on the same exact sound, time and time again. Will clients in range be re-downloading the particular sound even though it's already cached on their viewer from the first tile llPreloadSound() was called?

Anyone know?  And what if the second preload call comes WHILE the first one is still downloading to the client, does that mean the client is now downloading the same file twice, concurrently?

 

Thanks.

[Kaluura Boa]

I am no expert in the SL cache system but I know for sure that cached files use the in-world UUID as name... So, in theory, the answer is no, no and no.

Once the first preload has started, the UUID is used so the client will not start another download for the same UUID. This prevents concurrent downloads for the same asset.

Next, whether the asset is fully downloaded or not, it will be considered as cached. So, if the cache is not too buggy, no new download will occur until the asset is flushed because the cache needs to make room to stay below the configured limit.

However, I think that using llPreloadSound() in a timer will force the clients in range to check their cache repeatedly and some people might consider this idea negatively... especially if they never come close enough to actually hear the sound. Think also of your neighbors and the client-side lag it can induce.