Archive Cache Manager

[duerra]

@snaphat I see you're actively maintaining a fork of the original plugin.  Do one of your unreleased commits address the 7-zip errors using the latest LaunchBox release?  It looks like this isn't only happening to me.  I had it working on a previous LB version.  I tried the latest build from 2 weeks ago and I am getting the "7-Zip returned an error when trying to extract the archive." error message.

[Tayley]

1 minute ago, duerra said:

@snaphat I see you're actively maintaining a fork of the original plugin.  Do one of your unreleased commits address the 7-zip errors using the latest LaunchBox release?  It looks like this isn't only happening to me.  I had it working on a previous LB version.  I tried the latest build from 2 weeks ago and I am getting the "7-Zip returned an error when trying to extract the archive." error message.

Have you tried the earlier solutions to this error message?

[duerra]

Yeah, which is how I originally got it working.  Unless I missed a step somewhere.

[duerra]

One note - there should not even be any 7-zip extraction being performed for the file in question, since for this emulator it's "Copy" only.  It's still happening for emulators requiring extraction too, however.

Edited May 9 by duerra

[Tayley]

13 minutes ago, duerra said:

One note - there should not even be any 7-zip extraction being performed for the file in question, since for this emulator it's "Copy" only.  It's still happening for emulators requiring extraction too, however.

I had the exact same issue, do you have the most recent net? 

on windows cmd:
 

dotnet --version

it should be at least 9.x.xxx

Edited May 9 by Tayley

[AZUR3US]

On 5/6/2025 at 6:49 AM, kajunpoon said:

Have you resolve it? I have the same problem. It worked in the old version of LB and ArchiveCacheManager. 

I resolved the issue by updating .NET.
When you start ArchiveManager in a console, it gives you an error message about an outdated .NET version and provides a download link to the latest version of .NET.

[duerra]

Aha, this was it; thank you @AZUR3US - somehow I must not have had the latest .NET runtime.

[snaphat]

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.

Edited May 10 by snaphat

[ojed4r]

@sbamsbamsbam @snaphat Hey guys! Thank you so much for keeping this plugin updated, as someone who keeps the majority of his ROMs zipped, this plugin is a necessity. However, I found a weird bug that wasn't on v2.16.

It seems that if you have both the plugin and startup screens enabled, LaunchBox creates a second instance once you launch the game and if you close LB altogether, it doesn't shut down properly. 

In the video I've attached, you can see that even if I closed bigbox, the program is still active since you can still hear the background music and I have to end it through task manager.

I'd like to keep both the plugin and startup screens enabled so I will have to downgrade to version 13.18 of LaunchBox, the last one that supported the old plugin. I'll appreciate if any of you guys could take a look into this and fix it for the next release. Nonetheless, thank you for keeping this great feature alive and let's hope that it gets natively implemented into LB. Keep it up!

 

 

[snaphat]

On 5/12/2025 at 5:37 PM, ojed4r said:

@sbamsbamsbam @snaphat Hey guys! Thank you so much for keeping this plugin updated, as someone who keeps the majority of his ROMs zipped, this plugin is a necessity. However, I found a weird bug that wasn't on v2.16.

It seems that if you have both the plugin and startup screens enabled, LaunchBox creates a second instance once you launch the game and if you close LB altogether, it doesn't shut down properly. 

In the video I've attached, you can see that even if I closed bigbox, the program is still active since you can still hear the background music and I have to end it through task manager.

I'd like to keep both the plugin and startup screens enabled so I will have to downgrade to version 13.18 of LaunchBox, the last one that supported the old plugin. I'll appreciate if any of you guys could take a look into this and fix it for the next release. Nonetheless, thank you for keeping this great feature alive and let's hope that it gets natively implemented into LB. Keep it up!

 

 

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

[ojed4r]

On 5/17/2025 at 12:56 AM, snaphat said:

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

@snaphatThanks man, appreciated. Looking forward to any update regarding this issue.

I've just downgraded to LaunchBox v13.18 to test out the plugin's v2.16 made by @fraganator and can confirm that his version doesn't have this bug. Another oddity I've noticed regarding this bug is that usually when you have startup screens enabled (the default theme at least), when launching a game it displays a progress bar that fills out normally on v2.16, but on all .NET 9.0 forks of the plugin I've tested, the bar won't show up at all. Could it be that when launching a game the plugin is attempting to extract the archive even though it already has? Hence it creates a second instance of LaunchBox?

[snaphat]

5 hours ago, ojed4r said:

@snaphatThanks man, appreciated. Looking forward to any update regarding this issue.

I've just downgraded to LaunchBox v13.18 to test out the plugin's v2.16 made by @fraganator and can confirm that his version doesn't have this bug. Another oddity I've noticed regarding this bug is that usually when you have startup screens enabled (the default theme at least), when launching a game it displays a progress bar that fills out normally on v2.16, but on all .NET 9.0 forks of the plugin I've tested, the bar won't show up at all. Could it be that when launching a game the plugin is attempting to extract the archive even though it already has? Hence it creates a second instance of LaunchBox?

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.

Edited Sunday at 09:24 PM by snaphat

[ojed4r]

1 hour ago, snaphat said:

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.

@snaphat Thank you for taking the time to test it out. It is odd since I had different results on v13.21 in that when I ran a zipped game for the first time (the ROM wasn't cached yet) the progress bar displays and BigBox doesn't hang when closing it. Then, when I ran the game again (this time it should be already cached by the plugin) the bar fails to load and the program hangs when closing it. This led me to think that the issue was the plugin since if you don't use the plugin at all and run archives on LB, the program keeps the ROM on a temp folder and deletes it once you close the game. And did you tried any other emulators besides retroarch?

[snaphat]

5 hours ago, ojed4r said:

@snaphat Thank you for taking the time to test it out. It is odd since I had different results on v13.21 in that when I ran a zipped game for the first time (the ROM wasn't cached yet) the progress bar displays and BigBox doesn't hang when closing it. Then, when I ran the game again (this time it should be already cached by the plugin) the bar fails to load and the program hangs when closing it. This led me to think that the issue was the plugin since if you don't use the plugin at all and run archives on LB, the program keeps the ROM on a temp folder and deletes it once you close the game. And did you tried any other emulators besides retroarch?

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

[Clutz450]

37 minutes ago, snaphat said:

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 would encourage everyone to give this an upvote once the administration make it public.

Edited Monday at 06:44 AM by Clutz450
Typo

[ojed4r]

@snaphat So, I wanted to do some testing and see if that bug regarding small size archives could also be replicated on my end, and turns out that YOU WERE RIGHT! I installed v13.21 without the ArchiveCacheManager plugin and if I run a small zipped game with startup screens enabled, the progress bar won't show up. Then, I shut down BigBox and the program hangs as I have to close it via task manager. Can confirm this in the following video were I did the test with a Master System game (a <1mb ROM):

 

 

 

In the next video, I did the same test but I tried a PS1 game instead (a >100 mb ROM) and this time the progress bar displays and BigBox shuts down properly:

 

 

This is definitely a LaunchBox issue present in all versions since 13.19. In the last video I will show you, I go through the same test I did on the first video but this time on v13.18, the last version where I didn't encounter this bug:

 

 

And as you can see, I opened the same Master System game as the first video and the startup screen worked without issues and BigBox shut down properly.

Perhaps something should've happened during the .NET 9.0 conversion that broke startup screens for small archives.

[ojed4r]

@snaphat Did any of the admins replied to the bug report you made on the feedback forum?