[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.