Scan rework - preparatory changes

[zoltanvb]

Description

A batch of changes without changing the current behavior. Actual business logic changes will come in another PR soon(ish). The reason to send these earlier is to minimize the main PR content, in case it needs to be reverted.

Even though there are changes in several files, it is not visible - new menu items are not yet being created. But, to give a preview (and a bit of help for translators), it is planned to look like this:

• Scan Method: Automatic (same as previous autoscan) or Custom. Changing to Custom will display the extra options of the old manual scan + a few new ones:
• Database Check: strict (only content that matches DB will be added), loose (all files will be added, with DB reference if possible), custom DAT strict or loose (e.g. "filter DAT contents"), none (no DB scan, same as old manual scan)
• Database To Match: automatic (same as previous autoscan), automatic / first match only, or selected DB
• Target Playlist: old "System Name", it is much clearer to call it that
• Skip DB References: a fallback option if someone wants to match against DB but use own thumbnails directory
• Scan Single File: an option to cover previous "Scan File" functionality

Related Pull Requests

#18458
#18565

[i30817]

I hope this version will not have broken thumbnails by simply renaming the "target playlist" (system name) after scanning it.

multiple playlists for the same system are useful for cores that have multiple engines inbuilt (for instance scummvm), in order to keep separate different feels (like text only Vs graphics adventures), or overwhelming amounts of games (like AGS Vs everything else). This is currently not possible with the way scummvm playlists are built but that's not a inherent limit, indeed the CMD line tool I built that probably inspired that code (I certainly opened issues to copy it at the time) has the capability by filtering scummvm pathnames for different playlists created.

Currently as far as I can tell, System name is read only from from the playlists filenames when finding the libretro-thumbnails server directory and local cache dir.

Also my big issue about this explains how broken the manual scanner can get if you slightly deviate from the instructions of naming the games directory the system name.

I don't think it should be permitted at all to default the system name to the scanned directory, or even more strict, allow anything other than a existing database name or none in the expectation none means no thumbs at all, for those cases where a database/thumbnail server dir (o don't know what should have priority) doesn't exist.

[zoltanvb]

renaming the "target playlist" (system name) after scanning

Oh my. There is indeed a rename operation on the desktop interface (and nowhere else). I'll check how it behaves.

[i30817]

I believe the reason(TM) communicated for this design choice is to make the icons of the playlists load faster (by icons I think it was meant the emulated platform/system name specific icons that appear in the playlists tab not thumbnails), by not needing to parse a playlist for that name, just a filename.

It's unfortunate it breaks renaming/thumbnails and I'm not sure I agree with how easy it's to break manual scanner thumbnails, how the history/views don't use this design (history has a fixed filename and their thumbnails weren't broken because in them per game the system name is already there as db_name and it's obviously the reason that was introduced, but apparently the coder never went back to fix-up/replace the old method in other types of playlist) and how many other things around playlists access those files, not just them actually, I think time played and current m3u index are also saved and read from file.

Maybe this changed meanwhile, I was complaining about this 2 years ago, and haven't bothered renaming playlists since then.