Jason Carr

Usually in that case it's a file permissions issue, but it's hard to say. Either way, we can only delete the files that the OS lets us delete. If Windows Explorer is letting you delete it but not LaunchBox, maybe it's because it requires admin rights to delete?

The above is for Windows, not Android of course. But yes, of course this functionality is coming soon to Android.

It's trying to remove the RetroArch folder; it looks like something is interfering with that by not allowing that file to be removed.

We will be targeting .NET 5 fairly soon, but as for now, I don't think .NET will allow you to use anything built for .NET 5 in an application built for a lower version.

Thanks for these, much appreciated. I can get these fixed up on Monday. We do need to update the icons to be larger for higher DPIs, because they're all still only 16x16 pixels. That said, we probably won't be doing that for this release. What do you mean by more in line with the Windows 11 style though? Good thoughts on the rest as well. We may revisit those in the future.

Yeah, our thoughts there are that the power users already know how to do this stuff, and already have that kind of thing in place. The automatic RetroArch features are definitely more geared towards new users to emulation and/or RetroArch. The point is to make it easy. So we might come back in add that kind of thing later, but probably not for this release.

I wasn't able to get the MMJR 2.0 releases to work either, unfortunately, so I won't be much help. Is there a reason why you prefer the abandoned 2.0 series of releases?

Both situations have their positives and negatives, but no, it wouldn't be more portable to always use absolute paths. Always using absolute paths would mean you couldn't move anything anywhere without causing issues. That said, I can see the use for a setting that allows absolute paths to be used, but we don't have that as of yet. Honestly, I don't believe it's been a common request (this actually may be the first time), so unfortunately it probably isn't going to be prioritized any time soon.

Because of the way RetroArch provides the stable releases, we have to download all of the cores in order to update them. We could just throw away unused cores, but that seems kind of silly. RetroArch does not provide individual cores for the stable releases, only for the nightly releases. Out of curiosity, what's your reason for updating to the nightlies? We could add this functionality, but it's more extra code than you would think due to RetroArch using a different file structure for nightlies vs. the official releases.

Yay! It is indeed! Thanks for that.

That is pretty odd; I know for a fact that NES works fine with the NES RetroArch cores at least (just did another test). So either it's a configuration issue, or some sort of strange device-specific issue. It might be worth trying to delete the platform and re-import.

Beta 3 is out now with the following: New Feature: The import wizards will prompt you for a RetroArch BIOS file (and notify you of the file name that is needed) for applicable systems The RetroArch updater will now notify you if you already have the latest version and won't update again New Feature: You can now limit how many images you wish to download per image group in the Download Metadata and Media Wizard as well as in the various import wizards (community poll Item #5) Improvement: The right-click menu has now been reorganized as well Improvement: The picture viewer has been updated and now utilizes dialog theming colors Fixed: FlowVideo control was not always updating the HasVideo binding correctly Fixed: Add/Edit Emulator will now once again let you add two different cores for the same platform when editing RetroArch Fixed: The MS-DOS Import Wizard wasn't always using the correct startup path if it was changed in the wizard Fixed: FlowVideo controls used in platform and filter views in Big Box were not stopping after selecting an item Fixed: Dialog window maximization and minimization issues (introduced in 12.0) Per the RetroArch download issues, we're hoping that this is an improvement at least. The issue with the RetroArch downloads is definitely an issue with the RetroArch web servers, but we're going to have to find a workaround for it if we continue to have problems with it. We're just trying to read what the latest-released version is, which is what is giving us all the trouble because of unexplainable 404 errors. If anyone has any ideas as to how to programmatically determine what the latest version of RetroArch is (sans for parsing HTML markup), please let us know.

@Tmacesr What emulator are you using?

@TechBoi I responded to your PM. After testing everything again, I'm still unable to replicate. All I can figure is that maybe it's a device-specific issue. What device(s) are you using?

After you upgrade to the latest version, I believe you'll need to delete your Android platform to remove all the extraneous apps. Then just restart the app and your games should show up in the Android platform, assuming that the option to scan for Android apps isn't turned off.

@TechBoi, @neil9000 is just trying to help. This isn't "his" problem, as he doesn't even work for us. He's just a volunteer moderator here on the forums. We're just trying to get to the bottom of all of this. I still can't explain why you seem to be getting different results than I do in my testing. We're not trying to cop out of any of this, but I can't fix something if I don't know what's causing it. Trust me, I'd really like to solve this for you. I took a look at the file names you sent me and they appear to be similar or the same to the ones that I'm using, so once again I'm baffled. The scraper isn't going to be perfect, but for me it's a lot closer to perfect than what you're seeing. I'll do some further testing to see if I can identify why you might be seeing these issues, but as of yet I haven't been able to figure out why we're seeing different results.

If you're getting a download error, please try visiting this URL: https://buildbot.libretro.com/stable/ Then press Ctrl+F5 to completely refresh the page. If the page doesn't load, then it's definitely an issue either with the RetroArch servers, or with their blocking system. Let me know if the page loads in those cases.

Thanks guys, I have these in for the next beta.

This is on the radar, but we do have quite a bit to add to the Android version before approaching this.

Unfortunately RetroArch's servers are set up so that you cannot hit them very many times before your IP is temporarily blocked for over-use. This is typically what is happening in this case. Unfortunately there's not a lot we can do about it. You can't run those downloads over and over without RetroArch eventually blocking you.

@TechBoi I ran another test this morning, again completely fresh and imported the entire NES No-Intro set. Once again there were no image discrepancies. Even with the exact examples you gave previously, the current North American images were downloaded. Obviously we need to identify whatever is different between your situation and mine. Can you send me a list of the file names from your No-Intro set?

Are you having trouble importing them on Android? What exactly is happening?

Yup, we'll definitely be adding support for all of that.

Where are you downloading ROMs with badly formatted names? There really should only be one type of ROM set that anyone should be downloading these days: No-Intro sets (at least for cartridge based systems). You can get them easily from archive.org. What set are you using?

In the options, at the bottom, is the path to your data folder. There are Images and Data folders in there that you can just delete.