Improve performance when starting slideshows and updating huge playlists

[wutschel]

Description

This PR is motivated by an issue raised in this forum post, which describes excessively long loading times when starting picture slideshows with several thousand pictures.

Background:

There are two root causes for the long loading times. First is related to the way how the App start the slideshow compared to how Kodi internal seems to do. The App for any file type will first build a playlist (Playlist.Add) and then play it from the desired position (Player.Open playlistid/pos). This requires the playlist to be built before the playback starts. Kodi internally seems to use a dedicated command to start playback (Player.Open path/random/recursive) which starts the playback before the complete playlist is built. Second cause is the way how Kodi and the App interact while the playlist is being built. The App reacts to Kodi's notification events Playlist.OnClear, Playlist.OnAdd and Playlist.OnRemove. For each event it rebuilds the playlist, which means sending a request to Kodi to provide the complete playlist. This lets Kodi prepare this information and send it back to the App, which then further processes this including animation of playlist. Problem is now starting because Kodi sends multiple notifications when building huge playlists. This results in ping-pong between App and Kodi slowing down building the playlist and letting the App do playlist updates for a long time.

Typical effect seen when starting a slideshow for a folder (including subfolder) with 21k pictures is that playback needs about 150 seconds to start, including permanent and visibly animated playlist updates on App side.

Solution:

The solution has two aspects. First part addresses the playback command: The App now uses Player.Open path/random/recursive for picture playback as well. This reduces the delay until playback starts drastically. It also resolves issues with Kodi crashing after several attempts to play large slideshows via the former method. Second part is addressing the handling of playlist update notifications. The PR implements debouncing of such notifications sent from Kodi. The debouncing is done via (re-)starting the timer debounceTimer each time a new notification arrives. Only after the timer finished the playlist update is executed. For picture playlists the timeout is 1.0 seconds (to support huge playlists), for other playlist types 0.2 seconds.

With these changes the playback starts in 4 seconds and the playlist updates end after 9 seconds.

Remarks:

• As a positive side effect Kodi now behaves stable when starting playback of several such huge slideshow after each other. The older way of starting playback caused Kodi to crash mostly on the 2nd attempt.
• Another effect is that now also videos which are part of the picture folders are listed in the picture playlist. This seems to be a common situation as users might have pictures and short videos mixed e.g. when taken from smartphones or digital cameras. Kodi does now show the pictures and plays the videos following Kodi's playlist.
• The App needs to be reworked to not jump between playlists when playing mixed (picture + video) playlists.

Summary for release notes

Improvement: debounce playlist update notifications Improvement: quicker slideshow start by using Player.Open on path

[wutschel]

@kambala-decapitator, there are two choices on how to move on with this on. Either we take this as a whole and I update the PR description (would be quite lengthy, but this is a big change), or I split off the performance improvement (first 3 commits) from the state machine / animation rework and make a 2nd PR. Please share your thoughts.