foo_input_usf problems by DaggerMouth at 10:32 PM EDT on October 9, 2018
The last update to foo_input_usf seems to have a few problems for me. Many sets take long periods to load (some 10 seconds, some over a minute). If the track has a long loading time it will only play for a few moments before stuttering. This is on HLE or LLE. Other sets outright refuse to play when before they played fine.
Is this a bug in the plugin? Can I downgrade to the previous version because it works for me? If so, how?
by radornkeldam at 9:48 PM EDT on October 13, 2018
I'm having problems too. Loading USFs, whether 7z'd or decompressed, eats up RAM like crazy (good thing foobar is still a 32bit program or it wouldn't stop at ~4GB), and if you try to load enough of them it eventually causes foobar to crash. As for sets that no longer play (or load), 007 TWINE is one. I haven't tested more of them because the problem with foobar crashing after loading too many USFs isn't limited to loading them in one go, but it accumulates during the session. Trying to load the sets one by one accumulates the same RAM usage as loading them all in one go. As it currently stands, I would have to load each set separately and mind the RAM usage to reload foobar when it's too high and keep loading new USF sets. It's became really tedious and slow so I gave up xD
I've already outlined why in another topic: I switched back to the old emulator core, for compatibility with older rips. It also breaks compatibility with newer rips. I have not figured out a proper solution, other than providing two cores in the same plugin, and providing a tag to switch between them on startup.
For anyone interested, I think the post in question is the one here
I came here with the same problem. I've had a few sets no longer load and the rest take significant time to play (and stutter, on the longer loading ones), though I'll admit I've only tried a small handful of rips since the update.
While the proper solution is WIP, would it be possible for you to make a build of the previous version available?
Using the previous version (or switching back and forth) seems better than not being able to play sets at all for the time being.
edited 9:45 AM EDT October 15, 2018
by radornkeldam at 6:41 PM EDT on October 15, 2018
Apart from the non-playing sets, are you aware of the RAM usage hikes?
That's just the RAM hikes for the three first sets in alphabetical order. Actually playing the files keeps gobbling up RAM. I skipped through the entire tamagotchi set reaching ~2GB of RAM usage.
I had a look and noticed repeatedly loading "Cave Dungeon" from the Super Mario 64 set increased the RAM usage by 7-8mb per reload. It got to 500mb (and probably would have climbed higher if I'd kept going) with only that single song present in the library.
I tried with a different song from a different set ("Bio Hazard" from the Lode Runner 3-D set) and it behaved in the same way.
That'd be an "oops". I guess I can roll that back to the old library, which didn't have the memory issues, but does have issues with some older sets, particularly all of the Zelda series, where they'll play for a few minutes, then busylock the emulated CPU for several seconds of real time, before resuming playback, again for another few minutes. Maybe I need to specify a tag for re-ripped sets, and explicitly fail to load old sets.
Thank you for the rollback. To confirm, it looks to have resolved all of the problems on my end.
Regarding the tag implementation, perhaps a recommended core tag can be optional for each set. It could be made so users could choose a core in the foo_input_usf option dialog (defaulting to the most generally recommended core), along with having a pre-ticked checkbox saying something like "use recommended core for current set".
If the tag is present in the file and the checkbox is ticked, then there is a recommended core for the current set and it is used instead of the user-selected core. If there's no tag present or the checkbox is not ticked, then the user can define which core to use (this might help troubleshooting, too).
A "recommended core is not present" message or an explicit fail could be triggered for sets with a core tag that doesn't match the options available. Users could then disable the checkbox and play unsupported sets through a core of their choice at their own risk.
I'm not sure how practical this idea is, but it would prevent all sets needing to be re-tagged and also account for additional cores in the future.
Thanks again for fixing the immediate problem, kode54!
by radornkeldam at 5:46 PM EDT on October 18, 2018