C-Beats

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.

If yo go to Tools > Options and then the Game Details section and disable Achievements, Videos, and High Scores does the issue still persist?

You can import ROMs from any location the app can see. I don't have my Odin 2 set up the way you're describing but do/did my Odin 1 with no issues.

Currently the view isn't respecting the "Hide in Big Box" property of platforms and will be corrected in the next release. It doesn't sound like what you're referring to though.

So you're wanting the same image to be used as both? That'd require you grabbing the same file and tagging one as Advertisement Front, and the other as background. Alternatively (and what I'd recommend) is that inside of LaunchBox you go to Tools > Options and change the Background Image Priorities to just include Advertisement - Front (and make it the bottom most priority). This would then make the app use the image you already have AS a background if it couldn't find anything else.