[ToddSexington]

Thanks for the informative reply. I have had pretty good results with using Plex on the android box. I'm still evaluating options for playing from a NAS. I would like to be able to use kodi, because the general UX of its player is pretty good, although it seems that there is a challenge with large playlists that is a known issue. But after comparing a few players, Plex is by far more functional without extensive customization.

Edit; I did try a few rounds of party mode, and it the UX was still not very tight. I've found Plex to have the best UX, and cross-platform UX, of anything I've tried so far. I do hope that Plex gets integrated into kodi soon.

[quickmic]

I have the same issue. Imho the list handling routines are not good designed.
Currently I'm debugging the code getting the performance leaks.
One is as in Playlist.cpp in "void CPlayList::Add" here -> "AnnounceAdd(item, iPosition);"
I just comment it out, and it's getting a way better. No clue about possible consequences at this time.

Next weak spot is GUIMediaWindow.cpp in "bool CGUIMediaWindow::OnPlayAndQueueMedia" here -> "g_playlistPlayer.Add(iPlaylist, nItem);"

Maybe the devs can have an eye on that.

btw, I'm testing with >300.000 files in one playlist. So the weak spots are easy to find in this case.

[NeroBoron]

In V18 there were serval improvements to music library, but this is still an issue.
Would be awesome if this gets tackled.

I know I'm gravedigging here, but it would be nonsense to open another thread.

[Klojum]

And by this you mean a ridiculous amount of songs selected?

[HeresJohnny]

Currently I'm debugging the code getting the performance leaks.

Up until now I only knew about memory leaks and not performance leaks in code but hey, you learn something new every day.

Here is probably not the place to discuss code. This is an open source project. The community will be more than happy if you contribute your findings to the source files at github. Other knowledgeable people will review it there, too.

[DaveBlake]

I will admit that the title of this thread irritates me, Kodi is far from "useless" even with large music libraries, in fact I find it pretty dam amazing for free software created by volunteers that runs on a £30 RPi. But yes it does have some design weaknesses. The GUI was not designed to handle showing large lists (thousands) of songs (or anything else) quickly, nor was it designed for user to add thousands of songs (over a weeks worth of playback time) to the queue quickly.

As I have said before you can avoid many of the slow GUI on large lists issue by using filters and smartplaylists etc., acutally make use of the library features. Or you could use remote apps like Yatse to control Kodi as a music player, I even find the dynamic rule based filtering it offers more powerful than what Kodi can do itself.

In V18 there were serval improvements to music library, but this is still an issue.
Would be awesome if this gets tackled.

A fundamental redesign of the GUI / player queue interaction to allow for lazy loading of huge lists of songs has not been possible with the time and people available. But we have added to that ways that you can filter your music to aid choice, made API access 5 times faster (for remote apps) and fixed a few areas that we slowing down db access especially on MySQL databases.

If anyone thinks we need reminding of the GUI large list problem, I promise we don't. As I have said before no amount of user desire can make new skilled people appear to volunteer their time and expertise to Kodi deveolpement, let alone fix any specific issue.

Meanwhile there are many great ways in which Kodi can make  large music collections accessible and enjoyable

[Karellen]

@DaveBlake

Would you like the thread title changed to something more informative. If yes, let me know your preference. Maybe simply replacing "useless" with "slow"?

[docwra]

One of the answers to this is to provide things like a default A-Z node so people can filter down into Artist/Album Names.

Its understandable to be slow on massive lists, but there is no real need in the first place to show an entire list of album names for example. If I tried that on my windows 10 i7 it would still be slow

[NeroBoron]

The title is harsh music library is far from useless.
Just the (all) songs view slows down wit the amount of songs.

I got like 4000 songs and got an annoying and irritating delay on playback selection of 5seconds in this view.
Others have much more where the delay is not like 5 seconds but 10 minutes, which makes this view useless. And if there is such an view it will be used, so it shouldn't hang up like that.

Don't get me wrong the other views do fine and are nice to use. I even created other nodes with song selection by mood and co. As mentioned before my Szenario ist just "play random stuff from my library".

For now I added a library node with songs in random order and limited it to 250. Works for this Szenario.

But I still have other Szenarios where I want all songs.

And by this you mean a ridiculous amount of songs selected?

Yes :'D would be the best solution imo

One of the answers to this is to provide things like a default A-Z node so people can filter down into Artist/Album Names.

Its understandable to be slow on massive lists, but there is no real need in the first place to show an entire list of album names for example. If I tried that on my windows 10 i7 it would still be slow

I really hate A-Z lists. For this I usually use quick jumps works great on my remote by Pressing 2 = a, pressing 2 twice = b, pressing 3 = d and so on like on good old phone.

[Klojum]

The title is harsh music library is far from useless.

Thread title has been changed, things were probably worse 4 years ago when this forum thread was started.

[docwra]

I really hate A-Z lists. For this I usually use quick jumps works great on my remote by Pressing 2 = a, pressing 2 twice = b, pressing 3 = d and so on like on good old phone. 

 Problem is if I look at all albums in a single list its always going to be slow, no matter how the GUI lists are coded with 30,000 albums.

Quick Jumps doesn't solve that and neither does lazy loading really.

I'll try and post a video later to show how easy my large music library is to browse with my current Node setup. I couldn't imagine browsing it without my A-Z artist node. Its important to mention that I have the A-Z category view in a grid style, so it only takes a few clicks of the remote to get to any letter. Its not like I have to scroll 24 times to get to the Z.

[DaveBlake]

I see that the mods have been title editing, and yes many library things have improved in 4 years just not the display of very huge lists of things or the addition of thousands of songs to the queue.

If I was to edit the thread title to reduce my irritation (and there is no reason to do that, I believe in free speach and if that is how some users view Kodi then that is just how it is) then sure replace "useless" with "slow". But if we are wanting accuracy and to be informative then it really needs to go further. The thread title should be more "UI is too slow displaying large lists of items or adding them to the playlist".

The design flaw applies to everything - videos, pictures, file view (not library at all) - it just happens users are more likely to view thousands of library songs and hit play than they are to have all media files in one folder, or queue thousands of 2hr long movies. More likely to do it with songs, but not necessary or even the most common use, and when doing that they aren't really making use of the library at all.

Historically there has been confusion and often the database has been blamed for slowness. Well the db was never that bad, and improvements have been made when db issues are found. My most recent work that will go into v18.1 will also bring some speed improvements to the library generally, but I know that  the UI will still choke on huge lists of items.

[Powerhouse]

If you want to speed up the Music searching speed (or Displaying large amounts of Music), make sure your Music is on an SSD drive and not a slow HDD or even worse, a class 10 SD card.

For the Best performance, for all things Kodi, put it, and all your Data on a M.2 drive.

Personally, I have all my Kodi's (Android Shield TV and Windows NUC) running on an SSD drive, connected to a High End NAS, and never see slowdown issues. Oh, and I have huge libraries for everything (4000+ BluRay or 4K movies, 800+ TV series containing over 50,000 TV episodes, 4000+ Music Videos, and 2600+ Music Artists, containing thousands of Albums, and 10's of Thousands of Music Songs).

THE only slowdown I ever see, is when I install a fresh version of Kodi (which I am doing for all my Kodi 18 installs), and adding Movies (1.5 Hours), and TV Shows (4.5 hours). So I do these things when I'm going to bed, and wake up with everything done.

[docwra]

Quick demo from my Kodi setup, not my full collection but the video should show nice ways to browse the Music Library without long lists.



Seems the shield struggles a bit recording 4K, but its a lot smoother in real life

[quickmic]

Currently I'm debugging the code getting the performance leaks.

Up until now I only knew about memory leaks and not performance leaks in code but hey, you learn something new every day.

Here is probably not the place to discuss code. This is an open source project. The community will be more than happy if you contribute your findings to the source files at github. Other knowledgeable people will review it there, too.      

 
I'm currently rewriting the whole playlist subroutines, so hold on.
I think this will fix some of the most annoying playlist-problems, even if there are a couple more major performance issues.