C-Beats

I'm referring to the legacy badges that existed before we moved to the new "Progress" field. Old badges would show if play time/count were 0, or if you had the completed checkbox checked. New Progress badge/system should already assign the value accordingly to "Not Started / In Progress" or "Done / Mastered" and would show the appropriate badge, making the old badges redundant. Because of that we're getting rid of the old to make room for the new and avoid potential confusion.

Traditionally it's been a ruling to have screenshots in native resolution. That being said it doesn't always place nice with the UI and so that isn't a hard set rule (that I'm aware of). I personally would prefer though that if it's pixel based systems the scale be a pixel perfect scaling. No one wants to see any stretch/miss-shaped pixels... Generally speaking I think upscaled resolutions in 3D games also should be avoided. The screenshot should be indicative of what the game would look like on OG hardware, and not what it can look like after being manipulated by emulator tricks. Also in general you should NOT be accepting images using shaders that alter the game image in any way. The images where pixel games are manipulated to look like some smudgy watercolor crap doesn't really belong in the database.

Hey buddy! Can create a new thread in the troubleshooting section of the forums. Really we aren't too picky to these sorta things outside of the beta thread.

Don't believe this is beta related and should probably be moved to it's own troubleshooting thread so it doesn't get lost in the shuffle. This is likely related to the changes pertaining to video playback since migrating to .NET 9. Spin up a new thread people can attempt to help you work through the issue there. Biggest first step is to make sure you let the installer install Klite and it's codecs for you.

If you remove a game that was auto-scanned in it'll go to the blacklist file found in \\LaunchBox\Data\Blacklist.xml (or something similar). With LB closed delete that file and reopen and it should bring them back in. Also make sure in the View menu you aren't hiding games missing any specific media item. It could be that the item isn't showing because it's imported but isn't visible.

Yeah, we're looking into the playtime criteria. Unplayed/Completed badges will both be removed in the new beta as well.

Yeah, because of the notable confusion we'll be renaming that page to "Game Progress Organization" as well as add text to the top of the page explaining what it is you're actually doing on the page. Stop others from running into the same confusion hopefully, thanks for bringing it to our attention (you as well @Ultra God Azgorath). Last thing we want to do is make a application as.... feature rich as LaunchBox anymore confusing lol. We'll take a look at games getting the wrong in progress value assigned. We had any issue with that before the release we thought we had taken care of, sounds like we may have missed a spot or two.

Could just use DAT files for a ROM set. Should be able to con an AI (or potentially some one on the forums) to help make you a tool that creates an empty file by the filename included in the DAT. Would get you a pretty good start on your journey.

You may be able to use a DAT file with a ROM manager to help in your efforts. You're being a bit vague as to what the end goal seems to be. Some discrepancies will always be found between data sources though. Pretty rare to grab two different data sets and they match 1:1, especially with video games where things like release data and what dates are used can vary pretty wildly. It also would help to correctly identify where each source gets their information. For example the link you provided isn't "official" anything. It's a Nintendo fan site. The company has nothing to do with that site. Some communities have different standards than others once again causing a lot of information disparity. If you have a specific goal though you're working towards it may make sense to state it so others can better assist in getting you the information you're looking for.

Auto-Track Priority system is the first image you saw. The system will always go from the bottom up stopping on the first criteria that the game qualifies for. The second image is ONLY for managing what values show as possible values in the field and what order they appear in the UI. The ComboBox drop down, Sidebar, and quick filter ALL will use that priority list to display the values in the order you want them displayed. That page has 0 effect on what values a game gets for auto-scan, and can be altered even if you have that feature disabled.

We run an application called RAHasher on your local computer that hashes the ROM. Some system this process requires reading the whole file, others just the headers. The thing that makes it take WAY longer is if your ROMs are in 7z format since that app doesn't support it so we have to unzip your game, THEN hash it for each item you're scanning.

First two can be ignored, that's just Windows being Windows, annoying vague and overflowing with misnomer information. The part that has me confused is why you seem to have permission issues launching the app.... Do you have the same issue if you open the executable C:\LaunchBox\Core\LaunchBox.exe?

EA moved to an entirely different back end system. I think I have may have found a few projects that have cracked the code on the new one, but I basically need to completely rewrite the back end to make it work. As of right now we're hoping to have it in the 13.22 release.

Sounds like a missing codec potentially. 13.21 installer should be packaged with K-Lite which will install the ones you need for playback. It should ask you if you want them installed if it doesn't detect them. Just say yes and let it do it's thing.

Can you do the same steps you did with the one you've installed on a drive NOT in documents? The error should be different. Hoping it gets ya one step closer.

This may be because it's installed in documents. We've seen occasion doing that causes permissions issues. Can you try to install in a folder on one of the drives (like C:\LaunchBox\) and see if you can open the app there?

Back up again

Sorry to hear you're having this issue. Typically the best way to start troubleshooting things like is to try to open the app again and let it crash. Then go into Windows Event Viewer and look at your application logs. There will typically be two errors back to back. One says something like ".NET Runtime Error" both should say it's for LaunchBox. One will just have a generic, "stuff broke" message with a lot of random useless stuff in it. The other should have an actual readable error message. If you could provide THAT (assuming there is one) it'd give us a good starting point as to why you're seeing what you are. The current version of LB is also 13.21. You could try to upgrade to the latest to see if that helps at all.

We are once again seeing the EmuMovies API down. I will let you all know when we see it back up.

Good news @superrob3000! Faeran was able to deduce how to rep it and it'll be resolved in next beta.

Thanks for the report (and @JoeViking245 for the confirmation) is on the short list of things to get resolved so we can get the next version out.

I'm not able to produce this currently, but I have quite a large number of changes at this point compared to what's currently live so I can't say it wasn't a thing in this release. I've added it to my pre-release tests and will make sure I still can't before we release. Be interested if you can still do this once the next beta drops out. Thanks for the report either way.

Some of these have been the design of the app well before I started but I'll do my best to explain the reasoning as best as I understand. First off being the separation of files. When LB was first built we didn't HAVE the database and so you HAD to store information locally in the data files because when you scraped you were hitting a third parties API and not this file. Updating to "new data" from any data source is by design a manual process as well because people get REALLY irritable when the software starts changing their data all willy nilly. It's because of those design decisions each field doesn't have any metadata tied to it saying, "user manually touched this, please don't update". We also don't have any automated scraping processes that would update the data for you even if we did have that flag. The data from the XMLs is shunted into memory on load. Obviously not in raw text, but in "models" we use internally in code. This means that we are only susceptible to drive read failures negatively impacting the app once, and not every time we want to do any load process. It's also WAY faster to read from memory than from disk, the difference becomes greater on spin-drives and network locations. Having all the information in one file also means that we only have to load from one source, and not two (which we'd then have to merge) which is far faster and leaves only one point of potential failure instead of two. There is also messiness regarding game entries in your library NOT in our database, or entries that started off NOT in it and then since were added and connected, the fact that metadata came from other sources than just this file (like MAME ini files, storefront APIs, etc), and more... There are definitely things we've identified as things we'd do differently in the future if we had the opportunity, as well as some nice have things that would make certain tasks easier for both user and dev. As time allows we push the app towards those goals, but some of those legacy decisions are rooted DEEP in this code base and so migrating to our newer desires can often time being a MUCH larger and complicated task than you may assume and so get pushed off for other area's of the app we can improve in a more timely manner (that also typically have far larger impact on the overall user experience). Quite a large number of the performance bottlenecks have been identified and I've offered several solutions to combat, but as the only developer actively working on the PC version of LB there is only so much time in the day and so we have to really triage where and what I do in the codebase for maximum impact to everyone.