Jump to content
LaunchBox Community Forums

xml issues


Recommended Posts


I just starting getting into LB recently. I have hit a corrupted lunchbox.xml on start. It got corrupted for some reason when I logged off my user account with LB still open. So I restored the latest one from backup and all is well.

But then I started wondering about why LB uses problematic and potentially very slow xml files.

I wonder if things would be much better all around if LB switched to using a sqlite db? Has this been considered?

Link to comment
Share on other sites

You can still see and modify a sqlite db with a free sqlite tool, but I guess it's not as easy as using a text editor. I understand that reason. If the performance/stability benefit isn't big enough, it makes sense to stick with xml I guess.

Link to comment
Share on other sites

  • 4 years later...

Sorry for the necro bump, but, I actually found this thread in a search because I wondered the same question.

Why on earth is Launchbox not using sqlite on the back end with this many entries?

I'm going to agree that people want to edit their configs. Having it exist ONLY in a database wouldn't fly.

Giant XML files though really isn't a great answer. So... @Jason Carr why not both?

What if Launchbox imported XML data into a SQLite db as part of the caching mechanisms?

People could still edit the XML's as needed. On start, launchbox could parse the folder for timestamp codes and whenever the timestamp of the XML differed from matching sqlite entry, the contents are re-imported. That should be a relatively quick operation but then it's a 1 time op only on changes. That could entirely be a background process AFTER LB/BB launched scraping for changes and new entries.

sql back ends are light, lightning fast, editable on the fly, and significantly more scalable. XML on the front AND back end has GOT to be holding back performance. I'm sure it would make playlists and per game list stacking simple queries vs generated objects.

Edit: Holy CRAP I just realized the online backend metadata.zip is a file pull of a couple giant XML file! No WONDER imports take as long as they do! I bet we're talking 100x performance delta...





Edited by tastyratz
Link to comment
Share on other sites

@tastyratz This has come up many times over the years, and my responses are all over the forums. There are very few performance issues that are actually with the data itself. Really, there aren't any. Delays come primarily from the media. If you run an import and turn off all image options, it goes lightning fast. Our code has been optimized many times over, and SQLite would not bring a significant performance benefit. I know, because for one thing, I have the code, and for another thing, I spent many years as a software consultant working with SQL Server, MySQL, and SQLite.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...