[Canuma]

Is there a more deeper documentation for Kodi's Node feature then whats on the wiki pages?
I ask, because i don't know where to find a list of parameters the folder type or more precisely the music special path can take.
The reason I ask, i have organized my Music Collection to differ between Music, Soundtrack, Game Soundtrack and Audio Books and I want to recreate every Node possible with the plain Music hirachy.
But I found some inconsitencies.
For example, the following works:

xml:


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<node order="20" type="folder" visible="Library.HasContent(Music)">

    <label>133</label>

    <icon>DefaultMusicArtists.png</icon>

    <path>musicdb://artists/?albumartistsonly=true&amp;source=Musik</path>

</node>

This causes Problems allready:

xml:


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<node order="10" type="folder" visible="Library.HasContent(Music)">

    <label>135</label>

    <icon>DefaultMusicGenres.png</icon>

    <path>musicdb://genres/?source=Musik</path>

</node>

While it does work, it take ages, and it gives you all the genres, but those which are not within Sources are empty.
I discovered a similar behavior when using playlists, filtering by sources gives that result, filtering by tags (I had a Music Tag which i want to get rid off)
Does what it should, it gives me just the genres i expect.

This one does not work at all, it just returns every recently added album and unfortunatelly it seems i cannot recreate that using playlists either, i can't sort by day added and limit that:

xml:


<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<node order="80" type="folder" visible="Library.HasContent(Music)">

    <label>359</label>

    <icon>DefaultMusicRecentlyAdded.png</icon>

    <path>musicdb://recentlyaddedalbums/?genre=Audiobooks</path>

</node>

So, again, is there a way to find out which paths are exposed from the database and which arguments do they take?
I tried to find something within the Kodi Sources on Gthub, but i guess i understand not enough C++ ;-)


Update:
I consider this Thread solved. As @DaveBlake points out, folder based nodes are not documented for a reason and the feature is probably going to be deprecated in the future, so i won't bother. Still have a look at #10, there are some great explenations also of what is working with some folder nodes and what not.
I almost realized everything i wanted to, with genre splitted by source the only exception, yet still having a somewhat, allthough not perfectly working solution.
If you are interested in splitting sources and grouping by genres, i posted a partly working example in #13, which won't take ages on bigger libraries.

[LongMan]

These work for me.

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<node order="1" type="filter" visible="True">
       <label>Audio Books</label>
       <icon>icons\sidemenu\music.png</icon>
       <content>artists</content>
       <match>all</match>
           <rule field="source" operator="contains">
               <value>Books</value>
           </rule>
       <order direction="ascending">artist</order>
</node>

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<node order="1" type="filter" visible="True">
       <label>Musik</label>
       <icon>icons\sidemenu\music.png</icon>
       <content>artists</content>
       <match>all</match>
           <rule field="source" operator="contains">
               <value>musik</value>
           </rule>
       <order direction="ascending">artist</order>
</node>

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<node order="2" type="filter" visible="True">
       <label>Last Added Albums</label>
       <icon></icon>
       <content>albums</content>
       <match>all</match>
           <rule field="source" operator="contains">
               <value>Books</value>
           </rule>
       <group>albums</group>
       <limit>10</limit>
       <order direction="descending">dateadded</order>
</node>

[Canuma]

Thanks for your comment, but that was not the point i tried to make.
As I said, I am looking for information beyond what's in the wiki pages, especially parameters that the folder type nodes accept, as they seem to behave inconsistently, again, see my post.
I am trying not just simply to split one Database view (that would be simple) but to fully recreate the original music node folder but splitted. Only thing missing for now are proper genre splitting and a working recently added solution, everything else does work now.

[LongMan]

From my experience, the folder type may not be able to do what you want. The paths there are vfs paths. I suspect you really need information about vfs paths rather than nodes. If you can find the correct vfs path, it should work.

What I can say is, using the filter type nodes I referenced above, I have been able to recreate my own complex folder structure. Including multiple genres and sub genres of music, Audiobooks, Podcasts, DJ Mixes and Audio Drama. All these sources have sub menus and six differnt widgets per source including fully separated recently added.

It may not work for you, but it certainly does for me. As I said previously you want info on vfs path in Kodi. The folder node just accepts a working vfs path. If the path works, the folder node will work.

Hope that helps.
Cheers,
LongMan

[black_eagle]

I don't think there is any documentation for this.  There are however various posts by @DaveBlake that cover some of this. 

With regard to recentlyaddedalbums, there is no filtering applied when using the db path so your genre rule is just ignored.  As @LongMan points out, you can achieve a similar thing through smartplaylists (which you can then convert into nodes if you wish) although using the 'dateadded' field may return different albums to the recentlyaddedalbums node as that doesn't use the date to create it's list.

If you want to dig through the code to see what options you can use for filtering, you can look at https://github.com/xbmc/xbmc/blob/master...383-L11963

[Canuma]

From my experience, the folder type may not be able to do what you want. The paths there are vfs paths. I suspect you really need information about vfs paths rather than nodes. If you can find the correct vfs path, it should work.
 

Yeah, that is basicly what I am trying to find out. The filter based nodes are no Problem, Since they mostly work like smart playlists. But then, not everything is afaik possible with the filter based aproach. For example the allready mentioned recently added filter. While there is a folder based solution, there is no filter for that. So yeah, again, I would like to know where i can find some documentation of possible parameters for folder based nodes. Of course, if you where able to recreate f. eg. recently added stuff , I'd be more then happy if you'd share it.

[Canuma]

I don't think there is any documentation for this.  There are however various posts by @DaveBlake that cover some of this. 

With regard to recentlyaddedalbums, there is no filtering applied when using the db path so your genre rule is just ignored.  As @LongMan points out, you can achieve a similar thing through smartplaylists (which you can then convert into nodes if you wish) although using the 'dateadded' field may return different albums to the recentlyaddedalbums node as that doesn't use the date to create it's list.

If you want to dig through the code to see what options you can use for filtering, you can look at https://github.com/xbmc/xbmc/blob/master...383-L11963

Thanks for your reply.
If I understand you correctly, there are indeed inconsitencys the way the folder nodes behave, is that right? (As I said, some of them do work with source parameter called, others do not, I had no time yet to get through all the original musicrolenodes, but the ones i tried so far work)

Also, are you sure it is possible to sort Music via recentlyadded? It would be great as i wouldn't have to bother with the folder node and simply could use the filter node instead, but unfortuneatelly the smartplaylistfilter create tool suggests, it does not.

As a side note, do you happen to know as why genre grouping is so dead slow as soon as you apply a /any filter? I understood why my first approach a few years ago was so slow, as it had to look into every files (multi) genre field. But given that it can now first look into the source to filter the entries away it still is surprising how long it takes to show the genres

As for your link to the source, Thank you as well, i will try and dig through it, however i still have a hard time understanding c++ ;-)

[docwra]

Also this thread

https://forum.kodi.tv/showthread.php?tid=257378

[Canuma]

Also this thread

https://forum.kodi.tv/showthread.php?tid=257378

Jupp, was a great inspiration when i started to split my collections, still not so much regarding folder based nodes or working examples for recentlyadded music nodes (Or i have overlooked something, that is very well possible)

[DaveBlake]

Lots to comment on here, I should have jumped in sooner. Generally @black_eagle and @LongMan have given you good advice @Canuma , but maybe I can add some history and reasoning that will help everyone make more sense of the current state and uses.

Folder type nodes are a historic hangover from how Kodi GUI screen system was originally implemented (back in XBMC days). They are based around the original vfs paths used by skins and addons to open specific windows see https://kodi.wiki/view/Opening_Windows_and_Dialogs, navigation from say artist to album was implemented internally by adding ids to that path, and very basic filter criteria also added in that way e.g. show albumartists only, singles, compilations. I don't think it was ever intended for users to make use of that (hence not documented) but of course there was nothing to prevent them if they could figure out how.

Then rule based filtering was introduced suppoting filter type nodes along with smartplaylists and the sideblade filter facility. Most nodes in the default menu were converted to filter type  xm files in the system/library, and users were encouraged to make custom nodes of their own.  The idea was for this in time to completely replace the use of vfs paths by skins etc., although there are reasons why this has not actually happened. Music library nodes were switched to this approach in 2015 (video was earlier), but at the time some nodes couldn't be done filter/rules way so were left as folder type e.g recently added albums.

About then I started as a Kodi user trying to make nodes separate my classical music from pop see https://forum.kodi.tv/showthread.php?tid=235785 and tripped over the fundamental difference between folder type nodes and filter type ones. With folder type nodes the simple criteria gets passed down e.g. navigate genre>artist>album>song and the songs you see are those with the selected genre. With filter type nodes the filter rules get applied once only e.g. create an artists smartplaylist/custom node with rule (song)genre = X and it will list those artists with songs with genre X, but click on the artist and you see all the albums regardless of genre, and select an album you see all the songs.

Subsequently when I got more involved with Kodi development and added the sources feature (a flexible way for users to split up their music library) I extended folder type path options to include source in some situations (much as "albumartistsonly" or "singles" options work in some situations and not others). I did that somewhat selfishly so that both genre and source criteria could be combined and applied down through all levels of navigation, something I wanted with classical music particularly.  However in the long term (I have WIP) the better implementation is to change things so that filter rules get applied as you navigate.

So yes using options in the path of folder type nodes is undocumented, users are welcome to explore taking advantage of it to get the results they want, but do so knowing it is really a side-effect of the historic internal implementation rather than a deliberately designed user feature. Also know that eventually (assuming I get my WIP complete) there will be ways to achieve the same functionality (and more) using filter type nodes.

In particular @Canuma no the "source=XXX" option was only designed to work on artists, albums and songs paths and not genres. Also musicdb://recentlyaddedalbums and musicdb:recentlyplayedalbums node do not apply any options.  The recentlyadded and recently played albums nodes are hard coded in a limited way (and have other issues in the way "recent" is identified).
 

Also, are you sure it is possible to sort Music via recentlyadded? It would be great as i wouldn't have to bother with the folder node and simply could use the filter node instead, but unfortuneatelly the smartplaylistfilter create tool suggests, it does not.

The albums nodes (folder with path musicdb://albums or filter type content albums) can be sorted on the GUI by date added, but no that sort order has been omitted from smartplaylist options hence you can't apply it to them or custom nodes and create your own "100 recent albums filtered by XXX" node.

I have WIP that fixes that (it will also return to using dates not id to identify recently added, but with much better management of those dates when rescanning happens). Better is coming in v19, but not via folder type nodes which need to be thought of as legacy functionality.

[Canuma]

@DaveBlake
Thank you for your thoroughly reply, that helped a lot. Also while you are here, I really apreciate what you have done so far with Kodis Music Section, your addition of the source filter is the reason i am currently reworkng my nodes. I have started to split my collection with v17, but had to take a rather hackish aproach by adding a music genre tag to my collection for stuff that isn't audiobook, soundtrack or game soundtrack. I allways hated that, but thanks to you i am able to get rid of that now.

So yes using options in the path of folder type nodes is undocumented, users are welcome to explore taking advantage of it to get the results they want, but do so knowing it is really a side-effect of the historic internal implementation rather than a deliberately designed user feature. Also know that eventually (assuming I get my WIP complete) there will be ways to achieve the same functionality (and more) using filter type nodes.

I am not bound to folder based nodes, I wasn't even happy with that approach, because it added additionally complexity, you can't mix folder and filter based nodes etc. It was just that I use many of the system provided nodes but i wanted to be able to split them as well. Unfortunatelly several are in fact node based and as you confirmed, not everything is possible with a filter based aproach yet.

Anyway, as you suggest that folder nodes are actually deprecated, I will no longer bother, in the meantime i got almost everything working as it should with genres beeing to only thing left giving me massive headaches. I consider this broken for me for now, but my approach gives at least some usable results without using genre filter and still having a decent result time (My original approach by excluding genres and having artists as result criteria took up to a minute to be served now it is there instantly, just shows genres that particular source has, but unfortunatelly it shows all artists from the whole database that made albums with that genre, but artists folder beeing empty when they don't match the source criteria)

So again, thank you for your hard work, I am looking forward to Kodi 19 and am curious to see what else you have done to make the Kodi Music Library better

[jjd-uk]

My original approach by excluding genres and having artists as result criteria took up to a minute to be served now it is there instantly

I'm curious as to what type of device you are running Kodi on to have seen that sort of response time of up to a minute.

[Canuma]

My original approach by excluding genres and having artists as result criteria took up to a minute to be served now it is there instantly

I'm curious as to what type of device you are running Kodi on to have seen that sort of response time of up to a minute.   

It is a i7 Sandy Bridge, but it has nothing to do with the device but rather the way the database query is done. I took my time to dig through the nodes example thread again and well, on page 13 User @Uatschitchun happend to face the same problems i had. My approach was basicly the same he did in 190. It took him 7 minutes to get the result, as my library is much smaller it takes "just" about a minute. @DaveBlake suggested there, that this is probably a query Problem.

My current solution is a bit different, and while still not giving the expected results, it is good enough for now:

xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<node order="10" type="filter" visible="Library.HasContent(Music)">

<label>135</label>

<icon>DefaultMusicGenres.png</icon>

<match>all</match>

<content>albums</content>

<group>genres</group>

<rule field="source" operator="is">

<value>Musik</value>

</rule>

</node>

As you notice, i changed content from artists to albums. This gives a) an instant result and b) funny enough, still the artists within the genre node. It does however result also in adding every artist who has an album within the genre from the whole music library, but those nodes are empty, when they are not within the source filter.

To give an example i have a genre Electronic, which happens to be a genre in Musik, as well as in Soundtracks. When i open Musik/genres/Electronic, Artist Vangelis appears here, but is empty, as his Album from Blade Runner Soundtrack is in Soundtracks source.

So yeah, as i said, none of the genre mechanics are working as they should right now when splitting your sources, my approach however does not take minutes to proceed.

[jjd-uk]

It is a i7 Sandy Bridge, but it has nothing to do with the device but rather the way the database query is done. I took my time to dig through the nodes example thread again and well, on page 13 User @Uatschitchun happend to face the same problems i had. My approach was basicly the same he did in 190. It took him 7 minutes to get the result, as my library is much smaller it takes "just" about a minute. @DaveBlake suggested there, that this is probably a query Problem.

Fair enough, was wondering if perhaps you were using something like an RPi as normally database queries are not expensive operations, usually the inefficiencies is loading the data into the GUI by our file item handling.