Jason Carr

The media is almost always the biggest cause of performance issues, of course. Media-heavy things aren't always easy to do quickly. That's odd, but it's a good path forward. I know that the blurred backgrounds aren't causing much lag on the systems I've seen and tested, so I'm guessing something funky is going on with them on your system somehow. Certainly strange. It almost feels like you're using a broken/old blurring mechanism. Are you using the LaunchBox default theme? Any chance you're using a custom theme that might be causing the lag? Thanks, sounds good.

I missed the ThirdParty folder when I typed that out. Do you have this folder?: LaunchBox\ThirdParty\7-zip\x64 It's the x64 folder I'm curious about specifically. Also, are you on a 32-bit or 64-bit system? I just tested installing the latest beta to a new folder in the default location, and I'm still not seeing any issues. My only thought is maybe you're on a 32-bit system and the 32-bit version isn't working?

You can update to beta releases by going to Tools > Options > Legacy > General > Updates in LaunchBox and checking the box to update to beta releases. Then you can force an update check by going to Help > Check for Updates.

I'm not 100% sure that it has to do with media. One thing you could try doing temporarily though is renaming your media folders so that there's no media in LaunchBox to see if you still get the issue. Make sure you take a backup of your Data folder first though (but that's automatic unless you've turned off automatic backups).

Per jumping back to the top on delete, you can stop that from happening if you disable dynamic box sizing. Dynamic box sizing affects a lot of things like that. It's worked the same since we added it.

Well, it doesn't appear to be a data issue because I still can't replicate it on my machine with your data. I suspect that it's probably primarily a performance issue. It could be somehow caused by media though, since I didn't have any of your media to test with. I'm not sure about a fix for it though, since I haven't been able to replicate it, unfortunately.

We have replicated this ourselves and already fixed it for the next beta. No need for further confirmations of this.

Thanks for all the feedback, guys. To be completely honest, I'm not 100% sold on integrating DATs directly into the LaunchBox app itself, but that would come later anyways. Step one would be integrating No-Intro data into the games database, and using that on imports to improve ROM recognition. It can also be used to improve the data on the DB. It'll take a lot of manual work to match everything up, but I can see it being a big improvement. I don't think we can trust end-users to populate the games database with No-Intro data, so that would have to be done by us.

We can troubleshoot your performance, but probably would be best to do it in a new thread. We'll need your systems specs and stuff to determine if there's an issue with your data, or if it's expected performance with your collection and your hardware. My main concern though here is making sure that there's not an issue with the games list fading out and not coming back in. I've tested that though and I can't seem to reproduce it. I may be best to just zip up and PM me your Data folder so that I can test it. @Ateb Thanks for that report. That's a new issue that was introduced in the betas, apparently. We'll get it fixed for the next beta. @Pixel Thanks for that report as well. We'll get that one fixed too. What do you mean by sort by Versions? I've tested this and haven't been able to reproduce it. We should probably figure out what's happening here though; it's probably related to the 7-Zip upgrade we did in one way or another. Do you have a LaunchBox\7-Zip\x64\7z.exe file in your LaunchBox install?

Hey guys, let me clarify a few things. The main game name is important to be named according to the rules of the database. However, half the point of the alternate titles is for flexibility, and they DO NOT need to obey the same rules as the main game title, especially since we're using it to achieve better recognition of ROM files. It doesn't make any sense to reject alternate titles because they don't obey the rules in that case. I appreciate folks like @Captain Star Paw adding them to improve ROM recognition. Also, I agree that it would be beneficial to integrate the DATs. It has come up before, but it's been a long time. I can see that being a big plus for the database as well. I've got a ton on my plate, but this has been a good reminder; I'll look into the feasibility of all of that here soon. Let me know if you have any suggestions or recommendations in that regard.

Beta 8 is out now with the following: New Feature: The game audit process has been overhauled with missing fields added and the ability to audit all of the games in your collection at once instead of just single platforms Improvement: More additional logging has been added to the MAME high scores in the debug logs for @GreatStone With the updated audit, it is still in development. There's a number of tweaks that we still want to make, such as some of the column headers, the colors, the sorting, etc. It should mostly behave correctly though; we'll be back to it next week.

I'm doubtful that anything changed with the 10.14 release that would significantly slow anything down like that, but I could always be wrong. My guess is that it's likely a data issue of some sort. Did you make any significant data changes recently that could have caused it? Also, do you have similar issues with the box art view? This is the only notification from anyone that I've received that the 10.14 release has performance issues, so I'm guessing there's some kind of other influence and it isn't just the 10.14 release. I'm guessing it's either related to the list view, your data, or something else on your machine.

You can just add a new game via Add in the button bar at the bottom, and put the steam:// text in the Application Path field.

I see. All I can figure is that maybe there might be some connection issues? The log file states that it attempted to upload that score, so it looks like everything up to that point was working properly. I'll add some further logging to report when the uploads fail, but that's all I can figure happened in this case. It appears that an Internet issue prevented it from uploading correctly. If you're seeing this often, then most likely there's some kind of Internet instability issue.

The ROM folder name shouldn't make any difference here. Do make sure you're using the latest beta if you running into issues. Looking at the log file though, it looks like it did upload scores both times.

See the MAME troubleshooting thread here: We'll need a debug log, and then we can easily tell what's going on.

Yes, the massive multi-year-long list of changes was archived yesterday, as has been done in the past. We didn't lose any changes, just cleaned up the backlog of accepted and rejected changes. The "Changes Status" page should be the only page on the site that is affected, and as a result, we get much faster moderation.

Any thoughts on this from the community? Come to think of it though, there are a lot of games that don't have any names entered at all. Do we have an easy way of determining what games use names and what games don't?

Thank you so much for all of that @GreatStone. No problem; I can get that in for the next beta. Makes sense. This is a great idea, but my main concern here would be that you could easily destroy an amazing high score if you slipped up when entering the initials. I agree that we could really reduce a lot of issues that way though. But I know a lot of MAME games can be confusing when entering in initials, so I'm concerned that it might end up being a frustrating thing for users if they lose a high score because they didn't get the initials right.

From the log file: 2020-05-06 09:44:45 PM RomPath after M3U build: G:\LAUNCHBOX\Emulators\Mameui64\Roms\fireshrk.zip 2020-05-06 09:48:08 PM Aborting MameHighScores.Parse: No high score or nvram files found. This means that, for whatever reason, MAME didn't spit out any .hi or nvram files to read, at all. So in this case, there's nothing that LaunchBox or hi2txt could do to read the high scores. I didn't see you play the game, so I don't know exactly why MAME didn't spit out any files, but it could be either because of a bug in MAME or the MAME high scores system, or because no high scores were achieved and the files were never updated.

I'm not seeing anything in the logs related to MAME high scores at all, so for one reason or another it's not recognizing your games as MAME games. What did you call your platform with all the MAME games in it? What version of MAME are you using and what did you call your MAME emulator in LaunchBox?

I'd have to look into if there are any differences in functionality or command-line usage between GroovyMAME and MAME. I've put so many hours into the high scores features at this point that I really need to move on to new things, at least for now. It's an awesome feature, but I can't spend forever on it, unfortunately. I'll note the request though.

As far as I can tell, these appear to be hi2txt (or MAME) issues as well. Can you report them? See the instructions in the first post of this topic for reporting hi2txt issues.

We should probably report this game to @GreatStone. If you can follow the instructions in the first post of this topic for reporting hi2txt issues, please do (create a ticket on Github).

Yes, absolutely, @Corkscrew. Please see the first post of this topic for instructions on getting started. You may need a new translation package for it though. Can you take a look at this page and tell me which language code we should be using for the new translation? http://www.codedigest.com/CodeDigest/207-Get-All-Language-Country-Code-List-for-all-Culture-in-C---ASP-Net.aspx