[?] Save file issue on All RetroArch _GIT builds Versions 1.9.0-1.16.0 - Not recognizing .sav or .srm files despite only working on Google Play version (Probably outdated "latest core" database)" 1.9.12 (Details below)

[RPGX400]

First and foremost, consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
  Understood. This issue seems to be related to changes in RetroArch since the core version and configs are the same with the only difference being the version of RetroArch. This issue seemed like it was related to RetroArch, but it looks like it's just that the google play version of RetroArch and the _GIT version use different databases for what the latest core was. And it appears a change to the core was made. (confirmed needless change) I will add additional info on which versions it works and doesn't work on to help track down the change that could have caused this.

• This is not a forum or a help section, this is strictly developer oriented
  Understood. Please help figure out if this change is intentional or a bug. Your help is appreciated.

(Resolution - mainly a core issue but, the Google play version looks up cores using older database, which explains why it works still)

Description and configuration info

The emulator does not load the sav file that is in the content directory and instead creates a new .srm file.
-The core is up to date The core appeared up to date* (v0.91 c39f539) (Further research indicates that different versions of RetroArch have different "latest" versions of cores. clicking update did not change the commit version of 0.91)
-The core supports .sav files (gbSP)
-The core is exclusive to the 64bit branch so the issue can't be confirmed to exist on the 32bit version
-The issue occurs regardless of internal or SD card storage
-The folder is in the root directory of both (named GBA) and was tested with one game and save at a time
-The issue occurs on all (gba) games tested (Pokémon, Metroid, Kirby, etc)
-The save files to content directory option is on and configuration has been saved
-The save file is the same name as the ROM and is tested and working on Pizzaboy GBA Pro (also working on older version of RetroArch)
-The issue occurs whether you manually select core and content or through the saved playlist option (created using scan directory or manual scan)
-It was tested and working on a clean and a dirty install of RetroArch Plus (version 1.9.12) from the play store
-It does not work on any RetroArch versions from the git repository (buildbot.libretro) versions 1.9.0-1.16.0 from the stable channel or any of the nightly builds from 10/5 or 10/10
-Going from the working 1.9.12 version and installing any version over it breaks the .sav compatibility and causes the issue. a fresh install of any of the incompatible versions that aren't the working google play branch exhibit the issue. So far, any version number with the _git suffix. So I'm assuming that the google play and dev branches are different otherwise the 1.9.12 version from the play store and the one from the repository would both have worked.
-Some change between the two versions seems to have caused it to no longer recognize .sav files? I will do further testing to see which version does and doesn't have the issue. I will also be testing other systems.
-melonDS (0.9.3) is another core that supports .sav files but does not exhibit this issue on any version, whether 32bit, 64bit, google play, or Git version.

(Resolution - mainly a core issue but, the Google play version looks up cores using older database, which explains why it works still)

Expected behavior

As in the prior stable version 1.9.12 of RetroArch, the core supports .sav files, I select game content manually from home page or from "playlist" section. It recognizes the .sav file and load the save as normal (Pokémon save or Metroid save etc. Otherwise, it would say new game only) I continue to play and save the game through the in-game menu. The file is updated with new save info. (and then confirmed via Pizzaboy Pro and mGBA on windows 10)
(Resolution - mainly a core issue but, the Google play version looks up cores using older database, which explains why it works still)

Actual behavior

I select game content manually from home page or from "playlist" section. The game loads and no save file is found, all that is seen is the new game option or the 0% complete message. When checking the content directory, a new .srm file has appeared despite no input from me. (doesn't always get created for some reason) (Frustration ensues...) ;-)
(Resolution - mainly a core issue but, the Google play version looks up cores using older database, which explains why it works still)

Steps to reproduce the bug

1. Prepare a known good .sav file and gba rom. Put in a new root folder of the device that will be accessible by the emulator (Fuck Googles New A13 Storage Access Framework)
2. Install version 1.9.12 of RetroArch from play store (I will update with the last version this worked in later)
3. Change the save file config to store save files in the content directory. Save configuration changes to the config file.
4. Install latest (gbSP) core version (v0.91 c39f539)
5. On home menu manually select the core and then the content from the folder you created.
6. Load the game and see that the sav file has been accessed and your save game is there with your progress
7. Setup the GBA playlist using scan directory option and confirm that the save file is still accessible in the same game.
8. (Thats it for the proof of it working now to have it break)
9. Two options on how to test that it is broken on the latest release.

• A. Install the 1.16.0 update over it and double check that the save file config to store save files in the content directory toggle is still on. and repeat the steps above
• B. Or uninstall the app and start fresh with version 1.16.0 and follow the steps above to make sure the config info is setup.

10. Both ways result in the game loading up with and empty save since the .sav file was not detected/loarded/recognised. Leaving only an new game option and occasionally a .srm file in the content directory.
11. Repeat similar steps for melonDS to see how that core interacts and works on all versions with sav files. ???

Bisect Results

[Try to bisect and tell us when this started happening]
I just installed the latest version of RetroArch and noticed this issue. It appears to only affect the gpSP core (I only tested gpSP and melonDS cores for their sav file compatibility)
The issue doesn't exist on the latest google play branch of 1.9.12
It occurs on all _GIT builds available from the RetroArch git repository (buildbot.libretro) (The issue does not exist on any version of RetroArch for the melonDS core)
so it has to lie somewhere between the differences between the google play branch and the _GIT branch, and the gpSP core. Given the details above that specify what does and doesn't work.
_GIT versions are affected...

Found the root of the issue. v v v
(Resolution - mainly a core issue but, the Google play version looks up cores using older database, which explains why it works still)

Version/Commit

You can find this information under Information/System Information

Working RetroArch Git Version: 4b16b4f
Not Working Version: All versions in the git repository (buildbot.libretro) 1.9.0-1.16.0

• RetroArch: [version/commit] (Google play version looks up cores using older database, which explains why it works still)

Environment information

Tested on the following devices:
Device: Pixel 3 (128GB)

• OS: Android Version 12, Build SP1A.210812.016.C1 (Security Patch Update 10/5/2021)
  Device: Zenfone 9 (16GB Ram 256GB)
• OS: Android Version 13, Build TKQ1.220807.001.33.0804.2060.165 release-keys (Security Patch Update 7/5/2023)
  Device: Odin Pro (Snapdragon 845 8GB Ram 256GB)
• OS: Android Version 10, Build Odin_M2_V1.0.2.224_20230804_161756_user (Security Patch Update 4/5/2020)

Working Version RetroArch Git Version: 4b16b4f

• Compiler: Clang/LLVM (11.0.5)

[bslenul]

libretro/gpsp#228

[RPGX400]

libretro/gpsp#228

Thanks for the context. But something still seems off given its behavior in previous versions and on the google play store version.

So, from the sounds of it it's a change with the core itself? Then why would it work on the google play store version if both are using the same core version.

And honestly, it's a disappointment that the only core that supported sav format is no longer doing so. It's the only reason I don't use the others that only support srm files.

I need the sav format in order to not have a conversion step when exporting the save back to original hardware and for my file sync to work on my 3ds setup.

[RPGX400]

Hmm... there is a possibility that the issue is related to this change in the gpSP core.
notaz/gpsp@4ce9c5b
1 parent 9632ded
commit 4ce9c5b

Which seems to have been mentioned here as was linked to by bslenul
libretro/gpsp#228

[bslenul]

Not sure to understand why it's such a big deal, sure it's annoying but all you need to do is literally rename your .sav files to .srm (backup your files first just to be safe).

[RPGX400]

Not sure to understand why it's such a big deal, sure it's annoying but all you need to do is literally rename your .sav files to .srm (backup your files first just to be safe).

Yeah, I understand that perspective. It's technically not a big deal on its own and is mildly annoying. But the issue comes into play when you need to do it more than once, more than a few times, more than a hundred times a day when considering multiple games and save files to manage. All because I want the "dream" of having my sav file be synced and accessible on as many devices as possible. So, what ends up happening is besides the version changes between sav files (file conflicts) is now having to add a conversion (renaming) step to the process. Yet another step where the files can get out of sync and cause further headaches.
So, for example instead of the simple file sync app I made for my 3ds I now have to figure out whether to add the conversion step on the app itself or have the server do it which already had to keep files synced to the cloud. It's just another step where things can go wrong. And I'm like a novice programmer and my brain is already burnt as it is from my normal job. Lol XD

So yeah... I hope the core dev re-adds the feature since the only reason it was removed was because the feature was an "unused option" that was still working as of a month ago. :-(

Whelp since this is a core issue it seems after further research; I'm going to close this issue. Thanks for chatting with me. I sincerely appreciate it. ^_^ 👍

[RPGX400]

(Resolution - mainly a core issue but, the Google play version looks up cores using older database, which explains why it works still)