Allow creating multiple playlists per subdir or engine

[i30817]

Some engines in scummvm are shapping up to have hundreds of even thousands of games (ags, director, interactive fiction), and some stable engines already have dozens.

It would be helpful if the user could divide the games into thematic or engine playlists from the core playlist creator tab.

Disadvantages:

1. You lose the playlist icon if you allow the user to choose the name (if you go with the engine idea instead of a subpath idea you could make the user select one of a limited set of options and work out a icon with libretro upstream I guess). Unfortunately there is currently no way in libretro to have a particular icon in a playlist regardless of the name of the playlist file, because the API was never extended for it and the main program doesn't want to open playlists just to display icons in the playlist tab. A extension for this like a ignored part of the filename, aux file (already used to keep selected disc in multi disc entries for m3u) or sub extension could be done if you can convince libretro with code in hand. Note that libretro probably uses the playlist name as a part of the filename to find the database and icons already, and there are options to ignore the part of the playlist name before '-' if any in the GUI. With that a playlist with any (displayed) name could have the scummvm icon and database associated.
2. If using the path approach you'd need a extra way to select a name for the playlist and a path in the scummvm playlist generation feature, if using the engine approach a slider would suffice, either way, more code and if you want icons, more work elsewhere.

I don't recall if this core feature supports portable playlists if that setting is on already, but it's pretty much required imo.

[i30817]

There are alternatives upstream could do if I had any faith in upstream and specifically libretro database. A way to use the explore tab (that depends on libretro-database) to create playlists from filters would serve the same idea with more and better flexibility, by specifying scummvm, ags filters for instance, then saving that as a playlist.

Unfortunately libretro-database can't identify 50% of even basic console ROMs in manual playlists (even if those roms are valid redump\nointro), much less things like scummvm games. Even without manual playlists, since libretro uses serials to identify games (thereby identifying TOSEC games as redump for example) it is rather easy to end up with multiple instances of the 'same' game with softpatching, or end up with unknown games lost into the void. With Scummvm which doesn't have that problem you instead have the alternative problem that the way libretro-database "identified" a scummvm game was placing the simplified engine name entry from scummvm. cfg into a text file and using that filename as a entry, the exact thing that the core playlist option was made to run away from, because it requires absurd effort from users.

I suppose that instead something like inversion of control would be needed, with the core providing information about which game in the database a entry is, presumably with a foreign key in the playlist somehow, or just the game name and changing the explore tab to use that (and add the create playlist feature).

Frankly I think it's hopeless without taking ownership of the maintainance of the explore feature, which like many many libretro\retroarch features is bitrotting away, so I'm not proposing it as a serious ask.

[spleen1981]

Hi, the current playlist generation tool had the only purpose of transfering a scummvm launcher list to a standard retroarch playlist, providing a smooth and automatic link between the two, and this is what actually does, nothing more nothing less.

The only reason why this playlist handling feature has been added to the core source is to actively use the internal scummvm detection engine and link each playlist entry to scummvm possible per-game settings, which would be not accessible from outside the core otherwise.

Say that, any other additional advanced playlist management feature is out of the scope of the core.

In any case the (very specific and complicated) use case above, is not following scummvm nor retroarch game lists standard approach, and actually is not specific to the scummvm core itself, as such requirements may be applied to any core. I think that if I had such needs, I would generate a playlist and clean/split manually the generated lpl as needed. Being a one-time operation probably the effort of coding an automated solution is not worth at all.

Otherwise if one had the will of coding this, an external advanced playlist generator/manager would be the way, to be maintained separately from the cores and actually applicable to any libretro playlist kind (assuming that something isn't already out there).

[spleen1981]

Regarding the current scummvm libretro database, I would drop it completely, as totally unrelated to the internal scummvm detection system. It is already discussed here https://github.com/libretro/scummvm/issues/71#issuecomment-2452941124

if I had any faith in upstream and specifically libretro database.

I'm sure that if one proposes a good alternative it would be considered by the maintainers. For example, once dropped the current database, an alternative could be considering only the .scumvm files and parsing their content vs the standard scummvm game-ids (and all language or other possible variations). But in any case the database solution would be sub-optimal and subject to continuous mainteinance, and not covering the case of custom game-ids, so I would not waste time in that direction and just use the core internal generator (+ any additional external customization is required).

[i30817]

As someone that has a collection of about 900 AGS games which are all freeware and can all be gotten from a single torrent, I disagree with the idea this is specific. I find bloated scummvm playlists a very common problem to have.

The current scanner is ofc much better than before (I actually have a project that does essentially the same thing and can produce multiple playlists using the path filtering\different name approach, so this is a issue for other people more than me), and you can do something similar with the manual scanner for other cores if you explore the options and avoid the traps. It's just this core other people would have little idea about the alternative.

I think that connecting a playlist entry to libretro-database and add the feature to save playlists from explore is not a lost cause too, but it seems much more involved, requiring coding in RetroArch and the playlist reading and writing formats and routines. In short, if the explore feature had a option or default to use a game entry name + the system name, as the foreign key to fetch information about a game it would work with manual scanner playlists and with this core created playlists. After that, just add a feature to save a hybrid playlist (like the history playlist which has the cores used in the entries).

[spleen1981]

I'm not against advanced playlists management, just this topic does not belong to the core. It's in the frontend scope (so a possible feature request should be redirected there), and the only reason why a basic feature is included in the core is explained above. The internal tool will just produce the same list you have in the standalone scummvm launcher, hence if that is bloated the playlist will be bloated as well.