Description
Is there an existing issue for this?
- This is a bug in RetroArch frontend
- I have searched the existing issues
Description
This is a restatement of #16031 which I closed because I believe I have a better idea for the solution now.
First, the problem:
RetroArch uses the playlist filename minus extension as a path component to find the database file, local downloaded thumbnail dir, and server remote thumbnail dir.
This causes RetroArch to lose track of where thumbnails are if the playlist is ever renamed, and the manual playlists can end up renamed from origin by choosing a nonexistent system name (often by accident because of the default "directory name").
This information is also duplicated as "db_name" in each game entry, presumably so the history playlist items are constructed slightly more easily. This is bad idea that should be changed too, because some playlists can reach 20, 30 mb (C64 tosec) and all playlists would be much smaller without those repeated lines per game entry.
If that info was a single "system name" property of the playlist and when constructing the history playlist entries they added that to the game entries, and the parts of RetroArch that still use the filename are updated to use that property instead (thumb download path, thumb server path, database file), the filename could be changed without affecting thumbnails or the database.
Instead, this was never fixed.
The problem became more notable when the manual scanner was created because it allows users to change the playlist database\thumbnail dirs (and thus its filename) from the scan options, worse the default of the option is "directory name" so if you don't name your directory scanned exactly the name of the database RA expects for the games in there, you get no thumbnails with the default option.
Changing the playlist filename is actually useful (to separate thematically similar games from a single core\system and different scan dirs), the database\thumbnail dirs to a custom one not so much.
But both options could have been decoupled at the time by adding a new optional option "playlist name" to the creation options (this would change the filename only obviously, the default would be the chosen system name), and change up "system name" to make it obligatory - but crucially without a default when opening the scan so the user is forced to choose the correct one. If the user wrote a custom playlist name, then you have a new option in system name "none" (this is to accommodate RetroArch platforms\cores without databases\thumbnails, without confusing users). You're always forced to chose one if the menu isn't already setup with one (from 'refresh playlist' then going into the menu, which is another behaviour that should be systematized in #18013 ).
Then you can remove the custom and directory name options. That new "system name" property should be also in the non manual normal scanner playlists so those can also be renamed, get into the history playlist and become smaller size, without affecting anything after the refactor.
This would:
- prevent a lot of people getting confused about why they have no thumbnails with the manual scanner if they just thoughtlessly chose a dir then press scan, by then getting prompted to choose a system name without the trap options (although there should be visible information that choosing a custom playlist name means it's highly recommended to choose a system name instead of None, for the few that do without understanding - the difference is that None would not be there by default without editing playlist name from the default, so fewer would fall for this, and with the info right there, even less)
- free up other parts of RetroArch to eventually make custom named playlists without losing thumbnails (explore tab creating custom theme playlists organized a bit like the history playlist -because they could be from multiple systems- for example)
- free up users to make custom named playlists\rename playlists and keep thumbnails, which is a feature that is often requested, but broken afaict. From inside RetroArch (which is impossible right now) or outside (which is tricky right now without a external app but would be much simpler if this was implemented)
- make playlists smaller (except history)
Expected behavior
No response
Steps to reproduce the bug
- use the manual scanner with default options in a dir not named one of the RetroArch system database names but containing valid system database games.
- scan like a luser
- get no thumbnails because the UI defaults and several options in system name are traps.
Version/Commit
1.19.1
Bisect Results
No response
Present in the nightly version
I don't know
Platform & operating system
Android aarch64
Affected Cores
No response
Environment information
No response