Jump to content
LaunchBox Community Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About tastyratz

  • Rank
    1-Bit Wonder
  1. Thank you, I feel like there might be a mix here too though. why did the unzip extract directory change based on lack of emulator or specific retroarch core? Also, if LB unzipped a rom, shouldn't it do a files present success check prior to launching the rom? (in case of corrupt file, full drive, etc). Also, in the case of 3do - it was imported as a rom and had no associated emulator. Wouldn't that be easy to tell and pop a message "Warning, no emulator associated with platform". If it has nothing to do after opening the file, shouldn't that notify in some way to console? Nevermind to the debug log. Maybe a checkbox similar to Zinc if that's actually an intended configuration? This was driving me nuts for awhile and there was no trace of error which I'm used to seeing coming from Hyperspin. Hopefully this helps someone else too!
  2. I just thought I'd share. I had a problem setting up and testing Launchbox that was driving me nuts. I'm not really sure if this needs a bug report because it shouldn't be handling things this way, a feature request to implement error checking and notification that's not there, or just a helpful guide for anyone else who seemed to come up dry searching. Problem: When you try to launch a game instead of the game opening either A: The file opens in the default program instead (for me it was winrar) or B: The emulator launches and for me gives an "Uncorrectable data at sector 0" error sending me to the Saturn dashboard. Instead of unzipping the rom to the temp folder to launch as it's supposed to, it unzips in the rom parent directory (and leaves a mess)! Both of these scenarios were happening to me on some systems and I had no idea. Sega CD worked great in retroarch but Saturn in retroarch did not work. Bin/iso/Cue were named correctly in the cue/file. 3do would just open the rar file quietly. Debug logging was turned on but there was ZERO indication of issues in the logs. Removing and re-adding my Saturn platform did nothing. Solution: 3do: I apparently never added the 4do core to retroarch- oops! Shouldn't this normally pop an error of some type if the platform was marked as roms / or matching an "emulator required" scraper? Sega Saturn: I had to add the core to retroarch after setting up the emulator. Even after selecting it in the drop down, it didn't like beetle. I set the core to mednafen_snes, closed out, "launched" a game, then went back and set the core to mednafen_saturn again. After this, my games started extracting to the proper location and launching successfully. Neither case was related to my roms but I would think should have popped some kind of message to console/debug logs. Is error handling and notification not yet integrated or perhaps broken? My searches I ran just came up with "I reinstalled", had XML issues, or problems with the rom files themselves. but it looks like it's much simpler to solve. This looks like something specific within LB. I hope this helps someone else going nuts just like me!
  3. tastyratz

    xml issues

    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... Thoughts?
  • Create New...