Jump to content
LaunchBox Community Forums

fraganator

Members
 View Profile  See their activity

  • Posts

    142

  • Joined

  • Last visited

  • Days Won

    2

 Content Type 

Everything posted by fraganator

  1. 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.
  2. fraganator
    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
  3. fraganator
    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?
  4. fraganator
    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?
  5. fraganator
    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!
  6. fraganator
    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.
  7. fraganator
    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?
  8. fraganator
    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.
  9. fraganator
    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.
  10. fraganator
    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>)
  11. fraganator
    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.
  12. fraganator
    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.
  13. fraganator
    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.
  14. fraganator
    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.
  15. fraganator
    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.
  16. fraganator
    There looks to be a bug with the on-the-fly hashing, where one game will begin extracting multiple times. In my case I have a PS2 game in 7z format. If it hasn't previously been hashed and I select it in the LB interface, a background process is started which extracts it to Metadata\Temp\{GUID}. If I quickly select a different game, and select the same PS2 game again (while the first extraction is still going), LB will begin another hashing process, extracting the game again to another GUID folder. If this is done quickly, there can be upwards of 5 or 6 extraction processes running for the same game, which uses up a chunk of CPU. I've found zip / 7-zip disc based games (PS1, PS2, etc) don't produce a valid hash and instead are listed as COULDNTFILEHASH in the platform xml file. Do they need to be a certain format? In instances where the hash fails, can LB fall back to the title matching method?
  17. fraganator
    This is a known bug which seems to be related to the platform specific startup themes (Wii, GC, PSX, PS2, Dreamcast). I first noticed it in version 12.6, but it is still present in LB 13.1, Hopefully a fix appears soon.
  18. fraganator
    Version 2.15 has been released! This version includes a new on-the-fly redump iso to xiso conversion option for Microsoft Xbox games. The original rom file (zip or iso) won't be modified when converting to xiso. The rom is extracted or copied to the cache first, and that copy is then converted to xiso format. The resulting .iso.old copy from the cache will then be deleted. The xiso file in the cache will then be used when launching the game. After installing the v2.15 update, download extract-xiso and place the exe in the LaunchBox\Plugins\ArchiveCacheManager\Extractors folder. In the Archive Cache Manager config, add your Xbox emulator on the Extraction Settings page, and check the box in the extract-xiso column on the right. Also make sure the emulator has the Extract ROM archives before running option checked in the LaunchBox emulator settings. (thanks to @ErAzOr and @MattSidney for the suggestion on github)
  19. fraganator
    Hi @Kronos9294 When Launch Path is set to Platform, the archive is first extracted / copied to the cache. Once it's cached, the Platform path is created. A hard link is then created within the Platform folder to the cached game. In File Explorer this looks like there are two copies of the game, but in the file system itself there's only one copy of the game but with two links to it. The decision to use hard links means only one copy of the game needs to be in the cache, but can be accessed from different paths without the overhead of copying (large) files. When another game is launched on the same platform, the previous hard links in the Platform path will be removed (the original game will remain cached), and the new hard links created. If the original game is launched again, it is already cached so only the hard links need to be updated.
  20. fraganator
    More information about ""
    I've raised an issue on github to track the request. Things are a little busy at the moment, but hopefully I can get to it soon 👍
  21. fraganator
    More information about ""
    Hi @viritys That might just be a feature request Currently additional apps / multi-disc games are extracted to individual folders in the archive cache, and requires that each additional app has a disc number assigned (see screenshot). In your case, do the additional apps have a disc number? Or just the side A/side B setting checked?
  22. fraganator
    Hi @MontyMole NTSC is probably the way to go. The 60Hz rate looks good on modern TVs, and doesn't require 50Hz to 60Hz resampling. Technically the NTSC format is lower resolution than PAL (480 lines vs 576 lines), but I don't think many PAL releases took advantage of the higher resolution, and instead opted for black bars. So though PAL is higher resolution, the end result looks smaller on screen because of the bars. The only real factor to consider is regional differences between games. I grew up with EU / PAL games too, and prefer playing the PAL versions of certain games because that's what I remember. Things like music or voice acting can differ between regional releases. If there are any favourite games you remember playing in PAL format, it might be worth keeping both versions around (unless the NTSC one is obviously better). What file format are the Saturn games in? If they're a zip or uncompressed cue+bin, you can reduce space by converting them to chd.
  23. fraganator
    Version 2.14 of the plugin is now available (download here). This version adds a Batch Cache Games feature, available in the right-click menu. The batch caching feature allows multiple ROMs to be extracted or copied to the archive cache at once, ready to be played later. In my case I have LaunchBox setup on a laptop, with the game library stored on a NAS. This is great for playing at home on the couch, but sometimes I want to bring some games to a friend's place. Bringing the laptop isn't a problem, but all the ROMs are on the NAS and can't be (easily) accessed from elsewhere. With the batch cache feature, a selection of ROMs can be easily cached on the laptop. The same LaunchBox setup can still be used when disconnected from the NAS, and without needing to make any changes to ROM paths. Provided the plugin's Always Bypass LaunchBox Path Check is enabled, games will be launched directly from the cache.
  24. fraganator
    Not a problem, @JamesBond@ge. Good to see it's displaying correctly. Thanks for the comments
  25. fraganator
    It depends on the emulator (I think standalone mednafen supports m3u with zip) but in general yes, m3u works best with uncompressed zips, or with chd compressed ROMs. If the multi-disc ROM files are zipped, you can use the Archive Cache Manager plugin (full disclosure - I'm the author). It will auto extract all the zip files in a multi-disc game, and then generate an m3u file pointing to the extracted files. Another option is to extract the zips, then convert the resulting cue+bin to chd using chdman. You'd then need to update the game(s) in LaunchBox to point to the chd files. The LaunchBox generated m3u would then contain the chd files, which can be read by most emulators. Another option again is to extract the zip files, and manually create an m3u file which contains the filenames of the extracted cue files of each disc. The game in LaunchBox can then be updated to point to the m3u file. When the game is already configured with an m3u file, an m3u won't be automatically generated, and is instead passed directly to the emulator.
×
×
  • Create New...