fraganator

Thanks for testing and reporting back, and the supportive comments. Happy to hear it's working well now. I'll look at polishing the changes are putting out a new release soon-ish. @huh123 Sorry for not following up the M3U issue sooner. Is an M3U file being created but its contents are incorrect, or is the M3U not being created at all? Under the additional apps, does each disc have a disc number set? If you disable Archive Cache Manager (uncheck the Extract ROMs option under the emulator settings for RetroArch > Associated Platforms), does LaunchBox's own M3U playlist creation work with those games? In answer to your latest questions: Yes, that's the way to add multi-disc games. Archive Cache Manager creates M3U files based on the additional apps list, where one of the additional apps must also be the same as the ROM path for that game (usually disc 1). The M3U creation logic follows LaunchBox's own M3U creation logic as documented here. If the file is an M3U already, it gets treated as a normal ROM file - a future update to parse the M3U file and cache the files it references is something I've wanted to add, but haven't gotten around to yet. Games only appear in the Cache View if there's a game.ini file in the cached folder, which includes some metadata about the extracted / copied game. I'd guess that file doesn't exist, but it's unclear why it wasn't created.

Hi @W4rCh1ld - I believe I've found the issue. When a game is launched, Archive Cache Manager copies some files to the ThirdParty\7-Zip folder. Once the game has launched, the original 7-zip files are then restored. The issue in the logs showed those files were in use by another process. After a little debugging I think what is happening is LaunchBox is calculating RetroAchievement ID for the game in the background, which means the game is being extracted using 7-zip, and so the 7-zip files are in use. I've attached a beta version which doesn't replace the 7-zip files on each launch, but instead replaces them once when LaunchBox is first launched. Any calls to 7-zip be LaunchBox should continue to operate as normal (unzipping metadata, creating start-up and shutdown backups, and RetroAchievement ID scans). Please let me know how it goes. ArchiveCacheManager.v2.16.Beta1.zip

Thanks for those log files, that gives me some info to go on. Out of interest, is your LaunchBox folder being sync'd somewhere, like Google drive or with SyncThing? If it is, can you exclude the LaunchBox\ThirdParty\7-Zip folder from being synced?

Hi @W4rCh1ld Sorry to hear you've run into so many issues. Can you post the log files from the Plugins\ArchiveCacheManager\Logs folder? What version of LaunchBox are you using?

Hi @huh123, thanks for the comments and good to hear the plugin is helping improve your LaunchBox experience 👍 In answer to your questions: You're correct, if the emulator supports .chd files then there's no need to extract them first. The main use case would be if a new emulator popped up that didn't support .chd files, but your library contained chds. You might also use it to batch extract chds for transferring to a Raspberry Pi or similar, but even then I think most emulators on there have chd support now. If the emulator supports loading a game / rom directly from an archive then there's little reason to extract it first. The only real use cases are where an archive contains multiple roms (regions, hacks, etc) but you only want to play a certain version, or the emulator is picking up the wrong file in an archive (it has iso + md in the case of MSU1 patched games). Hope that clears things up!

As neil9000 mentioned, LaunchBox doesn't care about the file type, it just passes the filename along to the emulator when launching. PCSX2 has support for *.gz files, so there shouldn't be a problem.

Does that plan include variants, such as CD sleeves for demo discs, or double jewel cases (with dual spines)? An option to be able to select a custom case type per game would be awesome. My (physical) PSX EU cases are a mixed bag of wide jewel case, double jewel case, and regular jewel cases, where double jewel cases aren't always multi-disc games (Doom, Tomb Raider), and vice versa (Resident Evil 2). Is it possible for an end user to create a custom 3D case?

There was mention earlier in the thread of a plugin idea for checking hash results and missing titles, which might be expanded to a more general purpose RA auditing tool. For example being able to clear hashes and have LB rescan (due to updated ROM set, RA hashing fixes, etc). It might be a useful feature to add to my own caching plugin, so on extraction of 7z files it could calculate and populate the hash during the caching step if it hadn't already been hashed. Also the RetroAchievements Badge plugin would probably benefit from being able to access the hash / id, so could display a badge if those properties have been set. (Edit: I see the beta includes RA badges, so this might be kinda moot) I'll admit I haven't really used RetroAchievements until this beta release, but so far it's kinda cool. There's probably other cases where having plugin access to the RA properties might be useful. That said, I understand if those properties aren't something that should be exposed.

Looks good here, thanks. Will there be plugin access to the RetroAchievementsHash and RetroAchievementsId properties in IGame? Is there an option to disable auto hashing of games when selected in LaunchBox, where they haven't previously been hashed? For platforms (especially disc based ones) where ROMs are in 7z format, every selection begins extracting it to the Metadata\Temp folder. If many different (or the same) games are selected in quick succession, multiple instances of 7z.exe are spawned, using up CPU and slowing LB down: Also if LaunchBox is closed / killed while these spawned 7z.exe instances are running, they aren't aborted when they probably should be.

Regarding the RetroAchievements file hashing, is there an option to force rehashing of an individual game, platform, or all games? Or maybe an option to reset the hash so the next scan computes a new hash? Similarly is there a way to force a rehash of games which failed to hash correctly? (those tagged with <RetroAchievementsHash>COULDNTFILEHASH</RetroAchievementsHash>)

v2.16 is now available (link). This release includes: New M3U name option - "Disc 1 Filename" Always use the filename of the first disc of a multi-disc game for the m3u file, regardless of which disc was launched Allows better support for The Bezel Project config files, which use config files based on the ROM name New batch caching option to pause on caching errors (default is to skip and continue) Minor config window tweaks Thanks @MTyrealhanla and davis-junior for submitting the latest feature requests.

Hi @hydef I've had this issue for a long time and never managed to resolve it. See this issue on the issue tracker. The workaround I've been using is to launch a game with the Ctrl+P shortcut, rather than pressing Enter. This reliably launches the game / emulator once.

Thanks for investigating. I'm at a bit of a loss here - I tried repacking the bin+cue files in 7z rather than zip, and that does hash correctly (after the temp extraction). I then tried recreating the zip file in case that was the problem, but no dice. For completeness I tried importing the bin file rather than the cue, and that hashes correctly too, so it's not a bin / cue issue. It seems to be a problem with zip files specifically, though zip files for other consoles (such as Sega Genesis) work fine For reference I'm testing with Doom (USA).zip for the Sony PlayStation, which contains cue + 8 bin files. Any idea if the app Is using the hashing functions in the rcheevos / rhash library? Maybe I'll find some clues in there.

Thanks for the info. I found if the zip was extracted and the cue file imported to LB, the hash is calculated correctly. Similarly if the game is converted to chd and hashed, it works. Maybe the app is picking up a bin file instead of the cue file from the zip.

The new sidebar platform icons are really nice - is it possible in the theme to enable pixel snapping for the icons? Depending on window size and the item row, some icons are sharp while others are blurry. For example here's the Sony PlayStation icon, with the original png on the left and how it appears in LaunchBox on the right. It'd be nice to keep them looking sharp and retain their detail.