2019-01-20, 10:41
Yes, Kodi is slow when trying to populate the linked lists that sit behind the GUI and current playlist queue with a large number of items. It is a known issue, and nothing to do with the actual databases and how they are accessed. There probably could be some db optimisation done but it is not the main contributor. Using MySQL (clent/server setup) is slower than (local) SQLite, and a slow processor and data/network access will obviously makes things worse, but there is a design limitation.
What this means in practice is that if you have a large collection of music, for example, then that looking at the songs node (all the songs), or a big playlist, or clicking play from one of those (hence filling the queue with all those songs) is going to be slow. It is often hit in the music library more than video because users have more songs (332844 in this case) than movies (3840), but the issue effects both and pictures too come to that.
To fix this issue means a total redesign of how the GUI works and memory is used to use some kind of lazy loading, not the current approach which waits until all the items are loaded into the list before displaying any of them. Likewise sorting needs moving into the db (which is quick at it) rather than being done in memory with some algoithmic mistakes.
Frankly the active dev team is very small at the moment so tackling these fundamental redesign issues is slow progress. All we can say is it is known issue and hopefully can be fixed one day.
In the meantime as a workaround make use of smaller nodes e.g. genre, year etc. , smart playlists or party mode (to randomly play songs from a playlist) to limit how many items are displayed or added to the queue at one time. FWIW my prefered work around, since I have a large music collection and like to listen with TV off, is to use a remote app to browse my music and control what I play. It also uses a SQLite db just on an Android tablet and yet UI speed is fine, which anecdotally confirms the slowness is not having lots of songs or using SQLite but what Kodi does with the data once it is fetched.
What this means in practice is that if you have a large collection of music, for example, then that looking at the songs node (all the songs), or a big playlist, or clicking play from one of those (hence filling the queue with all those songs) is going to be slow. It is often hit in the music library more than video because users have more songs (332844 in this case) than movies (3840), but the issue effects both and pictures too come to that.
To fix this issue means a total redesign of how the GUI works and memory is used to use some kind of lazy loading, not the current approach which waits until all the items are loaded into the list before displaying any of them. Likewise sorting needs moving into the db (which is quick at it) rather than being done in memory with some algoithmic mistakes.
Frankly the active dev team is very small at the moment so tackling these fundamental redesign issues is slow progress. All we can say is it is known issue and hopefully can be fixed one day.
In the meantime as a workaround make use of smaller nodes e.g. genre, year etc. , smart playlists or party mode (to randomly play songs from a playlist) to limit how many items are displayed or added to the queue at one time. FWIW my prefered work around, since I have a large music collection and like to listen with TV off, is to use a remote app to browse my music and control what I play. It also uses a SQLite db just on an Android tablet and yet UI speed is fine, which anecdotally confirms the slowness is not having lots of songs or using SQLite but what Kodi does with the data once it is fetched.
