[scott967]

So I have tried searching old threads, finding out in the xbmc github sources, etc, and still don't understand how the library nodes work.

One problem, I haven't figured out where the xml files get parsed.

But in general questions I have are like this:

1. The files are organized as a folder tree with "music" at the root and a couple of child folders like "musicvideos" and ""musicroles". What is the significance of the folder hierarchy?

2. What are the allowed / dependencies of the <node> element attributes?

I see "order" which is obvious, and "visible" which I guess allows any legal kodi boolean. "Type" I guess is either "filter" or "folder". Is that all that is available for <node>?

3. I understand if 'type="folder"' then the child element <path> is required I assume exactly once?

4. What is the allowed syntax for the <path> element?

5. If 'type="filter"' are there any required child elements?

6. What is the purpose of the <content> child element? What are the legal values?

7. In looking at the code, I see an enum list of NODE_TYPE. It doesn't seem like many of these are actually used or am I wrong? Or, what is the significance of the NODE_TYPE (seems to control how the list container gets filled / grouped and what happens when you select a listitem, but anything else?)

8. I think the filter <rule> <limit> etc is explained fairly well for smart playlist and most examples I found in "how to create/edit nodes" focus on this aspect. But maybe there is more to this?

I'm trying to come up with some sane nodes for the new artist roles but I am struggling with how best to write these nodes. I tried to reverse engineer the library node editor addon but didn't get too far.

As an example, I would like to separate out songwriters from classical composers. Also for things like musical theater "soundtracks".

scott s.
.

[DaveBlake]

Scott my understanding comes from digging through the code (and modifying a bit of it)

One problem, I haven't figured out where the xml files get parsed.

It isn't obvious but have a look in CLibraryDirectory::GetDirectory. It ends up calling CMusicDatabase::GetItems, in turn the xsp or virtual path is turned into SQL by CMusicDatabase::GetFilter along with CSmartPlaylistRule::FormatWhereClause (for filter type nodes)

I will have a go at your questions, but I have not seen these things defined anywhere so it is just my interpretation from reverse engineering it.

1) "folder hierarchy" for xml node files under userdata/library provides the menu/node structure. If say a userdata/library/music folder exists then it overrides the default in system/library/music and the default music nodes that Kodi is deployed with. If you still want them then copy that system folder and customise it. Any child folder beneath userdata/library/music creates a branch on the menu/node tree. Within that folder a file call index.xml defines the order, visibility, label and icon for that menu item in the parent menu.

A look in child folders "musicvideos" and ""musicroles" will show you how that works, basically using folders you create whatever on screen node/menu hierarchy you want, the children can have children etc.

2) Within <node> element there is
"type" with values "filter" or "folder" and determines how the rest of the xml is processed as smart playlist rules, or as a virtual folder path like the standard nodes.
"order" an integer that defines what order the node appears on the menu/list/node hierarchy (I never know what to call that).
"visible" conditional visibility of the node in the menu using info booleans like a skin would.

AKAIK that is all available.

3) Yes <path> once, only processed when type = "folder" ignored otherwise.

4) Syntax of <path> is that of the virtual folder path used internally.
The first part is from here http://kodi.wiki/view/Opening_Windows_and_Dialogs e.g. musicdb://artists/ is the artist sub-section. Krypton also has a musicdb://roles sub-section that lists all the music artist roles that have been found in your music.

Then you can add options parameters. These are undocumented but examining CMusicDatabase::GetFilter will tell you what works where. There is no parsing, so invalid options combinations are just ignored. In summary the parameters for music are: genre, genreid, artist, artistid, album, albumid, role, roleid, year, compilation, albumartistonly. They can only be equated to a single value and combined in AND, so for example:

musicdb://artists/?albumartistsonly=false&role=Composer

It is a slightly raw but powerful approach to controling what is dislayed on a node.

5) For type="filter"' nodes there must be a <content> child element. It has no meaning for "folder" type nodes.

6) <content> values are same as those for smart playlists e.g. "songs", "albums", "artists" etc. again not parsed for validity, just no results.

7. Less certain on this as it is not used for cutom nodes and rationalisation of dialog types has maybe reduced its use too. As you have observed NODE_TYPE relates to how the list container gets filled / grouped and what happens when you select a listitem.

8) I don't think so, no mystery.

I'm trying to come up with some sane nodes for the new artist roles but I am struggling with how best to write these nodes. I tried to reverse engineer the library node editor addon but didn't get too far.

As an example, I would like to separate out songwriters from classical composers. Also for things like musical theater "soundtracks".

The real difficulty is that there are so many things possible, hard to know what any user will want. Also I anticipate refining things once I get feedback from people like yourself. The roles idea was dreamed up by Evilhamster (who I haven't seen about since) and myself out of the requirement to support composers. It opens a lot of possibilities, but needs the UI side developing to make those accessible in a user friendly way.

I presume by song writers you mean composers of non-classical music, there is also a lyricist tag that gets completed for some song writers. I'm pretty sure what you want to do is the obvious.

This is about combining genre and role filters. The positive selection is easy, in a folder type node you can do this with
<path>musicdb://artists/?role=Composer&genre=Classical</path>

But there is no path approach that excludes a genre (unless I add one, and that is tempting)
I persoanlly prefer the folder type nodes, the SQL produced is cleaner, it gives a "*all" item and drilling down with the same filter works.

There there is also a filter type node approach.

Code:

<?xml version='1.0' encoding='UTF-8'?>
<node order="2" type="filter">
<label>Rule Pop Composers</label>
<icon>DefaultMusicArtists.png</icon>
<content>artists</content>
<order direction="ascending">artist</order>
    <match>all</match>
    <rule field="role" operator="is">
        <value>Composer</value>
    </rule>
    <rule field="genre" operator="isnot">
        <value>Classical</value>
    </rule>
</node>

However, I have just realised there is a bug in this
Playlists do not pass their filtering on then you click on an item in the resulting list, hence unless a composer listed in such a list is also a song or album artist clicking on a composer results in an empty display.

So I have some work to do, but your input is appreciated as always.

[scott967]

Thanks. From a skinning perspective I might want to have custom nodes but there's no way to distribute that as a skin (that I can see). Otherwise I probably end up with various skin settings and visibility switches which makes dev and testing harder (but in 17 there are more procedural things available such as expression handling and include call parameters so I might need to look into the new design philosophy more for this).

scott s.
.