Custom scan in the manual scanner should populate core_name and core_path entries per game

[i30817]

Is there an existing issue for this?

• This is a bug in RetroArch frontend
• I have searched the existing issues

Description

Well I'm actually advocating in another pr to remove this option altogether because it breaks thumbnails and game info (database), but there is a worse problem that can be fixed with the title I'm going to explain.

Custom playlists appended with multiple systems only really get the last emulator core associated.

By the way DETECT is a misleading name, it doesn't perform detection. I thought at first it would use db_name in the game entry to find the first core.info file with that db_name to get a core that way, but ofc that doesn't work (db_name in a custom scan is the playlist filename, ie: custom name).

I'd even suggest replacing db_name on a custom scan by doing a reverse lookup based on the core choosen to get a valid database. But unfortunately that won't work (there are cores that are multi system emulators that have more than one possible database, for instance a bunch of the Sony emulators are MS/GG/MD).

Expected behavior

To fix: when the manual scanner populates game entries with a custom scan it should always set core_path and core_name to default_core_path and default_core_name instead of DETECT. Custom can't guarantee that the last emulator core is appropriate to games except during a scan, so using DETECT to save space is wrong.

Steps to reproduce the bug

Use case:

1. A user wants to make a thematic playlist with games from multiple systems, sees custom and thinks it's for that
2. They scan two or more different system games directories with a custom name, overwrite to off and different emulator in each scan
3. They try to load games from the new playlist and those not from the last scan use the emulator from the last scan. Hang or crash

Version/Commit

1.22.2

Bisect Results

No response

Present in the nightly version

Yes, this is reproduced in the nightly build

Platform & operating system

android 15

Affected Cores

No response

Environment information

No response

Relevant log output

[i30817]

I got told that if you don't set a core in the scan, DETECT will ask for the core when selecting a game in the playlist.

I'd like to propose that in addition to copying core_path and core_name to per game entries newly created on a "custom" scan (if the core is set during that scan), that the default_core_name and default_core_path are set to empty so in a possible multiple system playlist, if the core is reset by the user, it always asks instead of running one that could be wrong.

That way refreshing Custom name playlists would go only slightly wrong (it would ask for the core all the remaining games).

[zoltanvb]

Checked the current operation. There are 2 settings for cores inside a playlist: one for each individual entry (this is normally added as "DETECT" during scan) and one playlist-wide default, this can be set up during the scan or be left empty.

Running an entry from the playlist, it will use the core associated with the entry itself, if it is set to Detect then it will use the playlist-wide default (and actually add it to the entry).

Custom playlists appended with multiple systems only really get the last emulator core associated.

In a way, yes. A multi-system playlist can still only have one playlist-wide default, and if previously added entries have not been started, they will still have DETECT as core. So, the request in the title makes sense in these cases, at the slight expense of yet one more option for the custom scan. I may look at that after #18641 is finalized and merged.

[i30817]

Why would you need even more options? The manual scanner already has too many options (some of them misleading) and I don't see anything here that requires even more.

Just make custom (and only custom) manual scans always set core_path and core_name for the entries scanned, if there is core chosen in the scanner, set those to DETECT if there is no core chosen in the scanner, and set default_core_path and default_core_name always to nothing (so any existing DETECT entries from for example this being a append scan get to be chosen at runtime by the user.)

People see "custom" and think "ah this is the multiplatform/thematic playlist" this is just removing traps from people trying to use it like that. Therefore, for custom the default_core_* settings should be empty, and core_* setting be set right away during the scan if possible, if not possible use DEFAULT for the user to be asked (this is the current behaviour with default_core_* settings to "" and detect core_*) no more and no less.

I didn't even mention db_name of those playlists since that requires UI changes (this is the root reason these playlists have broken thumbnails, the system name is put in core_name but it's wrong because in custom scans "custom system name", a setting used for nothing else but custom playlists btw, is used).

As db_name is per game, it could be different systems per game and I believe the thumbnails would work right away, considering if you rename one of the normal playlists thumbnails work even without a equivalent default_db_name).

[i30817]

If you want my real opinion (you probably don't) custom should be straight up deleted and explore views should completely replace it by guiding the users to them when they want to do thematic or multi system playlists. It would only take some better integration of views.

But in the meanwhile, if there are some simple ways to make custom less of minefield I could think of, why not. So this bug report

I don't get why do you want to add even more options to manual scan that was not my intention at all with this. It appears you think the current default is something people want so you need a new option. The current default is buggy and people think it's something it's not. I want this bug to be fixed by changing the behaviour of the scanner for custom in a transparent to users way, not adding a option to keep the bug and have a fixed option, that would be absurd.