[rmrector]

As a possible property for AudioLibrary.GetArtists and AudioLibrary.GetArtistDetails, so that add-ons and other Kodi-related tools can more easily reuse the same directory.

Calculating the artist folder exactly like Kodi does is quite the process, considering the artist name needs cleaned for the file system and maybe they need a MBID slug to separate two artists with the same name. Since Kodi already does the hard work - and can do the second part significantly faster than we can accomplish with JSON-RPC - exposing it to other tools reduces the chance we'll end up with multiple slightly-different folders for one artist in some cases.

Edit: The result could be a full path like "smb://server/path/to/centralinfo/artists/David Cross_e256/", and maybe could even be a list to include the old artist path if one can be determined, because sometimes we'll want to find info in each path that exists and other times we'll want to create the central folder if it doesn't exist.

[DaveBlake]

Exposing the artist folder within the Artist Information Folder via JSON is a great idea @rmrector. I think I had it in my mind at some point, wanting addons to use this common location too, but then lost sight of implementing it. Thanks for asking.

The implementation issue is how to do that without slowing down AudioLibrary.GetArtists, that I have just refactored to be faster! it is not stored data, that would be easy to add as a property and storing may be the solution. At the moment it dertermined when it is needed - on export or scraping - both are slow operations so speed not an issue. I guess it could be slow with a warning on the schema to that effect.

[rmrector]

I had thought about storing it, but that's probably more complicated than it is worth. Existing artists will need to be rechecked for name collisions when a new artist is added, when an existing artist is removed, and if an existing artist is renamed (JSON-RPC, or scanning changed tags, maybe even online scraping) then existing artists that match either the old name or the new name need to be rechecked.

If it is stored then Kodi could use it for manual selection of artwork, starting the user directly inside of that artist's folder instead of the root of the Artist information folder. Not super compelling, but it's something.

The schema already has a warning for genre, role, and sourceid, and many media types in the library have a similar warning, so that shouldn't be a problem. This seems like it will increase the response time noticeably more than the others, though.

[DaveBlake]

My recent JSON speed up has acutally removed the slowness (and warning) for requesting genre, role, and sourceid. Only requesting art (or tumb, or fanart) for songs and albums is slow, and that is because to apply the common fallback strategy I left it as a call per row to the thumb loader. It is something that could be improved too.

But that is by the by. Storing artist folder name, and yes maintaining/adjusting if a clashing artist is added, is attractive for v19 (too late in beta for v18 I think). The only question is do I try and add to JSON API for v18 to return this folder, all be it slow for now?

[rmrector]

Adding the slow way may not be worth it if you want to store the path in the future.

[DaveBlake]

Just a reminder for myself that the overall Artist Information folder is available as a setting.

It is returning what Kodi thinks is the name of the folder beneath that for each individual artist that needs adding. Generally this is the artist name, but could have digits added (partial mbid) if more than one artist with same name and does have illegal char replaced.