ID:974682
 
Keywords: sound
Resolved
Sounds are no longer put into the cache directory where they could hang around forever.
BYOND Version:496
Operating System:Windows XP Pro
Web Browser:Chrome 22.0.1229.39
Applies to:Dream Seeker
Status: Resolved (499.1200)

This issue has been resolved.
Descriptive Problem Summary:
when a /sound datum's file variable is set at runtime, and the sound datum is outputted to a player, the file is copied into the cache directory every time the world is reinitialized.

I discovered the problem cause I am outputting a rather large ~20mb sound file, and after a few dozen times opening and closing dreamseeker, I realized that the local disk had run out of space. So I checked the byond cache directory, and there you have it, multiple copies of the same file.

It makes no difference whether you use '' or file() to load the file.

Numbered Steps to Reproduce Problem:
1. Download test
2. Press play sound
3. Close and reopen test.dmb
4. Repeat steps 2 and 3 a couple of times
5. Check the cache directory.

Expected Results:
The file is cached only once, or not cached at all in the case of files in the rsc.

Actual Results:
The file is always cached, and multiple copies of the same file are cached over and over.

Does the problem occur:
Every time? Or how often? Every time
In other games? n/a
In other user accounts? n/a
On other computers? n/a

Workarounds:
None, except going in there and deleting the cache files.
Caching sound files can be a tricky business because we found out that multiple sessions could interfere with each other if they both relied on the same file. It seems though like the obvious solution to the problem is for some kind of cache cleanup to be implemented to keep this from becoming a problem over time.

That said, 20 MB is way, way too big for a music file for your game. I think it's a mistake for authors to even allow 2 MB music files, but this is too much by a mile. Consider the player experience: That's a hefty download time for most people. If you want long-playing music, it's really a far better choice to use a module format. You can compress .xm files into the .oxm format which FMod can read, and that gives you incredible space savings. It's rare for a module-format file, except a very high-quality one, to exceed a megabyte; if you use .oxm it should be unheard of. Take a look at what's available at modarchive.org.

Of course I want to reiterate that the cache overflowing is in fact undesirable behavior, and so I think a bug report on the subject is appropriate. We definitely will want to address this. In the meantime, I think you'll want to do a hard rethink on your music files regardless because with or without the bug, your game will be undesirable to play over a network.
Thanks for the reply. I'm not using the big sound file for a game, and I'm aware of compression alternatives. One thing that puzzles me is why it's even caching at all when the world is being run locally.
As I recall, FMod requires the sound to be in its own file. If two different instances try to use the file at the same time, bad things happen, so we give each file a different entry in the cache based on the process ID.
Something still needs to be done about this... Every time you hear a sound, its put on the hard disk, and if you were to start a new game session over and over, you'd get a new set of cached sounds each time.

Furthermore, this is scary for anyone who wants to sell an OST.
In a recent version I updated the pager so that it will clear out old cruft from the cache when it starts. I can probably do a little better on the sound files though.
I plan to make most of my money from selling my OST, and have invested a lot of money into my OST. Will there be a way to make it really hard for someone to get the songs apart from opening cache and renaming the songs lol?
Lummox JR resolved issue with message:
Sounds are no longer put into the cache directory where they could hang around forever.
Amazing. Amazing. Amazing.