Nested Playlists Feature #18006
Nested Playlists Feature #18006
Conversation
…quested at certain forums. The feature may be tested by creating an entry within an existing playlist having a "core_path" of "virtual", "core_name" of "playlist", and "path" pointed to any existing playlist. The feature works by reusing certain mechanisms, notably the generic RPL and COLLECTION processing, that were already in place. I have though added a FILE_TYPE, MENU_ENUM_LABEL, DISPLAYLIST, and ACTION setup unique to the feature in order to avoid what I considered to be contamination; I wanted to avoid hacks that, while simpler, would have made the feature harder to debug separately from the existing code.
I am, however, open to any constructive feedback.
I fixed a display bug related to thumbnails and titles in this version; the
titles were showing the wrong information thanks to the nested playlists
being treated as a `Quick Menu` at the wrong time; the thumbnails did not
display correctly in all cases thanks to differences between menu drivers.
The functionality is identical to the original patch, but the names of certain
identifiers have changed to better reflect the standard set by upstream code.
The feature has been kept, mostly, small and isolated by simply reusing
existing code in a slightly different way than it is currently used.
A note about the feature request: the often requested feature has obvious
utility for people who create custom playlists; the feature could also be
used to generate flat playlists or nested playlists depending on a flag
in scanning; the optional nested playlists could be generated from
information contained within the databases allowing games for a given
system to be broken up by, for example, country of origin.
A note about the different menu drivers: an update from a few weeks back broke
part of my original private version; that update, related to thumbnail cycling
and the then new random selection feature, changed when thumbnails are displayed
for certain core types; this patch partially reverts that change to prepare for
a future additional feature I've begun working on which would allow people to
use RetroArch as more of a general media player with thumbnail generation using
the, often internal, `ffmpeg` core; the history and favorites menu should at
least offer the opportunity to display thumbnails, in any event, for custom
playlists which can have thumbnails for any media type.
I've included a sample playlist trunk below; the core's path and name are
important and fixed, but the path to the playlist may be set as desired.
{
"version": "1.5",
"default_core_path": "",
"default_core_name": "",
"label_display_mode": 0,
"right_thumbnail_mode": 0,
"left_thumbnail_mode": 0,
"thumbnail_match_mode": 0,
"sort_mode": 0,
"items": [
{
"path": "/home/username/temporary/branch.lpl",
"label": "Branch",
"core_path": "virtual",
"core_name": "playlist",
"crc32": "",
"db_name": "Trunk.lpl"
}
]
}
|
@sonninnos you're probably the most familiar with and invested in the current behavior and the implications of any changes. Got any thoughts? |
|
modifying playlists format is something I think should be made to walk before running. For instance, you can't even rename a playlist without nuking thumbnail downloads (or at least, you couldn't a few years ago last I bothered to investigate this). You also can't have the system icon if you rename a playlist from the system name of the database ra expects. Both of these are caused by failures of the playlist schema using the filename instead of a property inside them (or outside them as I will explain something in a bit). For the images, in spite of you needing to find\specify a system name in the (automatic\manual) scanner, and those ending up as entries in game entries not just the whole file (for some reason, probably hard coded for the history file thumbnails) they're not used like that for normal thumbnail playlist downloads for some reason, but the filename. Result: users that screw up and use the manual scanner default options with the "wrong" directory names or a custom directory name end up with no thumbnails possible to view or download. I reported this bug, oh, 5 years ago or so. Ignored. :P The other case of the system icon in the playlist, I was told it was because the devs didn't want to have to parse all the playlists just to get icons to show them in the playlists tab. Fair enough, but alternatives like smaller playlist aux files (like the one that memorizes the index iirc) were also ignored. |
|
I also want to mention that if the tag system of RetroArch wasn't such a incomplete disaster that barely functions with the manual scanner, can't do Ands and Ors and Nots, and has so few useful metadata, it would be a much superior way to let users make custom playlists. can you imagine: "action-aventure and !child-protagonist" then a button to "save as playlist"? Pity that of the few game it does characterize, it requires the automatic scanner for some godforsaken reason (instead of filename minus extension + system), and actually useful tags like that "child-protagonist" (or male or female or ...) aren't in the things that the scrappers the data comes from used (I'm partial to the tag system of hardcoregaming101¹ but anything is better than mobygames or whatever that is, tags that categorize game specifics instead of genres of all things - and genres are often highly misleading with the popularity of hybrids since the freaking 90s, Actraiser for instance). ¹ for instance these are the tags for metal gear solid there: Action: Top-Down View, Espionage / Spy, Hideo Kojima, Konami, Sony Playstation, Stealth, Windows so much better than just "Action", though I'd honestly prefer even more like "mecha; post-cold-war-mlitary; male-protagonist; conspiracies; psionics; 90s; mercenaries; postmodern(self-referencial); larger-10-minutes-cutscene" etc. |
|
The approach I've used doesn't change the playlist format. I'm not doing nested playlists by using features of the JSON format of something like that. I'm pointing a playlist to another playlist using a field of the existing playlist format and what is basically a virtual core. |
|
If you implemented this I'm sure you know, but RetroArch playlists are not just json files, theyre a (informal) schema. It's true you can special case one type of them for special usage or display, for instance, the manual scanner created playlists have more information than the history or automatic scanner playlists and so can be "rescanned", and "refreshed"¹, the history playlist is just a list of the entries of the other two without the rest of the properties etc. in short, I think this approach of making another schema that gets placed in the same UI tab\same directory as normal playlists (that already have two different schemas, manual and automatic scanner created playlists) complicates things for no reason, and will also break 3rd party tools that depend on processing playlists in that specific directory and now would have to figure out "this isn't actually a games list" and (for instance) 'finding genres or thumbnails for this is meaningless'. I'm saying this not because it's a coincidence, but because I implemented one such tool and I'm sure I'm not the only one (well actually two but one got almost outdated by the core using the idea... except mine can make different playlists for different scummvm games per the directory they are in - a way to separate engines from scummvm in different playlists actually). ¹ (the difference is that since RetroArch is... bad at c string hygiene you can as a user refresh a manual playlist then go into the manual scanner and all the options will be filled with the settings of the playlist for you to tweak - useful but probably not intended lol). |
|
Also, I don't hate the idea of making thematic playlists easier to make, but I personally think introducing a playlist that nests other playlists... doesn't help with that? It doesn't help users make the thematic playlists like connecting the tag system to playlist filtering->save as playlist would (if the tag system was good anyway) and for the people who do playlists by hand... what's the advantage? Just less playlists appearing in the playlist tab with another level of indirection? At the cost of breaking 3rd party tools that could\can create those same playlists until they're updated (or massage other properties of playlists, like my fuzzy thumbnails project). I don't think a level of indirection is worth breaking third party tools, and I kind of suspect this is a XY problem where what most people actually want is a way to make the thematic playlists not by hand, not nest them after painstakingly creating them by hand. Sure it's probably annoying to see all the genres that, for instance, mame roms can be in, but is it really worth it to introduce such a clumsly workaround as ignore entirely how RA wants playlists to be accessed in the drivers, and potentially break the tools creating those custom playlists ? To be constructive, and if the aim is to seperate the system playlists from thematic playlists, I actually think you'd be better off implementing another, optional tab in drivers with a seperate directory and directory setting and using the same code as the normal tab but when the user dumps playlists in a directory appart (made by hand, or in the future hopefully not - tag search playlists placed there could also be 'refreshed' like the manual playlists if that was coded) the tab automatically appears and display those playlists as part of a seperate tab. I highly suggest you fix the bug I mentioned about thumbnails being sabotaged in custom named playlists (that are not the history playlist that appears to work correctly by fetching the info from the game entry instead of the playlist filename - which changes) first because your thematic thumbnails would have custom names (if you want more detail read this post I just spat out from disgust at RetroArch 10 year old bugs if you want to know exactly what's wrong here: #18012) |
|
@kaysedwards hey man, are you on discord? If so, would you mind popping in there to discuss? |
|
I am now. I'm waiting on my ten minutes to expire before I can post. |
I've implemented a feature to allow nested playlists that I've enjoyed in my private build for years which I hope can be merged to fulfill the repeated requests I've seen across various various forums.
I've included the release note below for the sake of simplicity as I tried to include there all the relevant information.
I've hopefully completed the nested playlists feature with this version.
I am, however, open to any constructive feedback.
I fixed a display bug related to thumbnails and titles in this version; the
titles were showing the wrong information thanks to the nested playlists
being treated as a
Quick Menuat the wrong time; the thumbnails did notdisplay correctly in all cases thanks to differences between menu drivers.
The functionality is identical to the original patch, but the names of certain
identifiers have changed to better reflect the standard set by upstream code.
The feature has been kept, mostly, small and isolated by simply reusing
existing code in a slightly different way than it is currently used.
A note about the feature request: the often requested feature has obvious
utility for people who create custom playlists; the feature could also be
used to generate flat playlists or nested playlists depending on a flag
in scanning; the optional nested playlists could be generated from
information contained within the databases allowing games for a given
system to be broken up by, for example, country of origin.
A note about the different menu drivers: an update from a few weeks back broke
part of my original private version; that update, related to thumbnail cycling
and the then new random selection feature, changed when thumbnails are displayed
for certain core types; this patch partially reverts that change to prepare for
a future additional feature I've begun working on which would allow people to
use RetroArch as more of a general media player with thumbnail generation using
the, often internal, ffmpeg core; the history and favorites menu should at
least offer the opportunity to display thumbnails, in any event, for custom
playlists which can have thumbnails for any media type.
I've included a sample playlist trunk below; the core's path and name are
important and fixed, but the path to the playlist may be set as desired.