snaphat

Regarding what you said about caching: even though with ArchiveCacheManager it's already extracted, from LaunchBox’s perspective it isn’t — it’s “attempting to extract it,” so it should show the screen (briefly at the very least -- possibly too quick for humans to see). I hadn’t actually tested a different emulator or ROM before, but that turned out to be really helpful in narrowing this down. Based on what you said and the behavior I’m seeing, I’m now even more confident about what’s going on. It makes sense why you thought the issue was with ArchiveCacheManager, even though it actually isn’t. Let me explain. Based off of your video, I went back to a clean install of LaunchBox 13.12, switched to PCSX2, enabled ROM extraction in the emulator settings, and ran a large ROM/ZIP file. As you described, the progress bar showed, and everything worked correctly — every time. Then I swapped the game ZIP with a small one. It doesn't matter that it wasn’t a PS2 file; what mattered was that it was small. This replicated the hanging and no-progress bar. So from that, we can deduce that the issue occurs under these conditions: loading screens are enabled, LaunchBox is set to extract ZIPs, the archive is small, and BigBox is being used. That strongly suggests a timing issue or race condition, e.g. the extraction finishes before the load screen can render or pull output. Now, the reason this shows up with ArchiveCacheManager is because after extracting a large game (say >40MB, depending on the system), LaunchBox uses the archive cache on subsequent launches and returns immediately, as if extraction finished instantly. This triggers the same issue that small ZIPs normally cause because they are effectively instantly extracting. And that’s the trap: if you’re playing PS2 games and see this issue, then remove ArchiveCacheManager and test again, it’ll look like the issue goes away — because LaunchBox extracts the game every time, which takes long enough to avoid triggering the race in even the smallest actual PS2 games (probably Phantasy Star: Generation 1). Hence, your thought that it was ArchiveCacheManager with the issue. It's making necessary the conditions for the issue to show up with larger games for newer systems, but it shows up every time for the small roms. I reported the issue to the dev(s). Ya'll can't see it yet because it's pending approval but I'm dropping the link for the future: https://feedback.launchbox.gg/p/bigbox-hangs-after-launching-small-zips-with-load-screen-enabled

I tested and what I'm seeing is that BigBox hangs regardless of whether or not ArchivePluginManager is installed once I enable Startup Screens, so it seems the hang is in LaunchBox itself. You can actually install the original 2.16 version of ArchiveCacheManager with newer versions of LaunchBox, and the UI is just broken. Testing the original, I was able to verify the resulting extraction operations matched between the old and recompiled versions, so I don’t think it’s an extraction issue. To confirm the issue originates within BigBox, I took a clean install of LaunchBox 13.21 with default config, added my license, enabled Startup Screens, imported a single SNES ROM zip, imported RetroArch via LaunchBox's plugin manager, launched BigBox, ran the game, exited RetroArch, exited BigBox: same issue. If I remove the ROM from the zip and use that directly with LaunchBox, the issue no longer occurs. I think the progress dialog you mentioned is a strong clue to what may be happening here. I would surmise that BigBox’s archive extraction progress dialog, likely running on a separate thread, hangs, and when you exit BigBox, it waits indefinitely for that dialog to appear and complete. I don’t believe ArchiveCacheManager ever initiates or displays that dialog (in looking through the code); it seems to be entirely handled by BigBox. Based off of the architecture of ArchiveCacheManager and how it works to change the behavior of archive extraction in LaunchBox, I believe, LaunchBox/BigBox runs 7zip directly via the command line, and when the progress bar is supposed to be shown, it expects to read output from 7zip. It’s probably failing to do so in the case where progress information is expected and ends up hanging. This kind of issue is common as inter-process communication is notoriously tricky and often leads to hangs when output from child processes isn’t properly consumed.

Noted, I'll take a look and see if I can reproduce the issue

In the version on GitHub, I’ll include a download link for the required .NET runtimes when I publish the next release with the recent fixes (or bundle it self-contained perhaps?) It’s not surprising that people are hitting the runtime issues — ArchiveCacheManager depends on the Windows Desktop Runtime, which is an additional layer on top of the core .NET runtime already used by LaunchBox. This is likely due to its use of certain desktop UI APIs. I didn't realize it was an issue because naturally to even compile the thing, I needed the correct runtimes to be already installed 😄 I had just assumed it had the same runtime requirements as LaunchBox.

I looked into this. Correct me if I'm wrong, but it seems you have the platform configured to use M3Us, and all of the 7th Guest entries are set up as Additional Apps under a single Game. If that's the case, here's what you need to know: There are some bugs in Archive Manager's M3U generation that cause it to overwrite entries when multiple Additional Apps share the same disc number. I don’t think the developer anticipated that LaunchBox would allow duplicate disc entries. I’m addressing these issues in a GitHub fork, though I haven’t published a release yet. *More relevant to your setup*: when M3Us are enabled for a platform in LaunchBox, any Additional App with a disc number is automatically included in the generated M3U. Archive Manager replicates this behavior and also extracts all such discs into the cache. This isn’t suitable for single-disc games grouped under one game entry. The fix is simple—just remove the disc number from the metadata of each Additional App. Archive Manager will then treat them as separate games and skip the M3U logic, even without the bug fixes. Just for reference, by 'disc number' I’m referring to the Disc field under Edit Application: Hope this information solves your issue