C-Beats

You got something messing with XML files that shouldn't be. If you open the files in \\LaunchBox\Data and look for the string "f`lse" (without quotes) and replace it with "false" (without quotes).

To be blunt, yes. We have been pretty blessed by some amazing contributors to our database that have put in a LOT of effort to make it as good as it can be. I personally feel like we'd be doing them a disservice by allow poor submissions through. Users will tend to remember the negative they see in the DB when scraping, not the positive and so for every one or two poor submissions they tend to outshine a few hundred quality ones in the users mind. To allow that to happen willingly seems pretty disingenuous to the people that have been putting in all this effort to provide quality submissions. Yes, the background of the UI the image is placed on, not of the image itself. The UI background is black and you have carts selected and all you see are various squares all with different backgrounds then you're UI looks some tacky crap from the 90s hosted on GeoCities. Even the grid view of LaunchBox looks far better with transparent images than one with solid backgrounds. Also there is the dilemma of where do we draw the line? Should we start allowing pictures with the scanners desk underneath wood grains and all? How bout someone holding the tape/cassette, I mean the tape is THERE right? I think allowing stuff like that just opens us up for even worse submissions because, "solid backgrounds are permitted!" While I can see things like this being frustrating, we believe that the improved end product is worth the increased time it took to get there. No one is stating that this may not take longer, if submissions count drop because it takes more time for each one no one will NOT understand. I feel a lot of this sentiment we see from contributors are from some self imposed calling to some higher purpose of filling our database that sometimes gets a bit unhealthy. We appreciate any effort you can provide, but if it cuts into time you need in your personal life for any real reason then feel free to take that time for yourself, it's yours! The sacrifice is appreciated but not needed. As stated before we have a pretty large number of contributors which affords each one to be able to take a break when needed and not have the overall quality of the DB suffer too greatly. While having this archive is a great secondary win from our database it is NOT it's primary purpose. The primary purpose is a companion database to the frontend clients using it. The fact we can be a part of something used to preserve information and media on an artform we all love is FREAKING AWESOME, but ultimately sometimes needs to take a backseat to the primary directive. This may be one of those times. Transparent images work far better for literally anything you are using the image with and so we had to make the call that they were a requirement for submission. You're correct that it may reduce submissions, which IS unfortunate but we believe is required to best succeed at the primary purpose of our database. We are, "Keep it sexy silly!" (sorry couldn't help myself...)

1) Open LaunchBox 2) Go to Tools > Manage > Platforms 3) Select a platform and press edit 4) Window that opens is the "Edit Emulator" window, in that window is a folders tab. Select it 5) In the datagrid that appears are several folders and their path. Ensure none point to your desktop

Can confirm there is no logic change in 13.14 that would correct this issue. The issue is a weird issue with how WPF handles reading the XAML files from the drive in a multi-threaded environment which unfortunately means it can be pretty random when it does or doesn't occur and a pain to debug...

I've not used standalone at all. What command line are you passing? If you go to Tools > Manage > Emulators and then select and edit Duckstation, grab a screenshot of the first page of that edit window that appears and post it up.

You could be running into the issue simply because the order you tried things. To get the image to display you should do the following (in order): 1) Open LaunchBox, go to Tools > Manage > Platforms. 2) Select the platform in question and press edit 3) In the form that appears the right hand side shows images assigned to the platform. Verify that a logo is present, if there isn't one add it by using the Add Image button or dragging the image to the window. When adding an image using either method make sure to assign the image type to clear logo by selecting the text in that control and then selected the Clear Logo image type from the menu that appears 4) Press OK to save changes, then close LaunchBox 5) Open Big Box, then go to the system menu (press back) and then to Options 6) Go to the Image cache section and clear your platform image cache 7) Return to your wheel and you should see the image as desired

Recently we added logic to the database that for Clear Logo's, Carts, and Discs the image should have transparency within the image. The image types are designed and used within the application in a way that a transparent background is required for them to appear correctly. As such it made no sense that we allowed images with solid backgrounds to be uploaded to the database.

you running Duckstation standalone or Duckstation RetroArch core? You may have some "load save state on start" option enabled that is attempting to load a state that you don't have.

You can check your platforms folders and make sure none are pointing to the desktop. We create those folder paths as required so if one of them was changed for some reason it'd generate the folder. Outside of that we really don't have much logic that creates folders that would cause what you're seeing.

You can create pretty intricate menu set ups by using the Platform Category view instead of Platforms. This then lets you create menus several layers deep like you are describing. To do what you're referring to your top layer would be 3 categories, then under them would be playlists for the platform in question that also supports that setup. You'd hide platforms from that view entirely (just make sure they don't have any parents assigned).

Yeah

What file location is the new and old installs at? I know some locations have caused issues in the past, like installing directly to the root of the drive. Curious if WHERE it's being installed is the problem.

For starters I'd close all instances of LaunchBox. Then navigate to an old instance of LB and copy it's data folder to the new instance, (delete the folder in the new instance and then copy the old over). Then start the app again. If it still works you probably have a corrupted file some where in the install. Sounds like it could be either a plugin, or some no longer needed files lingering in the core or metadata folders causing an issue. If you're feeling adventurous delete the following folders from an existing install and then run the installer over top the location and see if it corrects anything: LBThemes Metadata Plugins ThirdParty

Can you use the 13.14 installer to install a new instance of LaunchBox some where on your computer and let me know if the new instance works?

Pretty sure this will occur if you manually alter the settings file and add it twice on accident. I'm not seeing it in any of my builds.

Can you open up \\LaunchBox\Data\Settings.xml and look for the <Theme> tag and change that value from Default to Old Default and then save the file and attempt to open LaunchBox and let me know if you still encounter it?

What file system format is your drive? NTFS or exFAT?

The 13.14 installer should be in the updates folder as well. Just run it and point it to the current install (make sure you don't point to a LaunchBox folder WITHIN the current LaunchBox folder when doing it) and then see if it corrects the issue.

Does running the current version installer over top work?

If the Event Viewer has an app crash log there will be two of them for the crash, one log just saying the app crashed and the other with the actual exception. The text you posted appears to be the "it crashed" log which won't be helpful at all. The other log should at least list a reason for the crash.

The cache system of auto-pop playlists has been altered a few times since I've been on team, but I've not been the person who changed the code so I don't really remember where we landed regarding WHEN/IF we cache the return set of an auto-populated playlist. I do know we had that issue in the past, but pretty sure we removed the startup cache of those playlists a while ago. What are your startup times looking like, and which app are you seeing it with? I have a build that has 2680 auto-populate playlists and I don't see any impact to my startup time. I admit I don't have as many game records as you in that build though and am only around 17k.

Reads like you're trying to load a bad theme XML file. What theme are you using? If using Default, did you try to edit something in the files?

NetherSX2 is just AetherSX2, should be able to select it as the emulator in the app and it work with NetherSX2 out the box. Or least did on my Odin 2. I don't remember having to change anything special for it.

Files the emulator needs to run the games properly. They are typically BIOS files for the system in question.

Known bug for platforms with no dependencies. Press back to get to the page, we have a correction made and it will be in the next release.