[GH-ISSUE #298] Issues with ReroArch standalone and RetroArch in EmulationStation #91

Open
opened 2026-10-15 12:48:57 +00:00 by bsakaguchi · 4 comments
Owner

Originally created by @lonlundgren on GitHub (Mar 12, 2026).
Original GitHub issue: https://github.com/games-on-whales/gow/issues/298

running retroarch:edge and es-de:edge, neither is configured/setup correctly

both run different versions of retroarch and have slightly different UI
standalone retroarch: 1.22.2
es-de retroarch: 1.21.0

Neither correctly show a list of available cores to download using shipped config. Since they are different versions, fixing is different for each, but they seem to be configured to use http instead of https links, one like the addition of .extended-index added to the path the other likes enabling experimental cores

Once configured, neither properly downloads, unzips cores.

I verified manually downloading / extracting a core in es-de version (had to install unzip).

Since logging isn't enabled in either and potential for missing packages, troubleshooting is cumbersome (especially between two installs with two different versions). I enabled logging for es-de version and spew showed nothing when a core download was attempted to not helpful in diagnosing. Of course UI shows it properly downloaded the core.

Since this is my first time out-of-the-box using Wolf and both things I wanted to try first were broken, I'm going to stop here since I don't know how supported this software is and 2/2 is not a great sign.

Originally created by @lonlundgren on GitHub (Mar 12, 2026). Original GitHub issue: https://github.com/games-on-whales/gow/issues/298 running retroarch:edge and es-de:edge, neither is configured/setup correctly both run different versions of retroarch and have slightly different UI standalone retroarch: 1.22.2 es-de retroarch: 1.21.0 Neither correctly show a list of available cores to download using shipped config. Since they are different versions, fixing is different for each, but they seem to be configured to use http instead of https links, one like the addition of .extended-index added to the path the other likes enabling experimental cores Once configured, neither properly downloads, unzips cores. I verified manually downloading / extracting a core in es-de version (had to install unzip). Since logging isn't enabled in either and potential for missing packages, troubleshooting is cumbersome (especially between two installs with two different versions). I enabled logging for es-de version and spew showed nothing when a core download was attempted to not helpful in diagnosing. Of course UI shows it properly downloaded the core. Since this is my first time out-of-the-box using Wolf and both things I wanted to try first were broken, I'm going to stop here since I don't know how supported this software is and 2/2 is not a great sign.
Author
Owner

@lonlundgren commented on GitHub (Mar 12, 2026):

Additionally, while troubleshooting es-de version
tcpdump showed download activity when pulling a core from the UI
inotify showed filesystem activity in the cores directory

That's about as far as I got with this mystery between configs, perms, packages, container troubleshooting etc.

<!-- gh-comment-id:4050995807 --> @lonlundgren commented on GitHub (Mar 12, 2026): Additionally, while troubleshooting es-de version tcpdump showed download activity when pulling a core from the UI inotify showed filesystem activity in the cores directory That's about as far as I got with this mystery between configs, perms, packages, container troubleshooting etc.
Author
Owner

@ApexArray commented on GitHub (Apr 1, 2026):

I also had this issue and just found the solution.

Navigate to Main Menu -> Online Updater and click Update Core Info Files. I also updated the other items as well (Controller Profiles, Cheats, Databases etc.) Then you should be able to download cores from the Load Core/Download a Core menu.

Strangely enough, I didn't have to do that in retroarch running under the Lutris image, but that version is several versions behind and had some compatibility issues with my games.

Anyway, hope this helps. Cheers!

<!-- gh-comment-id:4172753702 --> @ApexArray commented on GitHub (Apr 1, 2026): I also had this issue and just found the solution. Navigate to **Main Menu -> Online Updater** and click **Update Core Info Files**. I also updated the other items as well (Controller Profiles, Cheats, Databases etc.) Then you should be able to download cores from the Load Core/Download a Core menu. Strangely enough, I didn't have to do that in retroarch running under the Lutris image, but that version is several versions behind and had some compatibility issues with my games. Anyway, hope this helps. Cheers!
Author
Owner

@lonlundgren commented on GitHub (Apr 1, 2026):

No, of course this does not help.
Again, per the contents of the issue, there are two different installations of RetroArch and I included the version number for each, and each behaves differently.
As I put in my notes, even if you get the core list loaded, the cores do not actually download or persist - even when the UI says they do.

Just try for yourself.

<!-- gh-comment-id:4172891068 --> @lonlundgren commented on GitHub (Apr 1, 2026): No, of course this does not help. Again, per the contents of the issue, there are two different installations of RetroArch and I included the version number for each, and each behaves differently. As I put in my notes, even if you get the core list loaded, the cores do not actually download or persist - even when the UI says they do. Just try for yourself.
Author
Owner

@ApexArray commented on GitHub (Apr 3, 2026):

Yes, I did try myself and that's exactly what worked for me. See attached images for proof.

Like you described, the cores list was empty for me in RetroArch standalone 1.22.2 and the es-de image. Once I updated the core info files with the above method, the list populated and I was able to download them without any problems. I've been playing games on the retroarch image for a few days now, so I can attest that it works.

It could also be a filesystem permission issue. Perhaps try deleting the /etc/wolf/ directory and start from scratch again, or use a named volume instead of a bind mount since those tend to have fewer issues with permissions.

Specs:

  • r720xd w/ VMware ESXi 8.0
  • Debian 13
  • GTX 1080
  • Nvidia (proprietary) Driver Version: 580.126.09
  • CUDA Version: 13.0
  • Docker version: 29.2.0

Note that I'm not affiliated with the project in any way, just trying to help.

Image Image
<!-- gh-comment-id:4185007403 --> @ApexArray commented on GitHub (Apr 3, 2026): Yes, I did try myself and that's exactly what worked for me. See attached images for proof. Like you described, the cores list was empty for me in RetroArch standalone 1.22.2 and the es-de image. Once I updated the core info files with the above method, the list populated and I was able to download them without any problems. I've been playing games on the retroarch image for a few days now, so I can attest that it works. It could also be a filesystem permission issue. Perhaps try deleting the `/etc/wolf/` directory and start from scratch again, or use a named volume instead of a bind mount since those tend to have fewer issues with permissions. Specs: - r720xd w/ VMware ESXi 8.0 - Debian 13 - GTX 1080 - Nvidia (proprietary) Driver Version: 580.126.09 - CUDA Version: 13.0 - Docker version: 29.2.0 Note that I'm not affiliated with the project in any way, just trying to help. <img width="2434" height="1371" alt="Image" src="https://github.com/user-attachments/assets/91bf716a-87c7-4045-a5f9-f8e3a56a1145" /> <img width="2433" height="1366" alt="Image" src="https://github.com/user-attachments/assets/dfa23d5d-63e4-4103-9ff8-276f1bc5d0f2" />
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
games-on-whales/gow#91
No description provided.