[DaveBlake]

Having loaded your MyMusic72.db, when I use your nodes I do not get the same issue. Yes everything is slow because the lists are huge, but default Genres node > "Alternate" giving  artists is faster than Custom Node "Alternate" giving songs as I expect it to be. I am unable to repeat the odd behaviour.

I did notice Estuary was slower than Confluence, but not sure why. Perhaps repeat test generating a debug log with Confuence? Also use both node routes in one debug log, in the log you gave for the custom node route the songs query so fast it seemd it was against different data

[quickmic]

Complete new Kodi backup with new generated db, default settings and just two nodes. I even unmounted my music-folder so I have no access to mp3s as well.
https://1drv.ms/u/s!AsC6yIANTPi5cKWwvM5oPuB5Bbg
https://1drv.ms/u/s!AsC6yIANTPi5bi3MzEbAMw9PN6E
https://1drv.ms/u/s!AsC6yIANTPi5b1yzLxGxQFzK4kQ

I hope you can verify that. Please use exact selections as I do. e.g. if you try Genre user "Alternative" not "Alternative - Country" or so.

I try Confuence next.

[quickmic]

I forgot to say, I also changes the test-node "alternative" to show artists not songs anymore.

And not that we are talking about different things here cause you the call stock node "genres.xsp".
I copied the stock out from here:
cp  /usr/share/kodi/system/library/music/genres.xml /home/quickmic/.kodi/userdata/library/music/
no smart playlist or so...


EDIT:
Confuence exactly the same behaviour

[quickmic]

in the log you gave for the custom node route the songs query so fast it seemd it was against different data

Yes, but the other way around. The custom node select even more, cause it selects also the multigenres. e.g. custom selects "alternative" and "alternativ - *" and "* - alternative".
The stock ONLY selects "alternative" in my sample.

custom: 1151 Artists
stock: 413 Artists

btw, stock node has also a wrong behaviour when it comes to selections, but first we need a reproducible setup before I come to that.

[quickmic]

Final round for today. I have go to bed...

Custom node set to exact same selection as stock:

Code:

<?xml version='1.0' encoding='UTF-8'?>
<node order="40" type="filter">
        <label>Alternative</label>
        <content>artists</content>
        <match>one</match>
        <rule field="genre" operator="is">alternative</rule>
        <order direction="ascending">artist</order>
</node>

https://1drv.ms/u/s!AsC6yIANTPi5cYlD7tcRLHk3cQ4
https://1drv.ms/u/s!AsC6yIANTPi5ci9rx8ctHSY73Ss

[DarrenHill]

Thread moved to music support, as that's what it's become.

[DaveBlake]

Thanks @DarrenHill makes sense here
@quickmic I am away a couple of days, but will pick this up on my return. 

I thnk there is confusion over what nodes we are examining. The end result is a list of artists verses a list of songs (what is in your video), or now you are saying artists verses artists. We need to clear that up!

[quickmic]

@DaveBlake 
Last sample compared genre based Artist selection via custom node vs genre based Artist selection via stock genre-node.
It seems I'm unable to make my point here and I'm running out of options for a better documented issue description.
I think I will invesigate myself.
So, really big thanks for all your help!
I'll keep you updated in case I figure out, what's excactly going on in the code.

[DaveBlake]

OK @quickmic, I'm back earlier than expected

Complete new Kodi backup with new generated db, default settings and just two nodes. I even unmounted my music-folder so I have no access to mp3s as well.
https://1drv.ms/u/s!AsC6yIANTPi5cKWwvM5oPuB5Bbg
https://1drv.ms/u/s!AsC6yIANTPi5bi3MzEbAMw9PN6E
https://1drv.ms/u/s!AsC6yIANTPi5b1yzLxGxQFzK4kQ
I hope you can verify that. Please use exact selections as I do. e.g. if you try Genre user "Alternative" not "Alternative - Country" or so.

Right, now comparing artists list with artists list. I can see the slowness of clicking on genre = "Alternative" on the default Genres node (genres.xml, sorry I mistyped before but it was late) you experienced compared to your custom node, in both the log and the screen video.

However I still can't reproduce it
This means that something else is happening on your set up that is not happening on mine, but I can't see what from the log.

It seems I'm unable to make my point here

I believe you experience what you say, and I am sure now that I am trying the same thing. The issue now it is about reproducing it.

I suspect that something else is causing a query of the artists table on startup, and that it is still running while trying to get artists for a genre, hence the extra slowness. But that is just my first guess.

Is navigating the defaut genres route to artists for a genre always very slow, or does it only that slow sometimes? Could you try using the default genres node route more than once, but swap between different genre values, or to another node that lists artists to ensure that data caching etc. (slow to display nodes get saved to file, and reloaded from there) does not hide the issue. Or maybe leave a 5 min gap after startup and navigating to "music" as the selected item on the main screen (in left menu) before trying.

[DaveBlake]

It seems I'm unable to make my point here and I'm running out of options for a better documented issue description.
I think I will invesigate myself.
So, really big thanks for all your help!
I'll keep you updated in case I figure out, what's excactly going on in the code.

@quickmic you should not give up on me so easily, although of course you are welcome to investigate and explore the code yourself.

I think I understand the slowness you are seeing, and it is not related to the genre selection at all, nor to the SQL used. It is caused by the way the random artists widget on the home screen is being populated. This uses a smartplaylist to request 15 random artists, and unfortunately the limit of 15 and random sort is not being applied at the db. Instead it fetches all the artists, in your case 28k of them, which obviously takes longer to query than 15 would, then sorts all of them randomly in memory. For your huge collection this is a slow process, which delays any other music database artist query.

This theory can be tested by waiting for the random artists widget (scroll down home screen to see it) to populate before using using the default genre node to navigate to the artists of a specific genre. Can you do that and report back?

Meanwhile limits and random sorting of artists need to be applied at the db rather than in memory, much as they are done for songs. A fix I will look at implementing.

[quickmic]

Sorry, but I don't continue with testruns any more. I'm investing directly the code. I traced the issue all the way back to GUIMediaWindow.cpp -> CGetDirectoryItems(XFILE::CVirtualDirectory &dir, CURL &url, CFileItemList &items, bool useDir).
I assume here is the problem, but not sure at the moment. Investigation is still in progress.

[DaveBlake]

Sorry, but I don't continue with testruns any more.

That's fine. Therefore shall I close this thread?

[quickmic]

Yes, please. Thanks again for your help!

[DaveBlake]

Thread closed as user no longer wants team to pursue issue