Gaming.Zone

🧠 Beta Spotlight Feedback – Suggestions for Improving the Experience First off, I wanted to say thank you for implementing the Beta Spotlight window feature. I think we had a conversation about this idea only last week, and it’s great to see it make its way into the beta so quickly. It’s a fantastic addition that helps testers understand what’s new, where to focus, and how to provide meaningful feedback. After reviewing the new 13.25 beta 1 rollout and the Spotlight window, I wanted to share a few ideas for refining it further and making it even more intuitive for a broad range of testers—especially those who may not think like developers or QA professionals. 💡 Suggested Improvements Display the Beta Version Number Include the current beta version number directly in the Beta Spotlight modal window (e.g., “LaunchBox 13.25 Beta 1” at the top). This helps testers quickly confirm which build they’re testing when reporting findings or referencing specific behavior. Refine the Layout – Split into Two Clear Sections Top Section: “Welcome to the Beta” – a brief overview, general testing guidelines, and instructions on how to provide feedback. Bottom Section: When future betas release, consider adding a tabbed layout, where each tab corresponds to a specific beta version (e.g., 13.25b1, 13.25b2, etc.). Each tab could contain: New Features Improvements Fixes / Performance Updates Areas Where Feedback Is Most Helpful Why Version Tabs Matter Having separate tabs per beta helps users correlate when certain changes were introduced. For example, if a user joins the beta program at beta 4 and something behaves differently than expected, they might not realize that behavior changed back in beta 3. With a per-version tab structure, testers can look back through previous beta notes and quickly identify when a feature or behavior changed, reducing confusion and improving the quality of feedback provided. Clarify the Testing Language The current “What We’d Love You to Test” phrasing is friendly but might sound a bit directive to some users. Suggestion: Reframe it as “Areas Where Feedback Is Most Helpful” or “Things You Can Help Us Test” to emphasize collaboration rather than obligation. Add a Section for Feedback Guidance Many users may not know what kind of details the team needs when submitting reports. Adding a brief “How to Give Useful Feedback” section could help, with examples like: Steps to reproduce Expected vs. actual results Platform or theme in use Screenshots or logs (if applicable) Future Consideration – Access to Previous Betas It might be valuable to give advanced testers the option to download older beta versions for testing or comparison. For instance, if a tester is on beta 4, they could choose to download and install beta 2 in a separate directory to verify when a change occurred. This would be a useful tool for seasoned beta users who want to perform regression testing or isolate when a specific bug or change was introduced. If implemented, it would be important to include a clear note reminding users not to install an older beta over their current one in the same folder, to avoid version conflicts or data corruption. 🧩 Overall Impression The new Beta Spotlight feature is a major step forward in structured testing and communication. It provides clarity, direction, and a stronger feedback loop between the community and development. With a few layout refinements and some added context around version tracking, it could become an even more powerful tool for guiding testers and gathering high-quality, actionable feedback.

If you notice any errors, keep in mind that the LaunchBox Games Database is community-driven. You can click the database link, review the record, and make any necessary corrections — once submitted, your changes will go through review and then be updated in the database. Also, remember that not everyone using the application is an English speaker. Sometimes information is entered incorrectly, not out of malice, but simply due to translation issues or misunderstandings. New entries can also have small mistakes from people rapidly populating data or “fat-fingering” fields. Every record starts out new at some point, and the community helps refine it over time. So if you spot something wrong, please help us out by submitting corrections. Every fix improves the database for everyone!

I just wanted to add that the name of the ROM file doesn’t matter at all. I prefer to name my files a certain way locally, and they still match without any issues. As @C-Beats mentioned, LaunchBox compares the file hash against the RetroAchievements database, not the filename itself. I’ve also noticed that when a game is actively being updated or rebuilt on RetroAchievements — for example, when new sets of achievements are being added — a title that previously showed achievements can temporarily lose them. It’s rare, but it does happen. One example I ran into was a ROM that originally matched a No-Intro release, then later switched to the TOSEC version, and eventually ended up being recognized only in the Lost Levels archive (which curates ROMs not included in standard DAT groups). In cases like this, the RetroAchievements coverage can shift as the curators refine which ROMs are supported.

It looks like the issue is resolved. Emumovies has restarted the API service.

It looks like the EmuMovies API is currently unresponsive. Outages like this can happen for a few reasons — from a bad code deployment or memory leak to malformed requests or an overloaded server. Since multiple users are reporting the issue, it’s most likely a server-side problem (infrastructure or deployment) rather than anything client-side in LaunchBox. Hopefully the EmuMovies team is already aware and working on a fix.

I haven’t had any more crashes. I believe the fix for me was going to Options > Visuals > Game Details and unchecking Show Videos. I can’t confirm this is the exact fix, since I also reinstalled and manually moved my data, but for my RTX 3060 and the FFMPEG issues, it seems like switching between games or returning from an edit was causing the video player display to crash my system. Hopefully, this helps others troubleshoot similar problems.

So I did a fresh install of 13.24 and then copied over all the essential folders from my old setup (Data, Images, Manuals, etc.). Since doing that, I haven’t encountered another crash. One thing I did notice, though, is that on the fresh install the 3D box art and video aren’t displayed by default on the details page — which makes me think it’s possible that with the recent FFmpeg update and my RTX 3060, disabling those elements might have helped prevent the crashes. I’ll try turning them back on to see if the issue returns. My best guess right now is that over time, as LaunchBox has changed folder structures and storage locations, my setup ended up with redundant files and invalid pointers. That could explain the instability, especially if LaunchBox was trying to access media from paths that no longer existed. It might be worth considering a more fixed directory structure going forward, or perhaps a cleanup/validation tool that checks for stale references and broken media paths, since long-term upgraded builds like mine can accumulate these issues over time. Also, for media packs and other assets downloaded through LaunchBox, I’ve noticed they currently save to the Images folder — but at one point, some themes required images to be placed inside the Theme folder instead. With all the updates and shifting locations, it’s become hard to keep track of what needs to move and when, especially when switching between different themes. A more standardized approach, or some in-app guidance when changing themes, might really help simplify things.

Thanks so much for the detailed follow-up — I really appreciate how open the team is about process and how receptive you are to feedback. Totally understand the challenge of not having a dedicated QA resource. It’s great to hear that testing is a team effort and that you’re aware of how valuable dedicated QA could be as the product grows in complexity. Even knowing that helps the community understand where and how to best contribute. The idea of a beta-specific update window inside the app is fantastic. That would go a long way toward making testing efforts more coordinated and focused — especially for people like me who jump on betas early and want to provide targeted feedback. I’ve upvoted the feature and added a note highlighting how a simple “focus areas” or “known issues” section could help testers zero in on what matters most each cycle. Thanks again for taking the time to engage on this — it’s encouraging to see such thoughtful consideration given to QA and community testing.

Thanks again for the thoughtful reply — I really appreciate the transparency around your process. I can definitely see how complex LaunchBox is to test, especially with so many combinations and integrations. Automation in this kind of desktop environment isn’t straightforward and usually requires custom tooling or dedicated engineering time, so it makes sense that your focus is on thorough manual coverage. I’m curious how QA responsibilities are currently structured on your team. Is there a dedicated QA function or individual, or is testing primarily handled by developers and project leads before release? Sometimes having a separate QA role (even part-time) helps with consistency and documentation, especially when juggling multiple test environments and regression passes. I’m on the open betas and prefer to be on the cutting edge of the release window, so I’d be happy to provide feedback. One thing that could maximize the value of community testing would be a short beta test strategy — just a couple paragraphs highlighting key areas for testers to focus on. That way feedback is more targeted and actionable, and you can catch the highest-risk issues more efficiently.

Looking at your logs and comparing them with mine, my QA brain is thinking that LaunchBox isn’t properly handling scenarios where it can’t locate or access an asset (image, font, or media). It appears that the system hits a low-level WPF imaging exception before LaunchBox’s own error handling can intercept it — which prevents any error report or graceful fallback. From the logs, I’m seeing repeated FIRST CHANCE EXCEPTION entries (for BitmapDecoder, invalid pack URIs, and locked font files), followed by a silent crash. This suggests the exception is being thrown on the UI/render thread, causing a fatal process exit before LaunchBox can catch or log it. Here are a few questions and suggestions for development: Is LaunchBox currently catching BitmapDecoder or WPF imaging exceptions during theme/media loading? Should missing or corrupt image/font resources trigger a safe fallback instead of a fatal crash? Is there a recommended way to trace which file specifically causes the failure before WPF terminates the process? This seems to have started after upgrading to 13.24, and occurs even with the Default Theme, though sometimes after a delay. It may be worth reviewing recent changes to resource handling or theme initialization.

I have decided to attempt the nuclear option and have installed a fresh install of Launchbox. Luckily I can reference my old content, and start back from there. I will Update here if I experience any crashes from this new install. If it is resolved I will use the new system as a benchmark for future updates (via backups of it to my NAS) Hoping this was a me problem and not a global issue.

Thanks for the quick follow-up! I switched over to the Default theme to get a proper baseline. Unfortunately, I’m still seeing silent crashes, even when using Default and with no theme mods applied. Here are a few key exceptions from my latest Debug.log that occur right before the crash: FIRST CHANCE EXCEPTION: System.InvalidOperationException: Cannot perform this operation while dispatcher processing is suspended. at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame) at Unbroken.LaunchBox.Windows.ViewModels.GameDetailsViewModel.Dispose() FIRST CHANCE EXCEPTION: System.IO.IOException: The process cannot access the file 'Gilroy-Bold.ttf' because it is being used by another process. FIRST CHANCE EXCEPTION: System.IO.FileNotFoundException: Could not load file or assembly 'Unbroken.LaunchBox.Windows.XmlSerializers.dll' or one of its dependencies. FIRST CHANCE EXCEPTION: System.Reflection.AmbiguousMatchException: Ambiguous match found. at System.Reflection.RuntimePropertyInfo.GetValue(Object obj, Object[] index) FIRST CHANCE EXCEPTION: System.IO.DirectoryNotFoundException: ImageSourceConverter cannot convert from System.String (pack:\application:,,,\WpfResources\Background.png) The key one seems to be the dispatcher processing suspended exception, which points to a threading/race condition during disposal (GameDetailsViewModel.Dispose). That aligns with what I’m seeing — silent crashes when navigating quickly, closing edit modals, or bulk editing. The other exceptions (font file locks, missing serializer, and ambiguous reflection) might be contributing instability, but the dispatcher issue looks like the main trigger. Next, I’m going to: Keep using the Default theme Keep using a turned off video/music autoplay, Compare behavior when navigating slowly vs rapidly to confirm if the crash is timing-related. Based on additional testing, it seems the crashes occur more frequently when navigating quickly through the UI, suggesting a possible threading or disposal race condition. (This is an assumption still)

Here’s a snippet from my LaunchBox.log around the time of the crash. It looks like LaunchBox is hitting multiple UI and binding exceptions, including: An AmbiguousMatchException in PlatformFiltersDetailsViewModel A missing theme image (Not Rated.png) causing a conversion error And a transport connection exception likely during metadata loading Full log available if needed, but this seems to point to a theme or binding issue. I’m currently using the Default Plus theme. I have debugging on now so I will continue to monitor.

Hey everyone, I wanted to start an open discussion about the quality assurance (QA) process for LaunchBox. I’ve noticed an increase in stability issues and regressions over recent versions, and I’m curious what QA practices the team currently follows to maintain product quality. A few specific questions come to mind: Is there a dedicated QA team, or is testing handled primarily by developers and community feedback? Is manual testing performed on each release, and if so, what areas are covered? Are new builds going through regression testing to validate existing functionality? Is there any level of unit testing or automated testing being done? Do you use code reviews or paired development practices before merging changes? How do you determine which environments to test on — do you vary PC specs, OS versions, or test both fresh installs and existing builds? When new features are added, is there a risk analysis done to understand their potential impact on existing functionality? From my experience working in software QA across multiple companies, the recent patterns I’m seeing suggest that the QA process for LaunchBox may be slipping or possibly very limited. Even with a small team or rapid release cycle, there are ways to keep strong QA practices in place — from lightweight test plans to structured regression passes. Community feedback is valuable, but it’s not a substitute for coordinated QA efforts that work hand-in-hand with development. Having QA involved earlier helps catch issues before they reach production and can dramatically improve stability. Another thing I’m curious about — has there been significant refactoring in recent builds? If so, that’s another strong reason to have thorough regression and comparison testing to ensure nothing breaks during those changes. Would love to hear from the LaunchBox team (and other users) about what testing practices are currently in place, and whether there’s room for improvement or community collaboration to strengthen the QA process.

Hi all, I’ve been experiencing frequent crashes in LaunchBox ever since the FFmpeg update. I’ve been working on building out my setup, but the app has become increasingly unstable — especially since the official 13.24 release. While the recent betas seemed to reduce the frequency of crashes somewhat, the final release has made them more frequent again. From a user’s perspective, the crashes seem to occur during various normal actions, but I don’t believe they’re necessarily caused by UI interactions themselves. Here are some examples of when the app has crashed (with no visible error message): Editing a game record using the pencil button → Crash Importing ROMs and clicking Next in the wizard → Crash Selecting an existing game in any platform (UI starts to refresh) → Crash Editing a game entry, making several changes or adding media, clicking OK to close the modal → Crash Performing a bulk edit on multiple records, making a change, then clicking No when asked about further edits → Crash I haven’t been capturing detailed logs or reproduction steps yet, as these have been happening during normal usage rather than intentional testing. I’m happy to provide additional details, including my PC specs, logs, or to run more structured tests if needed. If this turns out to be an edge case, I’d like to understand why so I can fix it on my side. But if others are seeing similar behavior, I’d be glad to help narrow it down collaboratively. For context, I’m a Software QA professional with 18 years of experience, so I’m familiar with structured debugging and root cause analysis. I’d be happy to coordinate with the LaunchBox QA team if that would help track down the issue. If you have any initial theories or troubleshooting steps, please let me know and I’ll try them right away. Thanks for your help!

The stability of LaunchBox-13.24-beta-1 is better for me than LaunchBox-13.23 but I am experiencing more issues with these builds then I did with any of the 13.23 beta builds. I have a Windows 11 Machine with a NVIDIA GeForce RTX 3060. Currently set to FFMPEG. I am getting a lot of complete Launchbox crashes on my machine while doing the following: 1. Manually clicking games too quickly in a Platform list. (Auto play is off for Music and Videos) 2. Editing a game from a playlist. 3. Moving from Playlist to playlist too quickly. My build is not that large at the moment. It has a NES collection and a few other smaller platforms. ~1000 games at the moment. In the Web world I would record a JAM.dev file for you and send your way. Is there anything specific I could grab to help devs diagnose. Is it possible I am experiencing echo effects of videos loading in the display window even if auto play is off? I would love to help diagnose and help this to get resolved. Please let me know what I can do to help.

I can confirm the False Positive does not occur in the 13.24 beta 1 on my machine. I did not update Windows Defender definitions yet, so my PC was still at the same state as when I installed 13.23. Just an FYI. Thanks.

I can confirm this was thrown at me as well by Microsoft Defender on Windows 11. I ran a scan after on the Launchbox folder and no other concerns found. Possible false positive? EDIT: I see the answer was posted by an admin 2 minutes before I posted that it is indeed a false positive. Thank you for the fast reply faeran.

I know Vita games can get ridiculous in size. While I am not planning out the gate to add all of the games ever made....if I ever went down this path I would want to make sure my Launchbox/bigbox size never got out of hand because the emulator folder was XTB in size. I appreciate the reply.

I am interested in adding Vita3K to my Launchbox/bigbox build. However I currently store ALL my Roms on a Network drive. Is there anyway to change the location that roms are installed in for this emulator? If not could symlinks work? Thanks in advance.

Thanks. I was under the same assumption but wanted to hear it echoed. Again the issue with being a QA is I am always looking at software in abstract ways. I appreciate the dialogue.

Thanks for the reply. I was aware that the 2 in the middle were for the SABA Videoplay in Germany. I believe that you were able to answer some of my questions, which I thank you kindly. For the example I provided I believe at some point No-Into named the file differently and this helps grab legacy versions of the rom to scrape. As far as what I was asking for about my created collection on my PC. If I have a large collection, is there benefit to add Tic-Tac-Toe Shooting Gallery Doodle Quadra-Doodle as individual Alternate names in my collection to make search parsing quicker? ...or is the fact that there are redundant items now slowing down my game search. I am asking anticipating a large collection eventually. I want to know if I am shooting my foot or if I can get some sort of search efficiency in the future by making smart changes. Thanks again.

I am curious what the intended use of Alternate Names is? Was the purpose to call out title differences by region for relational linking or is it there to actually help with finding games better for the end user? Or are Alternate names meant to help those importing in the future when in the GamesDB? Given the example of Videocart-1: Tic-Tac-Toe & Shooting Gallery & Doodle & Quadra-Doodle It has alternate names of: Tic-Tac-Toe + Shooting Gallery + Doodle + Quadra-Doodle Videocart 1: Mühle - Tontauben-Schießen - Kreatives Malspiel - Videoscope Muehle, Tontauben-Schiessen, Kreatives Malspiel, Videoscope Tic-Tac-Toe, Shooting Gallery, Doodle, Quadra-Doodle For this game is there benefit for formatting differences of the same data (ie the +) ? Asking ChatGPT it is suggesting to use Alternate Names to make searching later easier like: Tic-Tac-Toe Shooting Gallery Doodle Quadra-Doodle Is this true and would it be useful to include in my Launchbox build or is it overkill? I do software QA for a living so when I run into something like this I tend to want to learn as much as I can to understand it's true purpose as if I don't I will edge case the heck out of it and find out later I have to do re-work when development adds proper guard rails to the area. Thanks in advance.

I think I solved my own problem, but I have discovered a bug in the process. The plugin is requesting me to have the beta of launchbox. At the time I am on 13.15. It's probably a good idea to do a version check to make sure that older versions are not broken due to an upgrade requirement. I will try and upgrade my version to the most current beta, but just a heads up on what I found.

It has been a week since I launched my launhbox software. Today I was greeted with a plugin update message for retroarch. After updating from 1.1 to 1.2, it no longer is tracking the version number in the mange emulator section. Was this intentional or is there a suggested way I can fix this? Thanks for Any help.