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
by punk7890-2 at 12:03 AM EDT on October 14, 2018
Yeah, several sets stopped working for me as well and slow loading of most sets. A previous version would be nice until these problems get sorted out.
by kode54 at 7:27 PM EDT on October 14, 2018
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.
by thecoreyburton at 8:47 PM EDT on October 14, 2018
Thanks for replying, kode54!

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?

007 TWINE -> ~300MB (won't load into playlist)
1080ยบ -> ~150MB
Tamagotchi -> ~600MB

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.
by thecoreyburton at 12:27 AM EDT on October 16, 2018
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.
[edit] (45 minutes left)


Go to Page 0

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source
Generated in 0.0025s;