C-Beats

That prompt is just asking if you want to close BB and run the installer you already told us to download via the settings. If you don't want it doing that in Tools > Options > Updates within LaunchBox shut off the update auto-download.

For those having the issue could you post up the following information: 1) What theme are you using? 2) What platform view are you using? 3) What game view are you using? 4) Do you let attract mode change platforms or no?

Believe this to be related to a bug found and resolved internally. The code passed to custom badge plugins passed null game references to the badge code which caused exceptions downstream causing that issue. Should be resolved in next release. Currently isn't a work around other than disabling the badge throwing the error.

I went ahead and decompiled the library attached. It looks like they are using that DLL to render your marquee. They are basically creating a WinForm window that is displayed in your marquee. The library allows you to change the settings for it. You could potentially look into the Third Screen Plugin found on the forums or just use Big Box's marquee view for marquee functionality.

Just do as instructed and uncheck the Attempt to hide console window on startup/shutdown option in the Edit Emulator window and you can use the emulator as desired without any side effects (or least none that I've seen personally or had reported)

@Kevin_Flynn @AlabasterSlim only the local copy of the games database we use to scrape metadata/media was converted to Sqlite. Your local files are still the same XML files they've always been.

Yeah, I think this is the cause. I have a full path in mine that isn't in yours and it's causing issue in the code. A work around for now is to open the yml file and in the "pref-path" entry put the full path to the folder the emulator is located in. Save the file and then try to import again in LB. Alternatively you can rename/move that file out of that directory, run the import and put it back. I've noted the problem location in code and it should be corrected in the next beta release.

Could you check to see if there is a config.yml file in your emulators root directory and if so PM it to me so I can attempt to step through code on my end @cscottbrown @ry4man93

That would depend on your auto-import setting. Tools > Manage > Storefronts will show what you have set to auto-import.

Apologies, that menu has had it's strings/location changed a bit since first added and I always forget the new one. The second screenshot is showing me what I was hoping to see. I'm at a loss for the moment since I can't replicate on my end. As time permits I'll walk through the code and see if there anything else we can walk through in an attempt to figure out why it's not working correctly for you. Are you opening the app from a network location or as administrator?

Yeah, worst case scenario is that on starting the app back up you'll import a bunch of games you may not want

If you go to View > Show/Hide within that menu are some selections like "Hide Games Missing..." are any of those checked?

If you press "Force Import Duplicates" in the import options page do you see them then? Also if you go to Tools > Manage > Platforms do you see Vita listed? If so does it have a game count?

@cscottbrown Can you run a normal ROM import using any file/folder and import for Playstation Vita and in the emulator page select Vita3k. When you get to the last page regardless of what you selected to import from all games not yet imported that are installed to Vita3k should appear on the game select page. Select a row and press delete to remove it. Let the import run and then close LB. Open it again and see if the scan picks up the row you deleted on restart. We are seeing a bit of a delay in the auto-import process in 13.19 likely related to the Sqlite change so give it a while longer (no longer than 3-5m depending on your specs).

We utilize the method we do for two reasons. It's officially supported by Valve, and it's far more secure than an SSO session like Playnite/GOG utilizes. SSO methodologies would need to save SSO cookies locally that can be used as an attack vector into compromising your accounts, otherwise we'd need to ask for creds every time (or store the creds which again is less secure). Since last I knew both were using it to log directly into your Steam account that session token can be used to hit your account settings including payment methods and purchases. Ours cannot. That being said I know Valve is constantly improving things and they may have made a more secure way of doing this that we can look into. You can submit a ticket via the Help and Support link at the top so that the powers that be can decide how important of an issue this is to tackle for our userbase.