[scott967]

The way the music role nodes are constructed, they only return results reliably when Kodi setting "showcompilationartists" (show song and album artists) is true.

So I changed the library node path to eg:

Code:

<path>musicdb://artists/?role=Composer&albumartistsonly=false</path>

and that fixed it, except "allroles" needs:

Code:

<path>musicdb://roles/?albumartistsonly=false</path>

at least ISTM that should be the default.

scott s.
.

[DaveBlake]

Yes I can see your point Scott.

I tend to look at this too parocially sometimes. I started out to get composer into Kodi to make my classical music collection manageable. In classical music mostly composer is also an album artist, hence happy to filter out all the minor composers. But I can see that for many roles or other music genres they are never going to be an album artist too, so by default the lists are often empty.

Many thanks for bringing a fresh pair of eyes (and brain) to this design.

[scott967]

Of course, user can create their own nodes, though this is somewhat advanced. Note that if you go into "all roles" node, you can get a crapload of entries if you use the PERFORMER artist (artist_role) tag. Many of these are singletons. I don't think it is necessarily a problem, more of an observation I guess.

A related issue, is there doesn't seem to be a good way to determine what node is currently being displayed. In some cases in Estuary skin it shows "Music / Artists" when you are in the "composer" node container. I know you aren't really into the UI aspects of it, but the only way I see now to display a "Composers" label is to find a substring in Container.FolderPath like "role=Composer" to set a skin VAR with the desired label.

scott s.
.

[DaveBlake]

Yes "All Roles" can give a crap load of entries. It just shows what is there, and it seems a good principle to always have a way to see everything. Yet to see what users do with that information. Most will do nothing of course, but some may be inspired to create nodes/playlists that suit their interests e.g. a pianists node. This may mean a tidy up of their PERFORMER tags too, or using rules with wildcards e.g. "like" rather than "is".

Note I have a PR in to fix the bug that means having a smart playlist of say composers clicking on one does not show any albums or songs. There was an earlier PR that fixed that too, but it never received approveal (it wasn't rejected either, it is just lingering in limbo unreviewed).

The problem with determining what filtering is currently being used when a folder type node is displayed is not only limited to roles, although that does make the issue more obvious perhaps. I know that drilling down from "All Roles" does display the selected role in the title above the artists, I guess I just need to work out what is being populated and when.

Same happens with genre. Drilling from Genres node shows the selected genre, but create a node for a genre e.g.

Code:

<path>musicdb://artists/?genre=classical&albumartistonly=false</path>

or

Code:

<path>musicdb://albums?genre=classical</path>

and it does not.

Despite CMusicDatabase::GetFilter having the same path (with options) to process, and the same data being fetched, the piece of information isn't being set. I'm not sure where the skin gets that title by default. I am happy to make any core changes I can to support UI needs, but I do find the whole info label design rather a jumble so hard to know what approach to take for the best.

Edit:
With some pointers from @Hitcher that the title comes from the CONTAINER_FOLDERNAME, I can see that the difference occurs in CMusicDatabaseDirectory::GetDirectory when the node is created from the path. So when the path is something like musicdb://genres/29, that is artists with genre=29 get displayed, the node gets its label by looking up genre "29". But when the path is musicdb://artists/?genre=classical, the genre is in the options not the path itself, it uses "artists".
See CDirectoryNodeOverview::GetLocalizedName and CDirectoryNodeArtist::GetLocalizedName.

Leaves me wondering about extracting options and adding to the folder name label. In the above example it is obvious as only one option value, but with

Code:

<path>musicdb://artists/?role=Composer&genre=classical&albumartistsonly=true</path>

does one say "Classical Composer Album Artist"?

Or is it just a matter of getting the node file name used for folder type, like happens for filter type nodes? Although that would be unwanted behaviour for the default nodes.

Better would be to put all the filtering into label(s) that the skin can use as they wish. For example am I only seeing album artists (what was that global setting?), have I excluded compliation albums etc.?

Any thoughts?

[scott967]

I will try to take a look at the code some. As it is I have kludged a solution for the default nodes in my skin mod. I did a quick hackery of Estuary to show what it does (ignore debug overlay):







I'm not sure exactly the significance is of Container.Folder = artists and also Container.Content = artists. That is, do they need to be the same or could maybe one maybe one could be different?

scott s.
.

[DaveBlake]

I'm sure that Container.Content = artists is required - the content is artists with all the contextual options that implies. But I think that Container.Folder could be set to something else i.e. node file name, or even a string built from the options. For filter type nodes that is the case, I think, so possible for folder type maybe?

I have a PR to change the standard role nodes as you suggest, although I have been wondering if albumartistsonly flag should simply be ignored when role > 1. Does it make any sense to be able to create a folder custom node that looks for Lyricists that are also abum artsists?

[scott967]

I'm sure that Container.Content = artists is required - the content is artists with all the contextual options that implies. But I think that Container.Folder could be set to something else i.e. node file name, or even a string built from the options. For filter type nodes that is the case, I think, so possible for folder type maybe?

Container.FolderName seems to be used only one place in Estuary. I'm guessing it could be modified and that wouldn't break anything.

I have a PR to change the standard role nodes as you suggest, although I have been wondering if albumartistsonly flag should simply be ignored when role > 1. Does it make any sense to be able to create a folder custom node that looks for Lyricists that are also abum artsists?

Probably not, but maybe for Orchestras or Composers, depending on how user tags the files. But that could be up to the advanced user to define if he wants IMHO.

scott s.
.