There has been discussion in the past about what an enhanced playlist format should look like, but I think anyone has put forward a specific recommendation yet. I’m writing this in the hopes of sparking productive discussion about what the new format should look like and ways that a more flexible playlist format could improve RetroArch.
Prologue: An Important Assumption
Per comments from Twinaphex, a new playlist format would need to co-exist with the existing format. This proposal is based on the assumption that the playlist parser would be modified to switch based on whether a v1 playlist or a v2 playlist was being loaded.
Because this proposal uses a minimal xml format, logic for playlist detection could be as simple as:
File fp = open_file(playlistname); char firstchar = get_char(fp); if(firstchar == "<") // XML format detected parse_xml_playlist(fp); else // v1 playlist parse_v1_playlist(fp);
Alternately, if the new playlists were given a different file extension than
lpl, that could be used to determine which parser to use.
This minimum viable implementation should, at least, accomplish the following improvements from the current (v1) playlist format:
- Allow the specification of arbitrary thumbnail paths on a per-playlist-entry basis, addressing deduplication issues with the thumbnail repository and making it possible to display thumbnails from the “History” playlist.
- Allow new tags to be added in the future without breaking the playlist file format
Minimal playlist v2 example:
<?xml version="1.0"?> <playlist> <playlist_entry name="Legend of Zelda, The - Ocarina of Time (USA)"> <content_path>storage/roms/n64/Legend of Zelda, The - Ocarina of Time (USA).n64</content_path> </playlist_entry> </playlist>
Equivalent to this v1 playlist:
/storage/roms/n64/Legend of Zelda, The - Ocarina of Time (USA).n64 Legend of Zelda, The - Ocarina of Time (USA) DETECT DETECT DETECT DETECT
Each playlist file should have at minimum one
playlist with at least one
playlist_entry within it. Each
playlist_entry should have at minimum:
nameas an attribute within the parent
content_pathas a child tag
This could be left optional. attributes specified within the root
playlist would be per-playlist defaults. When a
playlist_entry specifies the same parameter as a global parameter in
playlist_entry overrides the global setting for that item only.
More complex example
This example imagines some tags that could be implemented in the future.
<?xml version="1.0"?> <playlist> <playlist_icon>/tmp/assets/xmb/funky-n64/console_delight.png</playlist_icon> <content_icon>/tmp/assets/xmb/funky-n64/cartridge_delight.png</content_icon> <core_path>/tmp/cores/mupen64plus_libretro.so</core_path> <shader_path>/tmp/shaders/some_great_n64_shader.glsl</shader_path> <playlist_entry name="Legend of Zelda, The - Ocarina of Time (USA)"> <content_path>storage/roms/n64/Legend of Zelda, The - Ocarina of Time (USA).n64</content_path> <thumbnail_path>/tmp/assets/thumbnails/n64/Legend of Zelda, The - Ocarina of Time (USA)</thumbnail_path> </playlist_entry> <playlist_entry name="Legend of Zelda, The - Ocarina of Time (EUR)"> <content_path>storage/roms/n64/Legend of Zelda, The - Ocarina of Time (EUR).n64</content_path> <shader_path>/tmp/shaders/some_great_n64_shader_PAL_version.glsl</shader_path> <content_icon>/tmp/assets/xmb/funky-n64/euro_cartridge_delight.png</content_icon> <thumbnail_path>/tmp/assets/thumbnails/n64/Legend of Zelda, The - Ocarina of Time (USA)</thumbnail_path> </playlist_entry> </playlist>
Full list of basic
playlist_entry and global tags
nameas an attribute)
content_crc(exists in RetroArch DB)
content_sha1(exists in RetroArch DB)
content_md5(exists in RetroArch DB)
content_serial(exists in RetroArch DB)
Possible additional tags
user_rating(rated by the user, within RetroArch)
From existing RetroArch
developer(as a child
<developers>as nested strings, mirroring the RA DB)
Possible new tags inspired by the EmulationStation gamelist.xml format
playcount- statistic, integer, the number of times this game has been played
lastplayed- statistic, datetime, the last date and time this game was played.
kidgame- does not have any mature/adult content