gh-SvenGDK/RetroMultiTools
Watch
1
0
Fork
You've already forked RetroMultiTools
 0
Code Issues 9 Pull requests Releases 6 Activity

macOS RetroArch manually setting path / pointing at .app file does not recognize it. #2

New issue
Open
opened 2026-03-15 05:06:48 -05:00 by networked47 · 12 comments
networked47 commented 2026-03-15 05:06:48 -05:00 (Migrated from github.com)

Mac Mini M2 Pro
macOS: 26.3.1 (25D2128)

To replicate:

  • Have RetroArch installed in non-standard location
  • Open RetroMultiTools
  • Go to Settings
  • Click Auto-Detect on RetroArch Integration
    (returns: RetroArch not found. Please browse manually or download it)
  • Click Browse
  • Navigate to where RetroArch.app i located
  • Click OK.
    (no chaange in Path box)
  • or double click on .app
    (no change in Path box)

As a consequence Core Downloader does not work as expected.

Mac Mini M2 Pro macOS: 26.3.1 (25D2128) To replicate: - Have RetroArch installed in non-standard location - Open RetroMultiTools - Go to Settings - Click Auto-Detect on RetroArch Integration (returns: RetroArch not found. Please browse manually or download it) - Click Browse - Navigate to where RetroArch.app i located - Click OK. (no chaange in Path box) - or double click on .app (no change in Path box) As a consequence Core Downloader does not work as expected.
SvenGDK commented 2026-03-17 15:35:27 -05:00 (Migrated from github.com)

Mac Mini M2 Pro macOS: 26.3.1 (25D2128)

To replicate:

  • Have RetroArch installed in non-standard location
  • Open RetroMultiTools
  • Go to Settings
  • Click Auto-Detect on RetroArch Integration
    (returns: RetroArch not found. Please browse manually or download it)
  • Click Browse
  • Navigate to where RetroArch.app i located
  • Click OK.
    (no chaange in Path box)
  • or double click on .app
    (no change in Path box)

As a consequence Core Downloader does not work as expected.

The .app should now be detected in v2.0, there was an issue that prevented taking the .app in account.

> Mac Mini M2 Pro macOS: 26.3.1 (25D2128) > > To replicate: > > * Have RetroArch installed in non-standard location > * Open RetroMultiTools > * Go to Settings > * Click Auto-Detect on RetroArch Integration > (returns: RetroArch not found. Please browse manually or download it) > * Click Browse > * Navigate to where RetroArch.app i located > * Click OK. > (no chaange in Path box) > * or double click on .app > (no change in Path box) > > As a consequence Core Downloader does not work as expected. The .app should now be detected in v2.0, there was an issue that prevented taking the .app in account.
networked47 commented 2026-03-17 15:55:06 -05:00 (Migrated from github.com)

I stil get the same error.

Way to replicate is the same.

However I have an idea, since the .app is a container for the files and the executrable, and when either double-clicking on the .app or clicking open on the dialog closes the window, it never really 'opens' the .app for navigation to the Contents/MacOS structure and thus fails in the detection.

(on note: using the self-contained installer)

I stil get the same error. Way to replicate is the same. However I have an idea, since the .app is a container for the files and the executrable, and when either double-clicking on the .app or clicking open on the dialog closes the window, it never really 'opens' the .app for navigation to the Contents/MacOS structure and thus fails in the detection. (on note: using the self-contained installer)
SvenGDK commented 2026-03-17 16:18:11 -05:00 (Migrated from github.com)

I stil get the same error.

Way to replicate is the same.

However I have an idea, since the .app is a container for the files and the executrable, and when either double-clicking on the .app or clicking open on the dialog closes the window, it never really 'opens' the .app for navigation to the Contents/MacOS structure and thus fails in the detection.

(on note: using the self-contained installer)

That's strange, just tested it again with latest RetroArch build on my MBP with 10.15 (Catalina) and it get's auto-detected from /Applications/RetroArch.app/Contents/MacOS/RetroArch

> I stil get the same error. > > Way to replicate is the same. > > However I have an idea, since the .app is a container for the files and the executrable, and when either double-clicking on the .app or clicking open on the dialog closes the window, it never really 'opens' the .app for navigation to the Contents/MacOS structure and thus fails in the detection. > > (on note: using the self-contained installer) That's strange, just tested it again with latest RetroArch build on my MBP with 10.15 (Catalina) and it get's auto-detected from /Applications/RetroArch.app/Contents/MacOS/RetroArch
networked47 commented 2026-03-17 16:21:36 -05:00 (Migrated from github.com)

I do have it installed in another path, it's the first step in my "how to replicate".

That the auto-detect doesn't find it I completely accept, unless it were to do a scan of the disk and all attached volumes. And that would be silly.

But since you can point out a path, I used that and that part doesn't work/fails to find it, even when pointed out the path or the .app file.

I do have it installed in another path, it's the first step in my "how to replicate". That the auto-detect doesn't find it I completely accept, unless it were to do a scan of the disk and all attached volumes. And that would be silly. But since you can point out a path, I used that and that part doesn't work/fails to find it, even when pointed out the path or the .app file.
SvenGDK commented 2026-03-17 16:22:59 -05:00 (Migrated from github.com)

I do have it installed in another path, it's the first step in my "how to replicate".

That the auto-detect doesn't find it I completely accept, unless it were to do a scan of the disk and all attached volumes. And that would be silly.

But since you can point out a path, I used that.

Yes I edited after reading again and could reproduce the bug, I first tought manually choosing and pressing auto-detect would resolve the manually selected path but it doesn't. Will fix this.

> I do have it installed in another path, it's the first step in my "how to replicate". > > That the auto-detect doesn't find it I completely accept, unless it were to do a scan of the disk and all attached volumes. And that would be silly. > > But since you can point out a path, I used that. Yes I edited after reading again and could reproduce the bug, I first tought manually choosing and pressing auto-detect would resolve the manually selected path but it doesn't. Will fix this.
🎉 1
SvenGDK commented 2026-03-17 16:39:05 -05:00 (Migrated from github.com)

I do have it installed in another path, it's the first step in my "how to replicate".

That the auto-detect doesn't find it I completely accept, unless it were to do a scan of the disk and all attached volumes. And that would be silly.

But since you can point out a path, I used that and that part doesn't work/fails to find it, even when pointed out the path or the .app file.

There's a temporary fix that should accept your custom RetroArch installation path :

  1. Open the file /Users/YOURUSERNAME/Library/Application Support/RetroMultiTools/settings.json
  2. Find the "RetroArchPath" entry and add your custom RetroArch.app path between "" like "/Users/svengdk/Downloads/RetroArch.app/Contents/MacOS/RetroArch"
  3. Restart RetroMultiTools
> I do have it installed in another path, it's the first step in my "how to replicate". > > That the auto-detect doesn't find it I completely accept, unless it were to do a scan of the disk and all attached volumes. And that would be silly. > > But since you can point out a path, I used that and that part doesn't work/fails to find it, even when pointed out the path or the .app file. There's a temporary fix that should accept your custom RetroArch installation path : 1. Open the file **/Users/YOURUSERNAME/Library/Application Support/RetroMultiTools/settings.json** 2. Find the **"RetroArchPath"** entry and add your custom RetroArch.app path between "" like **"/Users/svengdk/Downloads/RetroArch.app/Contents/MacOS/RetroArch"** 3. Restart RetroMultiTools
networked47 commented 2026-03-26 15:08:01 -05:00 (Migrated from github.com)

This continues. In version 4 now.

  • Auto Detect will not detect in, and when selecting manually, I cannot even select the .app file.
Image

I tried the "All Applications" also, then I could select, but nothing happened.

This continues. In version 4 now. - Auto Detect will not detect in, and when selecting manually, I cannot even select the .app file. <img width="707" height="184" alt="Image" src="https://github.com/user-attachments/assets/aa7f7c3a-57b7-43d8-965b-56c996aba5d1" /> I tried the "All Applications" also, then I could select, but nothing happened.
SvenGDK commented 2026-03-27 06:06:40 -05:00 (Migrated from github.com)

This continues. In version 4 now.

  • Auto Detect will not detect in, and when selecting manually, I cannot even select the .app file.
Image I tried the "All Applications" also, then I could select, but nothing happened.

This is why it's still marked as "bug". The source of this bug comes from Avalonia Issue #18080 & Issue #18303 that doesn't allow selecting .app from a FilePicker (but it should for macOS).

I will provide a small update soon that will add a workaround for this issue, including the application menu still not showing on macOS.

> This continues. In version 4 now. > > * Auto Detect will not detect in, and when selecting manually, I cannot even select the .app file. > > <img alt="Image" width="707" height="184" src="https://private-user-images.githubusercontent.com/45419068/570021947-aa7f7c3a-57b7-43d8-965b-56c996aba5d1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzQ2MDk2MTQsIm5iZiI6MTc3NDYwOTMxNCwicGF0aCI6Ii80NTQxOTA2OC81NzAwMjE5NDctYWE3ZjdjM2EtNTdiNy00M2Q4LTk2NWItNTZjOTk2YWJhNWQxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjAzMjclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwMzI3VDExMDE1NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTMxMzYyY2Q2MzZmYWFhYjQ5MTFjOTk5YTRmYzJhY2FhNmVhYjdiNWI0OTBmMmEyY2QwNGYwNGJkYjQ4NTI4MzcmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.wsJgdyQGXqIn_ocK6mTAt86VNZM9ylUG1_VGYfEPr9s"> > I tried the "All Applications" also, then I could select, but nothing happened. This is why it's still marked as "bug". The source of this bug comes from Avalonia [Issue #18080](https://github.com/AvaloniaUI/Avalonia/issues/18080) & [Issue #18303](https://github.com/AvaloniaUI/Avalonia/issues/18303) that doesn't allow selecting .app from a FilePicker (but it should for macOS). I will provide a small update soon that will add a workaround for this issue, including the application menu still not showing on macOS.
SvenGDK commented 2026-03-27 10:43:21 -05:00 (Migrated from github.com)

Can you please try out with v4.1 again. Simply select the folder that contains the RetroArch.app if you can't select the .app by itself.

Can you please try out with v4.1 again. Simply select the folder that contains the RetroArch.app if you can't select the .app by itself.
networked47 commented 2026-03-28 07:30:07 -05:00 (Migrated from github.com)

Can you please try out with v4.1 again. Simply select the folder that contains the RetroArch.app if you can't select the .app by itself.

Tried with 4.1 and, well.. I don't know how to say this but it works bt doesn't. I'll explain.

  • Auto Detect still doesn't work, that is expected.
  • I can point it at the directory, and the dialog updates with a filename.app and saus that RetroArch has been located.
  • I can see what cores I have, and it lets me download missing cores, apart from 2 that I don't think exist anymore/are somewhere else.

However there are two issues:

  1. The .app being displayed in the path box is not RetroArch, but the first .app file I have in that directory, I thought this was jsut a display issue.
  2. When launching, it is trying to use that .app, resulting in an error from that .app file.
Image
> Can you please try out with v4.1 again. Simply select the folder that contains the RetroArch.app if you can't select the .app by itself. Tried with 4.1 and, well.. I don't know how to say this but it works bt doesn't. I'll explain. - Auto Detect still doesn't work, that is expected. - I can point it at the directory, and the dialog updates with a filename.app and saus that RetroArch has been located. - I can see what cores I have, and it lets me download missing cores, apart from 2 that I don't think exist anymore/are somewhere else. However there are two issues: 1. The .app being displayed in the path box is not RetroArch, but the first .app file I have in that directory, I thought this was jsut a display issue. 2. When launching, it is trying to use that .app, resulting in an error from that .app file. <img width="537" height="185" alt="Image" src="https://github.com/user-attachments/assets/144d5c66-f059-4a9d-9b11-47e9da8baefe" />
SvenGDK commented 2026-03-28 17:42:29 -05:00 (Migrated from github.com)

Ok, I think I got it now with better filtering. The fix will be included in upcoming v5.0 release.

Ok, I think I got it now with better filtering. The fix will be included in upcoming v5.0 release.
networked47 commented 2026-03-30 14:25:41 -05:00 (Migrated from github.com)

Verified with 5.0 Release.

  • RetroArch is being correctly identified on folder level.
  • RetroArch is launched when requested from context menu with correct core.
Verified with 5.0 Release. - RetroArch is being correctly identified on folder level. - RetroArch is launched when requested from context menu with correct core.
👍 1
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v5.0.0
v5.0
v4.1.0
v4.0
v3.0
v2.0
v1.0
Labels
Clear labels   
bug
Something isn't working

  
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
enhancement
New feature or request

  
good first issue
Good for newcomers

  
help wanted
Extra attention is needed

  
invalid
This doesn't seem right

  
question
Further information is requested

  
wontfix
This will not be worked on

No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
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
gh-SvenGDK/RetroMultiTools#2
No description provided.