Configuration via RGUI partly broken?
-
It seems something has changed in how RetroArch handles configuration includes. By default, RetroPie relies on a central retroarch.cfg in /opt/retropie/configs/all. For each libretro emulator, there's another retroarch.cfg, for example /opt/retropie/configs/snes/retroarch.cfg. On a clean installation, the emulator specific retroarch.cfg simply includes the central retroarch.cfg, i.e.:
#include "/opt/retropie/configs/all/retroarch.cfg"So far, so good. You can change RetroArch settings for a specific emulator while you're running a game, by pressing Hotkey+X (i.e. Select+X) to bring upp RetroArch's menu system. Previously, you were able to change any settings and then go into "Configuration File" and select "Save Current Configuration". The next time you'd launch this emulator, the settings you made would still be in effect.
This no longer seems to work, at least not the way you'd expect. For example, try changing the setting "Threaded Video" from on (the default) to off, saving the configuration and relaunching the emulator. The setting is back to "on".
I've made some tests on both RetroPie and RetroArch on Windows and my conclusions so far are:
- This problem is caused by the use of "include" to include another config file
- The issue occurs when the included config file contains the setting (and it has not been commented). When changing and saving this setting via the GUI, such as "Threaded Video" in my example, the new value is not stored in either configuration file (base file or included file). It's simply lost.
- If a setting is deleted or commented from the included config file and the setting is subsequently changed and saved via the GUI, the setting will be saved. The setting value is stored in the base file, not the included file. It's stored after the "include" line.
I will also mention that I tried changing settings in RGUI, then went into the Quick Menu -> Overrides -> Save Core Overrides. If the "Threaded Video" setting has been modified, this results in a crash and you're thrown back to EmulationStation. I tried other settings and those did seem to successfully save without crashes.
I'm quite sure this behavior has not been there all along, and that it previously worked fine to save any setting from RGUI. I wanted to check here if this issue is known since previously and has been discussed with the Libretro people or perhaps if workarounds are being devised? Maybe there's good reason for the change in behavior, but it does cause unpredictable behavior in RetroPie. I'll happily bring this report to Libretro's attention if it's not already being dealt with.
-
@Brunnis Which version of RetroArch ? Details of config are needed to reproduce.
-
@BuZz Oops, totally forgot that. It's RetroArch 1.8.8. It's the exact same image as used when reporting this issue (see description for full config details): https://github.com/raspberrypi/linux/issues/3935
In short, the RetroPie 4.6 image fully updated should exhibit this issue.
-
Looking into it.
-
I can confirm there is an issue - it used to save out all the values no matter (just to note: runcommand moves the #include line to the bottom also after exiting). Looks like it will only save out values that are not present in the included config. It used to save out everything and we relied on this behaviour.
Please can you open a ticket at our bugtracker. We can track it there and report upstream if needed.
I'm bisecting it to see where it changed - looks like this broke somewhere between v1.8.5 and v1.8.6
Note it is recommended of course to edit the configuration editor etc, or manually adjust to avoid long unmanageable config files (Not saying it isn't a bug - just it's a better way to manage imho).
-
Still bisecting but I think it's this https://github.com/libretro/RetroArch/pull/10524 or a related change.
-
I can confirm it is the changes referenced above. Probably a ticket upstream will be needed for this but I may revert the change for now.
-
I'm looking into this now so will make a ticket myself on our bugtracker.
-
-
@BuZz Thanks for looking into it. I saw that you have implemented a temporary fix until it's fixed upstream. I will test this and see how it works.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.