Retroarch: CLI: Scan Directory/File

[RobLoach]

Description

Allow scanning directories of files from the command line interface. This is from @skpy over at https://github.com/libretro/Lakka-LibreELEC/issues/182 .

Expected behavior

Have the ability to run something like the following to scan and add to the playlists:

retroarch --scan-directory="path/to/dir"

Actual behavior

Right now, in order to create playlists, the user must add the directories manually. Would be nice to have the ability to set up a script to trigger retroarch --scan-directory to create the playlists so that users wouldn't need to do it manually.

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1cf6f2f20f496e4e21d59d54ac93977ceda00aec

Environment information

• OS: Linux
• Compiler: gcc

[hizzlekizzle]

I'm not really seeing the benefit of this. Playlists only work through the GUI, so there shouldn't be any point at which a user wants to use a playlist but isn't in a position to create them. Right??

[RobLoach]

Correct, this is just about creating the playlists from the command line. You'd go into the menu to use them, this is just a handy tool to trigger the Scan Directory function from the command line.

[i30817]

This would be much more valuable if 'methods' could be specified so specializations of the scan not based on file crcs could happen.

Scummvm will soon be able to be given a absolute path and return a 'yes it's this game' or 'no it isn't a game' and this would be much much better than asking users to create hundreds of files, one for every game scummvm supports. Scummvm returns string, 'scummvm-method' find in (string->metadata) mapping and associates path to metadata.

Another case where specialization would be useful: the dreamcast TOSEC set is the best for actually playing because it hasn't some of the known dumping problems redump has on dreamcast (broken audio) but it's full of duplicate crcs because the .gdi files have often the same contents (they named the tracks the same) and they're used as rom crcs. One way to avoid the false positives would be to have a filename->metadata mapping and associate the .gdi to metadata and remove TOSEC dreamcast .gdi from the main 'crc' databases and use this mapping instead.

These hypothetical better methods being selectable individually, or to at least per core so they can be tried sequentially without the performance drain and false positives of all the rest would be great for people who know what they're doing. I'd like to have actually working dreamcast metadata, or not need to create or move files to random dirs in order to have a playlist.

I honestly understand the appeal of a single scan method for everything, but at least for me, with 1TB+ of various games, it's already unsustainable. I have to wait several hours to make a scan (if i try it all at once) and the result is subpar in various respects. If it was easy to create (for the devs) and use specialized methods, even if they weren't used on the main scan for performance reasons, i'm sure advanced users would be grateful.

[bparker06]

With large folders this would be awfully slow (and a waste) if you're just adding a new file here and there. Something that watches the filesystem for new content that's not already in the playlist, and then only scans that, would be more appealing IMO. A cross-platform version of something like this would be nice.

[kivutar]

Playlists are also used for netplay, it can be useful if we make a CLI version of the netplay lobbies

[paperbenni]

+1 for this idea, I'd like to automate scanning for my lakka station.

[r37r0m0d3l]

Still no progress?

[RobLoach]

No. If anyone picks this up, there'll be comments. Feel free to have a hack at it! There's been a bunch of new additions for playlist management in the UI.