2018-10-19, 19:29
I think I've tracked down some of Kodi's slowness to its origins. Mind you, it's not like it's dragging, but there is some definite potential for speed-ups. There are 2 main issues I've identified:
1.) Playlists for Widgets
2.) Datum fields in SQL database
Let's start with
2.) Datum fields
Kodi uses several columns for storing datums, like lastScraped, dateAdded, lastPlayed. For whatever reasons these are mostly defined as TEXT fields (Blobs) instead of DATUM fields. Changing the datatype to TIMESTAMP (on MariaDB, should be similar on MySQL) makes reading the tables faster. Also, DATUM fields are used in many queries, so an INDEX for DATUM fields is recommended.
Here are the columns I've found and changed to TIMESTAMP with beneficial effect:
a) mymusic72.db
a) myvideos112.db
1. Playlists
I'm referring here to playlists that are used for widgets. Those are the biggest holdup in Estuary. You can try for yourself to replace in Includes_home.xml
(For TVShows, replace special://skin/playlists/recent_unwatched_episodes.xsp with videodb://recentlyaddedepisodes/)
Using a playlist produces a spinner that will stay for several seconds whereas the direct call is instantaneous. Also, after changing 1.) and 2.) exiting Kodi is also almost instantaneous.
There is a caveat, however, as changing the datatype for "dateadded" columns will break playlist sorting at the moment. That's probably why the type is set to TEXT presently. You only need playlists if you want to exclude your watched video items from recent video items. Otherwise
1.) Playlists for Widgets
2.) Datum fields in SQL database
Let's start with
2.) Datum fields
Kodi uses several columns for storing datums, like lastScraped, dateAdded, lastPlayed. For whatever reasons these are mostly defined as TEXT fields (Blobs) instead of DATUM fields. Changing the datatype to TIMESTAMP (on MariaDB, should be similar on MySQL) makes reading the tables faster. Also, DATUM fields are used in many queries, so an INDEX for DATUM fields is recommended.
Here are the columns I've found and changed to TIMESTAMP with beneficial effect:
a) mymusic72.db
- album-lastScraped
- artist-lastScraped
- audiobook-lastScraped
- song-lastplayed
- song-dateAdded
- versiontagscan-lastscanned
a) myvideos112.db
- episode-lastPlayed
- episode-lastChange
- files-lastPlayed
- files-dateAdded
- movie_watched-lastChange
- movie_watched-lastPlayed
- path-dateAdded
1. Playlists
I'm referring here to playlists that are used for widgets. Those are the biggest holdup in Estuary. You can try for yourself to replace in Includes_home.xml
withxml:
<include content="WidgetListPoster" condition="Library.HasContent(movies)">
<param name="content_path" value="special://skin/playlists/recent_unwatched_movies.xsp"/>
<param name="widget_header" value="$LOCALIZE[20386]"/>
<param name="widget_target" value="videos"/>
<param name="list_id" value="5200"/>
xml:
<include content="WidgetListPoster" condition="Library.HasContent(movies)">
<param name="content_path" value="videodb://recentlyaddedmovies"/>
<param name="widget_header" value="$LOCALIZE[20386]"/>
<param name="widget_target" value="videos"/>
<param name="list_id" value="5200"/>
(For TVShows, replace special://skin/playlists/recent_unwatched_episodes.xsp with videodb://recentlyaddedepisodes/)
Using a playlist produces a spinner that will stay for several seconds whereas the direct call is instantaneous. Also, after changing 1.) and 2.) exiting Kodi is also almost instantaneous.
There is a caveat, however, as changing the datatype for "dateadded" columns will break playlist sorting at the moment. That's probably why the type is set to TEXT presently. You only need playlists if you want to exclude your watched video items from recent video items. Otherwise