[quickmic]

Thanks Dave for your statement from a dev perspective.

Actually, this more or less what I've expected.
Rewriting and changing the concept of such a fundamental part is a pain in the a..
Anyway, I think sooner or later this has to be done.

For the moment, I think some improvement is still possible even under the current approch.
e.g. Subset of music loaded via node...

Code:

<?xml version='1.0' encoding='UTF-8'?>
<node order="530" type="filter">
    <label>Funk</label>
    <content>songs</content>
    <match>one</match>
    <rule field="genre" operator="is">funk</rule>
    <rule field="genre" operator="contains">funk - </rule>
    <rule field="genre" operator="contains"> - funk</rule>
    <order direction="ascending">artist</order>
</node>

...takes about 12 seconds (on low end hardware).
I think this delay is mostly based on db performance, so nothing to improve here.
After this I have list with around 1937 items. Now I click on a item (song). As far as I know, the playlist will be created at this moment.
This takes between 20 seconds and 3 minutes depending when I click.
I assume the playlist-creation is running in background thread asynchron and if first thread is not finished, while I select a new song (generate new playlist), the first thread will not be cancelled.
Anyway, as you mentioned here is room for improvement but hard work.

Based on that observation:
If I select in the list (not playlist) another song Kodi starts over recreating the playlist.
This is imho absolutely unnecessary, cause nothing has changed. Here is room for improvement cause this is just a decition, when you trigger the create-playlist subroutine and maybe cancel previous thread.

So performance issue is not only the playlist creation itself, it's also when you trigger the routines.


Another spot for improvement:
At the previous example I select the subset of songs via node and it took around 12 seconds.
Now, if I use the group function...

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<node order="10" type="filter">
        <label>Genre-SLOW</label>
        <icon>DefaultMusicGenres.png</icon>
        <content>artists</content>
        <group>genres</group>
</node>

...it is quite fast (almost instantly) showing me the genres list, but:
If I select e.g. Funk as genre it takes 1 minutes. (compared to 12 seconds before)
Here is also imho something wrong cause this is not a DB performance issue. I think here is also a design problem the actual reason.



Additional information:
When playlist creation is in progress, the CPU is not really busy. 4 cores, and peak of one core is maybe 50-60%. Combining load of 4 cores would be approx. 1 core at 100%. The rest would be idle. Not sure if there is some load-balancing and playlist-creation is a single thread, or as it looks multithread but not using the full cpu power.
I gave pop-genre also a shot, but I stopped after 35 minutes playlist creation and still pending.

Final statement:
Good to know, that you (the devs) aware of those issues.
When I have time, I will also investigate on those again to remove the most painful delays. Unfortunately, the code is very complex and as you mentioned, this would need lots of work and really experienced developers to fix the design issues.
And please excuse if I'm wrong on some assumptions. Mostly is based on observation and not too much code review.