Jump to content
LaunchBox Community Forums

-McFly-

Members
  • Posts

    302
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by -McFly-

  1. I'm waiting for a new rig for my arcade, this is on hold until I get it. Expect an update in about 2 weeks. (update - i went back to this a little early as I found some time)
  2. This is still in Beta. I've been working on this for a few weeks now, let me know if you find any bugs so I can squash 'em please. Use this at your own risk though, you know the deal with beta software... I'm not responsible if this breaks your setup.
  3. Launchbox Precache Manager - Speed up your build - BETA VERSION! View File LPM Readme.docx LaunchBox Precache Manager (LPM) Mass image optimizer + junction-based precache system for LaunchBox libraries. TL;DR This tool scans your LaunchBox Images folder, builds a compressed WebP/JPEG precache into Images\_Precache, and then (optionally) swaps your original image folders for the precache using NTFS junctions. You keep your original art safe in Images\_Originals, LaunchBox gets faster scrolling and lower disk usage, and you can restore the originals at any time. If you’ve got a large LaunchBox setup with hundreds of thousands or millions of images (fanart, box art, logos, screenshots, etc.), this toolset is designed to: Build a highly compressed WebP/JPEG thumbnail “precache” for almost everything Keep your original artwork safe (in a parked folder) Swap in the precache folders via NTFS junctions Speed up scrolling and reduce SSD usage, while keeping LaunchBox itself happy It’s built for libraries in the millions of files range and tested against real-world installs with very large Images trees. This package contains two main scripts: LB-Precache-Manager.ps1 – interactive front-end menu Build-LaunchBox-Thumbnails-Parallel.ps1 – the “engine” that does all the heavy lifting The manager itself is run by launching the separate ‘Launch-LPM.cmd’ file. Optional: cwebp.exe – Google’s WebP encoder (recommended for best compression) High-Level Workflow Audit your Images folder to see what’s there, what’s convertible, and rough space savings. Build the precache (WebP/JPEG thumbnails) into Images\_Precache. Optionally Backfill any missing precache items later. When you’re ready, Activate Precache to park originals and swap junctions. If needed, Restore Originals to go back to a vanilla LaunchBox setup. Optionally Rebuild existing precache with a different compression profile later. Important Notes Up Front Close LaunchBox and Big Box before running: Especially for [2] Activate Precache and [3] Restore Originals. If LB/BB is open, some folders/files will be locked and skipped. Back up first. Make a backup or snapshot of your LaunchBox folder for safety sake in case of program hangs or crashes, especially Images and Data. The tool never edits your games metadata except when you explicitly use [4] Clean XML references, which only removes references to images that have already been moved to _BadImages. Why the folder/file counts won’t always match You may notice differences between: A simple count script like: # Example .\Count-LBImages.ps1 -Root 'H:\LaunchBox\Images' vs. What the engine prints as it runs, e.g.: [scan] visited 384,000 dirs, collected 967,295 files... [scan] files matched so far: 1,080,000 This is expected. A few reasons: The engine sees more than “just real folders”: It scans ImagesRoot plus any junction-based views (_LBTemp\_view) that the Manager may create. It can see _Precache and _Originals paths (depending on mode) which effectively double-count logical folders while you’re mid-migration. The engine’s progress messages show: visited X dirs – directories walked (including junction targets, _Precache, _Originals, etc.) files matched so far: N – candidate image files (png/jpg/webp/bmp/gif/jfif/tif/tiff) matching filters and category rules. Your standalone count script usually: Ignores _Precache, _Originals, and “internal” engine folders. Counts only “real” directories, once. So it’s normal to see: Count script: ~331k folders, ~2.35M image files Engine progress: 300k+ dirs, 1M+ candidate images (or more) as it walks junctions, parked originals, etc. Don’t panic if the numbers don’t line up perfectly, especially after multiple runs 😊. Handling Locked Folders / “File in use” Errors When you run [2] Activate Precache, you may see messages like: Move-Item : The process cannot access the file because it is being used by another process. ...or LOCKED folder skipped during Activate: H:\LaunchBox\Images\SomeFolder (The process cannot access the file because it is being used by another process) What it means: LaunchBox, Big Box, Explorer, or antivirus has something open in that folder. The script: Logs a message in the log file (if LogPath is configured). Prints a yellow warning to the console. Continues with the rest of the folders (it doesn’t abort the whole run). Action: Make sure LaunchBox/Big Box are closed. Try again if you want those few locked folders to be fully parked/junctioned. It’s safe to re-run [2] Activate Precache; any already-parked/junctioned folders will be detected and handled. Installation Extract the zip in a folder of your choice (e.g. Desktop, tools folder, etc.) Run ‘Launch-LPM.cmd’ as Administrator (recommended for junctions & Defender toggles). The script will ask for: Your LaunchBox root (e.g. H:\LaunchBox) Whether to use a junction-based “view” (_LBTemp\_view) for faster category-limited runs Defender exclusion options, etc. (depending on the version; see below) Important: Make sure LaunchBox and Big Box are closed before running any options, especially [2] Activate Precache and [3] Restore Originals. Open instances can lock folders and cause them to be skipped. Logs: LPM writes its own log file alongside the scripts (and the engine can also log there when LogPath is enabled). If you run into issues, this log is the first place to look for details about locked folders, skipped files, and any unexpected errors. Usage Strategies (A, B, C) Because .webp isn’t accepted by LaunchBox as a source art format (you can’t drag a .webp into the UI), this tool is designed to keep your originals intact while the precache handles display. Windows can natively handle .webp files, Launchbox will see these images and show them as expected. A) Recommended (Hybrid) – Use precache for speed, keep originals for editing Original PNG/JPG art stays where LaunchBox expects it. Precache WebP/JPEG lives in Images\_Precache. You use [2] Activate Precache to junction-swap platform/image folders to the precache version. LaunchBox still “thinks” it’s looking at the original paths, but most data comes from the compressed precache. B) Aggressive – Rely mostly on precache Similar to A, but you may eventually: Move rarely used originals off to cold storage. Rely on precache for daily use. You’ll have less flexibility editing art directly, but more space savings. C) Minimalistic – Precise, platform-by-platform use Use Include Scopes / views to limit processing (e.g. only logos, only fanart, only a specific platform). Use the per-platform / per-folder workflows (planned/optional) to rebuild or tune precache only for new systems you add. Great if you periodically add one or two platforms and don’t want to re-scan the entire Images tree every time. LaunchBox still needs PNG/JPG in the right places for manual drag-and-drop or future scraping. LPM is about precache and mapping, not changing what formats LB itself supports. Clear Logos & transparency (PNG strongly recommended) LaunchBox relies on transparency for Clear Logos, so PNG is the preferred source format for all Clear Logo artwork. JPEGs don’t support alpha transparency and will usually produce ugly borders or halos in themes. LPM will still precache Clear Logos regardless of their source format, but for the best visual results in LaunchBox / Big Box you should: Use .png as the source format for all Clear Logos where possible Gradually replace any non-PNG Clear Logos if you notice rough edges or artifacts in your themes. Main Menu (Manager) – Options Explained When you run ‘Launch-LPM.cmd’, you’ll see something like: Main Menu [0] Audit images (recommended first step) [1] Build Thumbnails [2] Activate Precache (junction swap) [3] Restore Originals [4] Clean XML references [5] Backfill missing precache from Images [6] Rebuild existing precache at new profile [7] Exit [0] Audit images (recommended first step) What it does: Walks your Images tree and: Counts total images and folders (within the current view/scope). Estimates how many files are convertible to precache format. Estimates total GB you could save at each profile (Fast/Balanced/Extreme). Identifies problematic images (e.g. corrupt / unreadable) and can move them into _BadImages. What you see: A summary: Audit scope: i.e. 4,767,948 images Convertible originals: i.e. 995,899 files (~450.43 GB), potential extra savings up to ~201.65 GB if fully converted. Planning hints that look like: Profile Extreme: rough full-library runtime ~3h 48m; estimated recoverable space ~201.65 GB. Extreme is slower but aims to get close to the full estimated savings. Consider Balanced if you want a shorter run with most of the benefit. Note: These savings estimates assume you’re starting from mostly-original PNG/JPG sources. If you’ve already run Balanced/Extreme once, future runs will show the same maximum potential but the actual number of new conversions will be much lower, because many candidates are already in _Precache. [1] Build Thumbnails This is where you actually create or update the precache. When you pick [1] Build Thumbnails, you’ll be prompted: [0] Fast [1] Balanced [2] Extreme [3] Custom Select speed/quality preset [default 1]: Presets Fast (0) Highest quality, least compression, fastest run. Good if you want a mild size reduction without going all-in. Balanced (1) – Recommended first run Good compromise between quality and size. Suited for general use on large libraries. Extreme (2) Smaller files, slower run. More aggressive quality/compression settings. Paired with extra logic to avoid re-compressing files that are already “good enough” in future runs. Custom (3) Choosing [3] Custom lets you fine-tune: Baseline profile: Custom profile: [0] Fast [1] Balanced [2] Extreme Select profile [0..2] (default 1): JPEG / WebP behavior: Force JPEG only? y/N: JPEG quality [1..100] (85): If you answer y to “Force JPEG only?”, it won’t write WebP even if cwebp.exe is present. The JPEG quality value lets you sharpen/soften compression. Audit Planning Hints After you choose your options, you’ll see the same audit planning hints again so you remember the estimated runtime and GB savings. When you confirm, the engine will: Walk the configured ImagesRoot (or _LBTemp\_view if you’re using that). Classify images by category (logos, box art, fanart, screenshots, discs, marquees, etc.). Create scaled compressed copies under Images\_Precache following the same folder structure. Respect BatchSize as max new conversions this run (you can run multiple smaller batches if you prefer). [2] Activate Precache (junction swap) This is the “turn it on” step. What it does: For each folder under ImagesRoot that has a corresponding precache folder under _Precache: Moves the original folder into Images\_Originals\<same path>. Creates a junction at the original location pointing to the precache folder. Result: LaunchBox still sees the same folder paths (e.g. Images\Nintendo Entertainment System\Clear Logo), But the data actually comes from Images\_Precache\Nintendo Entertainment System\Clear Logo. Important: LaunchBox / Big Box should be closed when you run this. Locked folders are: Logged as LOCKED folder skipped during Activate: ... Left untouched; the rest of the swap continues. If anything goes weird, you can always use [3] Restore Originals to go back. [3] Restore Originals This undoes [2] Activate Precache. What it does: Finds any junctions created under ImagesRoot. Removes the junction. Moves the parked folder back from Images\_Originals to its original location. You’re back to a standard LaunchBox Images tree, no junctions, no precache swap. Again, best to have LB/BB closed while doing this. [4] Clean XML references Advanced / optional. What it does: Looks in _BadImages for any files the engine has tagged as invalid or problematic. Walks your LaunchBox\Data XML files. Removes XML nodes that reference those bad images. Saves cleaned XML. This is mainly for housekeeping when you’ve got a lot of broken image references. [5] Backfill missing precache from Images This is for catching up after partial runs or after you add more content. Scenarios: You ran Balanced/Extreme once, but only in a partial scope (a few platforms). You added new platforms or media packs later. You have a precache built from an earlier run and want to fill in missing entries. What it does: Scans your existing precache and originals. Finds original images that have no corresponding precache file yet. Creates precache copies only for those. It uses the same sizing and category logic as [1] Build Thumbnails, but only for missing entries, so it’s usually much faster than a full rebuild. [6] Rebuild existing precache at new profile This is a tuning / refinement pass. Example use cases: You originally ran Balanced, then decide you want tighter compression (Extreme) to claw back a few dozen extra GB. You tweak JPEG/WebP quality settings and want your existing precache to reflect that, but you don’t want to start from scratch. What it does: Walks _Precache and finds existing .webp / .jpg files. For each, tries to find the original in: Images\_Originals\... (preferred), or Images\... if _Originals isn’t present. Re-encodes to a temp file using the current profile settings. Only replaces the existing precache file if: The new file is at least a small percentage smaller (e.g. >2% smaller), or The existing file has non-positive size. It respects BatchSize as maximum replacements this run, so you can nibble away at a very large library in chunks instead of doing everything at once. You’ll get a summary like: RebuildPrecache complete. Pairs=150,000, rebuilt=42,000, kept=108,000, skipped=... extra savings ~12.34 GB. Elapsed 1:23:45 [7] Exit Just exits the Manager. Per-Question / Prompt Behavior (What It’s Asking You) Throughout the menus, you’ll see questions like: LaunchBox root folder? Path to your LaunchBox install, e.g. H:\LaunchBox. Used as the base for Images, Data, and _Precache. Use junction-based view? (_LBTemp\_view) If you say yes, the Manager can create a filtered/junction-based view of your Images tree to: Focus on limited scopes (e.g., only some platforms or categories). Avoid walking the entire tree every time. Disable Defender / re-enable Defender? Optional optimization: temporarily disable real-time scanning on LaunchBox image paths for the duration of the run and restore it afterward. Helps performance on huge runs. Profile selection (Fast / Balanced / Extreme / Custom) Controls the trade-off between quality, speed, and size. Force JPEG only? (y/N) If y, skips WebP entirely and sticks to JPEG (useful if you prefer JPEG everywhere). JPEG quality [1..100] Higher = larger files, better quality. Lower = smaller files, more aggressive compression. Feel free to create your own LaunchBox Images / Data folder backups before large first-time runs on production setups if you're unsure. Long runs on external USB drives can take many hours; that’s normal with multi-million-image libraries. Once you’re happy and have run Launchbox / Bigbox a few times, you can manually delete (or move them to a thumb drive or somewhere else) your ‘_Originals’ folder (where all your original image files have been moved to) to reclaim the space on your computer. There isn’t a menu item to do that, this should be done only after you’re happy with the results. If you’d like this option to be added to the manager, let me know. If you like this and want to help me out, buy me a coffee! https://buymeacoffee.com/mcflylpm LPM Readme (.DOCX).zip Submitter -McFly- Submitted 11/22/2025 Category Third-party Apps and Plugins  
  4. Version 0.28_Beta

    19 downloads

    LaunchBox Precache Manager (LPM) Mass image optimizer + junction-based precache system for LaunchBox libraries. TL;DR This tool scans your LaunchBox Images folder, builds a compressed WebP/JPEG precache into Images\_Precache, and then (optionally) swaps your original image folders for the precache using NTFS junctions. You keep your original art safe in Images\_Originals, LaunchBox gets faster scrolling and lower disk usage, and you can restore the originals at any time. If you’ve got a large LaunchBox setup with hundreds of thousands or millions of images (fanart, box art, logos, screenshots, etc.), this toolset is designed to: Build a highly compressed WebP/JPEG thumbnail “precache” for almost everything Keep your original artwork safe (in a parked folder) Swap in the precache folders via NTFS junctions Speed up scrolling and reduce SSD usage, while keeping LaunchBox itself happy It’s built for libraries in the millions of files range and tested against real-world installs with very large Images trees. This package contains two main scripts: LB-Precache-Manager.ps1 – interactive front-end menu Build-LaunchBox-Thumbnails-Parallel.ps1 – the “engine” that does all the heavy lifting The manager itself is run by launching the separate ‘Launch-LPM.cmd’ file. Optional: cwebp.exe – Google’s WebP encoder (recommended for best compression) High-Level Workflow Audit your Images folder to see what’s there, what’s convertible, and rough space savings. Build the precache (WebP/JPEG thumbnails) into Images\_Precache. Optionally Backfill any missing precache items later. When you’re ready, Activate Precache to park originals and swap junctions. If needed, Restore Originals to go back to a vanilla LaunchBox setup. Optionally Rebuild existing precache with a different compression profile later. Important Notes Up Front Close LaunchBox and Big Box before running: Especially for [2] Activate Precache and [3] Restore Originals. If LB/BB is open, some folders/files will be locked and skipped. Back up first. Make a backup or snapshot of your LaunchBox folder for safety sake in case of program hangs or crashes, especially Images and Data. The tool never edits your games metadata except when you explicitly use [4] Clean XML references, which only removes references to images that have already been moved to _BadImages. Why the folder/file counts won’t always match You may notice differences between: A simple count script like: # Example .\Count-LBImages.ps1 -Root 'H:\LaunchBox\Images' vs. What the engine prints as it runs, e.g.: [scan] visited 384,000 dirs, collected 967,295 files... [scan] files matched so far: 1,080,000 This is expected. A few reasons: The engine sees more than “just real folders”: It scans ImagesRoot plus any junction-based views (_LBTemp\_view) that the Manager may create. It can see _Precache and _Originals paths (depending on mode) which effectively double-count logical folders while you’re mid-migration. The engine’s progress messages show: visited X dirs – directories walked (including junction targets, _Precache, _Originals, etc.) files matched so far: N – candidate image files (png/jpg/webp/bmp/gif/jfif/tif/tiff) matching filters and category rules. Your standalone count script usually: Ignores _Precache, _Originals, and “internal” engine folders. Counts only “real” directories, once. So it’s normal to see: Count script: ~331k folders, ~2.35M image files Engine progress: 300k+ dirs, 1M+ candidate images (or more) as it walks junctions, parked originals, etc. Don’t panic if the numbers don’t line up perfectly, especially after multiple runs 😊. Handling Locked Folders / “File in use” Errors When you run [2] Activate Precache, you may see messages like: Move-Item : The process cannot access the file because it is being used by another process. ...or LOCKED folder skipped during Activate: H:\LaunchBox\Images\SomeFolder (The process cannot access the file because it is being used by another process) What it means: LaunchBox, Big Box, Explorer, or antivirus has something open in that folder. The script: Logs a message in the log file (if LogPath is configured). Prints a yellow warning to the console. Continues with the rest of the folders (it doesn’t abort the whole run). Action: Make sure LaunchBox/Big Box are closed. Try again if you want those few locked folders to be fully parked/junctioned. It’s safe to re-run [2] Activate Precache; any already-parked/junctioned folders will be detected and handled. Installation Extract the zip in a folder of your choice (e.g. Desktop, tools folder, etc.) Run ‘Launch-LPM.cmd’ as Administrator (recommended for junctions & Defender toggles). The script will ask for: Your LaunchBox root (e.g. H:\LaunchBox) Whether to use a junction-based “view” (_LBTemp\_view) for faster category-limited runs Defender exclusion options, etc. (depending on the version; see below) Important: Make sure LaunchBox and Big Box are closed before running any options, especially [2] Activate Precache and [3] Restore Originals. Open instances can lock folders and cause them to be skipped. Logs: LPM writes its own log file alongside the scripts (and the engine can also log there when LogPath is enabled). If you run into issues, this log is the first place to look for details about locked folders, skipped files, and any unexpected errors. Usage Strategies (A, B, C) Because .webp isn’t accepted by LaunchBox as a source art format (you can’t drag a .webp into the UI), this tool is designed to keep your originals intact while the precache handles display. Windows can natively handle .webp files, Launchbox will see these images and show them as expected. A) Recommended (Hybrid) – Use precache for speed, keep originals for editing Original PNG/JPG art stays where LaunchBox expects it. Precache WebP/JPEG lives in Images\_Precache. You use [2] Activate Precache to junction-swap platform/image folders to the precache version. LaunchBox still “thinks” it’s looking at the original paths, but most data comes from the compressed precache. B) Aggressive – Rely mostly on precache Similar to A, but you may eventually: Move rarely used originals off to cold storage. Rely on precache for daily use. You’ll have less flexibility editing art directly, but more space savings. C) Minimalistic – Precise, platform-by-platform use Use Include Scopes / views to limit processing (e.g. only logos, only fanart, only a specific platform). Use the per-platform / per-folder workflows (planned/optional) to rebuild or tune precache only for new systems you add. Great if you periodically add one or two platforms and don’t want to re-scan the entire Images tree every time. LaunchBox still needs PNG/JPG in the right places for manual drag-and-drop or future scraping. LPM is about precache and mapping, not changing what formats LB itself supports. Clear Logos & transparency (PNG strongly recommended) LaunchBox relies on transparency for Clear Logos, so PNG is the preferred source format for all Clear Logo artwork. JPEGs don’t support alpha transparency and will usually produce ugly borders or halos in themes. LPM will still precache Clear Logos regardless of their source format, but for the best visual results in LaunchBox / Big Box you should: Use .png as the source format for all Clear Logos where possible Gradually replace any non-PNG Clear Logos if you notice rough edges or artifacts in your themes. Main Menu (Manager) – Options Explained When you run ‘Launch-LPM.cmd’, you’ll see something like: Main Menu [0] Audit images (recommended first step) [1] Build Thumbnails [2] Activate Precache (junction swap) [3] Restore Originals [4] Clean XML references [5] Backfill missing precache from Images [6] Rebuild existing precache at new profile [7] Exit [0] Audit images (recommended first step) What it does: Walks your Images tree and: Counts total images and folders (within the current view/scope). Estimates how many files are convertible to precache format. Estimates total GB you could save at each profile (Fast/Balanced/Extreme). Identifies problematic images (e.g. corrupt / unreadable) and can move them into _BadImages. What you see: A summary: Audit scope: i.e. 4,767,948 images Convertible originals: i.e. 995,899 files (~450.43 GB), potential extra savings up to ~201.65 GB if fully converted. Planning hints that look like: Profile Extreme: rough full-library runtime ~3h 48m; estimated recoverable space ~201.65 GB. Extreme is slower but aims to get close to the full estimated savings. Consider Balanced if you want a shorter run with most of the benefit. Note: These savings estimates assume you’re starting from mostly-original PNG/JPG sources. If you’ve already run Balanced/Extreme once, future runs will show the same maximum potential but the actual number of new conversions will be much lower, because many candidates are already in _Precache. [1] Build Thumbnails This is where you actually create or update the precache. When you pick [1] Build Thumbnails, you’ll be prompted: [0] Fast [1] Balanced [2] Extreme [3] Custom Select speed/quality preset [default 1]: Presets Fast (0) Highest quality, least compression, fastest run. Good if you want a mild size reduction without going all-in. Balanced (1) – Recommended first run Good compromise between quality and size. Suited for general use on large libraries. Extreme (2) Smaller files, slower run. More aggressive quality/compression settings. Paired with extra logic to avoid re-compressing files that are already “good enough” in future runs. Custom (3) Choosing [3] Custom lets you fine-tune: Baseline profile: Custom profile: [0] Fast [1] Balanced [2] Extreme Select profile [0..2] (default 1): JPEG / WebP behavior: Force JPEG only? y/N: JPEG quality [1..100] (85): If you answer y to “Force JPEG only?”, it won’t write WebP even if cwebp.exe is present. The JPEG quality value lets you sharpen/soften compression. Audit Planning Hints After you choose your options, you’ll see the same audit planning hints again so you remember the estimated runtime and GB savings. When you confirm, the engine will: Walk the configured ImagesRoot (or _LBTemp\_view if you’re using that). Classify images by category (logos, box art, fanart, screenshots, discs, marquees, etc.). Create scaled compressed copies under Images\_Precache following the same folder structure. Respect BatchSize as max new conversions this run (you can run multiple smaller batches if you prefer). [2] Activate Precache (junction swap) This is the “turn it on” step. What it does: For each folder under ImagesRoot that has a corresponding precache folder under _Precache: Moves the original folder into Images\_Originals\<same path>. Creates a junction at the original location pointing to the precache folder. Result: LaunchBox still sees the same folder paths (e.g. Images\Nintendo Entertainment System\Clear Logo), But the data actually comes from Images\_Precache\Nintendo Entertainment System\Clear Logo. Important: LaunchBox / Big Box should be closed when you run this. Locked folders are: Logged as LOCKED folder skipped during Activate: ... Left untouched; the rest of the swap continues. If anything goes weird, you can always use [3] Restore Originals to go back. [3] Restore Originals This undoes [2] Activate Precache. What it does: Finds any junctions created under ImagesRoot. Removes the junction. Moves the parked folder back from Images\_Originals to its original location. You’re back to a standard LaunchBox Images tree, no junctions, no precache swap. Again, best to have LB/BB closed while doing this. [4] Clean XML references Advanced / optional. What it does: Looks in _BadImages for any files the engine has tagged as invalid or problematic. Walks your LaunchBox\Data XML files. Removes XML nodes that reference those bad images. Saves cleaned XML. This is mainly for housekeeping when you’ve got a lot of broken image references. [5] Backfill missing precache from Images This is for catching up after partial runs or after you add more content. Scenarios: You ran Balanced/Extreme once, but only in a partial scope (a few platforms). You added new platforms or media packs later. You have a precache built from an earlier run and want to fill in missing entries. What it does: Scans your existing precache and originals. Finds original images that have no corresponding precache file yet. Creates precache copies only for those. It uses the same sizing and category logic as [1] Build Thumbnails, but only for missing entries, so it’s usually much faster than a full rebuild. [6] Rebuild existing precache at new profile This is a tuning / refinement pass. Example use cases: You originally ran Balanced, then decide you want tighter compression (Extreme) to claw back a few dozen extra GB. You tweak JPEG/WebP quality settings and want your existing precache to reflect that, but you don’t want to start from scratch. What it does: Walks _Precache and finds existing .webp / .jpg files. For each, tries to find the original in: Images\_Originals\... (preferred), or Images\... if _Originals isn’t present. Re-encodes to a temp file using the current profile settings. Only replaces the existing precache file if: The new file is at least a small percentage smaller (e.g. >2% smaller), or The existing file has non-positive size. It respects BatchSize as maximum replacements this run, so you can nibble away at a very large library in chunks instead of doing everything at once. You’ll get a summary like: RebuildPrecache complete. Pairs=150,000, rebuilt=42,000, kept=108,000, skipped=... extra savings ~12.34 GB. Elapsed 1:23:45 [7] Exit Just exits the Manager. Per-Question / Prompt Behavior (What It’s Asking You) Throughout the menus, you’ll see questions like: LaunchBox root folder? Path to your LaunchBox install, e.g. H:\LaunchBox. Used as the base for Images, Data, and _Precache. Use junction-based view? (_LBTemp\_view) If you say yes, the Manager can create a filtered/junction-based view of your Images tree to: Focus on limited scopes (e.g., only some platforms or categories). Avoid walking the entire tree every time. Disable Defender / re-enable Defender? Optional optimization: temporarily disable real-time scanning on LaunchBox image paths for the duration of the run and restore it afterward. Helps performance on huge runs. Profile selection (Fast / Balanced / Extreme / Custom) Controls the trade-off between quality, speed, and size. Force JPEG only? (y/N) If y, skips WebP entirely and sticks to JPEG (useful if you prefer JPEG everywhere). JPEG quality [1..100] Higher = larger files, better quality. Lower = smaller files, more aggressive compression. Feel free to create your own LaunchBox Images / Data folder backups before large first-time runs on production setups if you're unsure. Long runs on external USB drives can take many hours; that’s normal with multi-million-image libraries. Once you’re happy and have run Launchbox / Bigbox a few times, you can manually delete (or move them to a thumb drive or somewhere else) your ‘_Originals’ folder (where all your original image files have been moved to) to reclaim the space on your computer. There isn’t a menu item to do that, this should be done only after you’re happy with the results. If you’d like this option to be added to the manager, let me know. If you like this and want to help me out, buy me a coffee! https://buymeacoffee.com/mcflylpm LPM Readme (.DOCX).zip
  5. The archive has a new manager - Thanks everyone for your DM's.
  6. This archive needed someone like Hayato to take it over and do it justice, someone who can drill deeper into it that I ever did. I'm looking forward to seeing the work he does for the community.
  7. Many are incomplete due to them simply being missing from the web. Some games become available or found by people and ripped for everyone, some are incomplete due to bad rips, etc. The archiving should have started about 30 years ago when everything was new and available, but here we are.
  8. yes, i started there and gave up due to all the failures with uploading that way.
  9. All my files are there, uploading and downloading is simple and straightforward. I just don't have time for all the questions and requests.
  10. My repo is up for grabs to anyone who wants to take it over - 

     

  11. I'm giving up the entire repository that used to be at snaapgames.com as I don't have the time to manage it anymore. If you know what this is and are interested in taking it over, let me know. If you're not sure what this is; it's a MEGA site I used to upload my entire collection for archiving purposes. My goal was to keep everything available forever for anyone interested in preserving our collections, but the time I've had to give this has been far more than I anticipated and I just don't have the bandwidth anymore due to professional and personal reasons. It's currently sitting at 26TB and costs around $90 per month, payable on the 15th. ASparky was interested in taking this over but I haven't heard from him in a couple of months, so I'm opening it up to everyone. This is NOT FOR SALE - there is a monthly cost for this that will be payable to MEGA, not to me. There is / was a website associated with this and an email address. At a minimum I'll need an email address from whoever takes it over to forward messages to. I was asking for donations to help cover the monthly MEGA fees, you may need a website if you choose a similar path. Reach out to me via DM is interested. If no-one takes this over, it'll be cancelled before November 15th 2025 and gone forever.
  12. Hi everyone. I don't have the time to continue it so I'm closing the MEGA repository in 2 weeks on September 30th 2025. If anyone wants to take it over, PM me and we can discuss as there are several things that need to be done before the handover can happen, specifically email, web and banking back-end stuff. If anyone is interested in taking it over there are costs involved with hosting the repo. Thanks to everyone who grabbed what they could while they could, sorry it wasn't forever. I may make this its own post, I'll just put this here for now. Asparky - if you're still interested, let me know.
  13. I'm not using this, but it might be useful to you? https://nytric.com/clients-zapit-games/ I have several systems that don't have working emulators yet, I have everything queued up for when they arrive and work well.
  14. 1.2M titles, but they're not all strictly games. I've included cheats, videos and manuals as well so... probably about 800-900k games maybe? I haven't got a lot of the 'bigger' games like XBOX, Playstation etc. so my total storage is around 30+TB. 60TB is a lot of space for less than 100k games, I'm guessing you've chosen more recent systems?
  15. These .xml files only has the Metadata for each game... title, gameid's, details, etc. There are no game files in the playlists. These .xml files get built / updated by LB when you import your own games. My .xml files show all the games in the .xml files inside MY LB & BB, they are basically a shortcut for you if you already have all the games on your system already. Any games you don't have simply won't open when ran inside LB or BB as they're not there. You don't need these .xml files if you intend to run the importer yourself - I've simply added them here as a reference if you are looking for more titles to add to your own collection.
  16. Thanks for this! I have over 1000 playlists already, I could do all the ones you suggest, but someone will suggest others and someone else will suggest even more... I've reached a limit I'm happy with. Anyone can create playlists in Launchbox and upload them to these forums, you could help the community by doing these yourself?
  17. I tried, no luck. I have everything online as a backup but I'm not allowed to give any information about it here.
×
×
  • Create New...