C-Beats

You will want to open Windows Event Viewer and look in the application logs for two errors next to each other that point to LaunchBox crashing. One log will be a generic ".NET stopped working..." sorta thing and the other will give actual details (I believe it to be the top most log by default). That log should give a hint as to what's failing. If you could paste it here or attach a screenshot of it we can go from there. Also if you haven't tried run the installer again over the same location (making sure it doesn't try creating a LaunchBox folder IN your LaunchBox folder) and try again. Sometimes AV applications quarantine files that cause issues like that.

What sidebar filter are you on when starting?

Unfortunately the best way is to just put the old folder back and start adding underscores to folder names to hide them from LB and see where the issue appears. Most of the time I've heard this it's because of older malformed images tied to MAME games gotten from EmuMovies, I believe they've since been removed but if you haven't updated your media in a while it could potentially be the case. Does the error occur after selecting a specific game? With where this stack trace is showing I'd have assume it occurred when selecting a game, I'd just start with that game and remove the images to see if it fixes it, then potentially rescrape media on the platform that game is in.

As stated, this is almost always an image file that is corrupted and NOT a hard drive issue. You can prove the theory by renaming your Images folder to _Images (with the app closed) and then open LaunchBox and see if you still run into the same issue.

No, there's no process in LaunchBox that would overwrite that database ID association. Once it's set it stays set that way.

Right now the database is undergoing a process where we are adding SteamIds to games. Currently LaunchBox will not attempt to match games without a SteamID associated to them in the database. You can tell these pages because the pages WITH the association has a link to the game's Steam page. Right now the only work around is to manually go to a game and edit it. Once the window comes up, cut out the app path and then go to the metadata tab. Press search in the upper right and it'll find the game page. Then click on it to associate the game. Then go back to the launching page and paste the app path back in and press OK to save the changes. We realize this is FAR from ideal and are working hard to get the database changes completed.

Yeah, they've all came in at different times in the app so the uses they were put in for are all slightly different. I could see it being a tad less confusing if we could have a single location for all that stuff. Something to think about moving forward.

I looked into the code and have discovered we only do the unzip process for .7z files since the hasher can never consume those directly. We DON'T for zip files. I'll look into the code to see how best to address this since we'd need to ensure we only did that for disc based games.

We've put in several code changes to address that issue, I haven't seen it reported in a long while so was under the impression it was taken care of. Just to help ensure it's the same thing we've seen in the past can you hop to grid view, then back to list view and let me know if that makes the headers appear again?

Go to Tools > Options and then within that go to Data > Search. Should see something similar to the attached. That bottom most number drives how many votes a game needs to have before we count the community star rating. Make sure it's not higher than you expected. I believe the default is 5, I tend to enjoy it being higher in my collections.

Fairly certain that we are. We extract them to our temp directory (\\LaunchBox\Metadata\Temp) and then run the hasher against it. I'll review the code and let you know for certain.

Tools > File Management > Scan for removed roms

None of that changed for us, but gives me something to vet against. Thanks for the additional information, much appreciated.

No, I'm saying you'd alter the Version information on your games to adhere to the multi-value rule of "different values are separated by semicolons". You don't need to touch filenames at all for much of anything in LaunchBox outside of initial scraping/detection.

This is only cleared by the app when we update the hasher application we package with. Otherwise the result wouldn't change. Only other time this is cleared is when you change the app path of a game.

It is, but as you stated it's not the path you're going down. Right now it to work the way you're hoping it'd be work you'd need to split the values in parens with a semicolon, or we'd need to implement a "Doesn't Contain Any of the Values" sorta rule that would check if the strings were there at all or not (which I could see getting REALLY confusing alongside the "Has None of the Values" type).

I've never used EmuDeck to really know where all it sticks things and how nasty it'd be to do something like that. You MAY be able to symlink folders to make that happen but it isn't something I do well enough to say whether or not that'd definitely work.

For now, we have this corrected internally and are waiting to see if any other critical bugs are found before releasing a correction.

There is a community plugin to add things to Steam, but I'm not entirely sure how it compares to Steam Rom Manager as I use neither. You can use LaunchBox and point it to the emulators EmuDeck installed for you though.

Or the save event on the image got botched while downloading it, or something altered the file that shouldn't have. You can run test on the drive, but a failing drive isn't always the cause for something like that.

Right now the intention is that back from Game Discovery always returns you to System Menu

Version isn't typically a multi-string field so I'd have to look into the code to verify. If you version is "(USA) (Rev1)" (without quotes) and you say "None of the values - (USA)" it wouldn't fire on that because that is a single value. Multiple values need to be separated by a semicolon, so the games version would need to be "(USA);(Rev1)" which it typically isn't.

Only time I've seen this error occur is with a corrupted image file. The file is malformed and throws the error when trying to read it. I've jotted this down so I can at the very least look into a way to make the program fail silently when this happens.

Not at this time.

That is a plugin, and the plugin dev can set whether they show while locked or not. The dev would have to change that property and then recompile/rerelease the plugin for that to happen.