When Kore retrieves the data over HTTP the playlist would be
refreshed every 4 seconds. This caused the playlist to jump to
the top when scrolled down. This has been fixed by checking if
the new playlist is different from the current playlist. If not
* Reverted gradle plugin upgrade to prevent forcing users to
upgrade to Android Studio 4 preview version.
* Refactored TVShowsActivityTests into using the AndroidX libs.
* Updated test setup to handle saving tab state in abstract list fragment.
Migration to AndroidX
- Update to API level 29
- Update Java sourcecode and xml import statements
- Upgrade Butterknife Version 10 AndroidX support
- Set Java 8 compile options due Butterknife needs it
* Uri encoding for local filenames. Kodi should now be able to play http-served files with spaces or other special characters in their name.
* Uri encoding for local files served with "share with Kore".
* Fixes race condition in MediaFileListFragment
The "Play from here" feature previously queued all songs at once using
a loop and did not wait until an add action was confirmed by Kodi
before queueing the next item. This sometimes resulted in a seemingly
random play order on Kodi.
* Fixed play from here adding first item twice
When selecting "Play from here" in the file browser the current
item is started using "playMediaFile" and the subsequent items
are queued. However, the current item was added to the queue
list as well. Resulting in the first item always being added twice
to the playlist.
* Added menu options to PVR recordings view fragment: Sorting and hide_watched option.
Default to unsorted (showing the order delivered by Kodi). Default to not hide watched recordings. (#385)
* Implemented sorting and filtering of PVR recordings as per user's selection. (#385)
* Local media files (image, audio, video) can now be shared with Kore. Added token to HttpApp to improve security.
* Added 'Queue on Kodi' share option. 'Play on Kodi' skips the playlist while 'Queue on Kodi' puts the media link at the end of the playlist
Preferences for the Nav Drawer and Bottom Bar shortcuts weren't being properly saved. This fixes that and also fixes the order or the Navigation Drawer items, after the addition of the Local Files option.
SettingsActivity does not inherit from BaseActivity which caused
the preferred locale not to be set. This was not apparent when
switching to the Settings screen as the preferred locale would
already have been set by a previous activity which does inherit
from BaseActivity (e.g. RemoteActivity). Therefore we needed
to explicitly set the preferred locale as well in SettingsActivity.
This PR fixes some issues with connections and threading. Specifically, the change in #618 introduced threading in `HostConnection`, which had some issues. To fix them, the following changes were made:
- A specific TCP listener thread is used and manually started, instead of using one of the threads in the pool. The TCP listener thread is a long lived thread that should always be running (as long as the connection is through TCP), blocked listening on the TCP socket, so it shouldn't be managed in a pool, where, theoretically, it can be paused and reused.
- Changed the number of threads to 5. We shouldn't need more than this, otherwise we can overwhelm some Kodi hardware.
- Had to sprinkle some `synchronized` to avoid race conditions. For instance, through a TCP connection, as soon as Kore is opened (on the remote screen) it will call at least `GetActivePlayers`, `GetProperties`, `Ping`. If the TCP socket isn't set up yet, each of these calls would create a socket (and a TCP listener thread), so we would open 3 or more sockets when we should just open 1. A `synchronized` in `executeThroughTcp` prevents this. The others prevent similar issues.
- Tweaked the playlist fetching code, so that it happens exclusively in `HostConnectionObserver` and when PlaylistFragment is notified of changes, it already gets the playlist data. This somewhat simplifies the code, and makes it more consistent with the Player Observer code;
- Change `EventServerConnection` to accept a Handler on which to post the result of the connection, so that the caller can control on which thread the result is called;
- Calls to the various `RegisterObserver` loose the reply immediately parameter, as it was always true.