Doing this programmatically is just a no-go when themes are being set
in some other places (the toolbar is using a custom theme, in this
case), so, instead of hunting down the proper theme, just let the
system do its work.
- Add adjustment_step_key to settings_keys.xml to be used when
saving/loading the step size.
- Remove the global stepSize variable and the code that saves it to
outState/loads it from savedInstanceState because it's now saved to
Shared Preferences.
- Move initially setting step size to setupStepSizeSelector to be
consistent with the other view setup methods, using the value loaded
from Shared Preferences.
- Save the step size to Shared Preferences inside setStepSize.
Fixes: #7031
Removed some non-translatable strings and just hardcoded them in the code, like it's being done for other string separators. This also deduplicates some code by using Localization.
Used some Kotlin feature to reduce code.
This commit refactors the way `InfoItemDialog`s are generated. This is necessary because the old way used the `StreamDialogEntry` enum for most of the dialogs' content generation process. This required static variables and methods to store the entries which are used for the dialog to be build (See e.g.`enabledEntries` and methods like `generateCommands()`). In other words, `StreamDialogEntry` wasn't an enumeration anymore.
To address this issue, a `Builder` is introduced for the `InfoItemDialog`'s genration. The builder also comes with some default entries and and a specific order. Both can be used, but are not enforced.
A second problem that introduced a structure which was atypical for an enumeration was the usage of non-final attributes within `StreamDialogEntry` instances. These were needed, because the default actions needed to overriden in some cases.
To address this problem, the `StreamDialogEntry` enumeration was renamed to `StreamDialogDefaultEntry` and a new `StreamDialogEntry` class is used instead.
ExoPlayer right now fetches HLS video tracks even if you disable them (with setRendererDisabled or setSelectionOverride).
See issue 9282 of ExoPlayer's issue tracker for more information.
* Replaced by ``wasLastResolvedVideoAndAudioSeparated``
* Uses an ``Optional`` instead (we can't determine if the video and audio streams are separated when we did not fetch it)
Unable to compile!
* Cleaned up ``getMostCompactAudioIndex`` and ``getHighestQualityAudioIndex`` into a new method ``getAudioIndexByHighestRank``
* Removed unreadable code and use Java Streams API
* Tests work as expected
Prefering video-only streams to video streams for our player will allow us to make seamless transitions on 360 and 720p qualities on YouTube.
External players and the downloader are not affected by this change.
This is only available when playing video-only streams (and when there is no audio stream and only video streams with audio) and audio-only streams.
For more details about which conditions are required to get this transition, look at the changes in the useVideoSource(boolean) method of the Player class.
It ensures that queues are not the same. Without this check when you have multiple videos in the backstack and navigating back via Back button you'll get duplicated videos
This happened in fullscreen player: while play-pause, brightness, volume, ... buttons were correctly centered in the app UI, the fast seek overlay was centered in the system UI, causing a mismatch between the two that looked ugly
The previous/reverted behavior caused unwanted data transmission:
* Removed loading via handleResults/loadMoreItems-callback because the RecyclerView is apparently not immediately updated in the UI when the data is set which causes one load of data to much.
* Always recreate the footer so that it's not possible to attach the same instance twice
* Removed support for creating a custom footer as it's never used
* Supply the header with an supplier
* This might not fix the problem completely as we currently can only create the header once inside Channel, Playlist and RelatedItems-Fragment - allowing creation of multiple headers might be done in the future if the issues still arise
* Other minor fixes
The workaround set before was not applied when switching to main player with content thumbnail from popup or background player. This commit fixes this by applying the workaround when switching to main player with content thumbnail from popup or background player.
ExoPlayer's default behavior is to use a multiplication of target segment by a coefficient (3,5).
This coefficient (and this behavior) cannot be customized without using a custom HlsPlaylistTracker right now.
New behavior is to wait 15 seconds before throwing a PlaylistStuckException.
This should improve a lot HLS live streaming on (very) low-latency livestreams with buffering issues, especially on YouTube with their HLS manifests.
Instead of trying to reload the play queue manager and then throwing an error, BehindLiveWindowExceptions now make the app seek to the default playback position, like recommended by ExoPlayer.
The buffering state is shown in this case.
Error handling of other exceptions is not changed.
This checks if the uploaderUrl is in the database, if not it gets the
uploaderUrl and puts it in the database. This is similar to the fetching
of uploaderUrl when it doesn't exist done in #6919.
Also use createNotification when error occurs in getStreamInfo.
The issue was caused by an ExoPlayer change, which when setting a media source, resets the current playback position and the current window index by default.
Also set player recovery in more places to fix playback position not propely set in some cases after a player type switch.
* Consolidated main-setttings into a single file
* Debug settings are only enabled in the DEBUG build
* Moved LeakCanary (debug) specific stuff into a small class that's only shipped with the debug build
* Other minor fixes
* When rewinding: Check if <0,5s
* When fast-forwarding: Check if player has completed or the current playback has ended
This allows rewinding on the endscreen
* Deduplicated and simplified a lot of code
* Fixed ``invalidSeekConditions`` so that it's possible to seek while the player is loading (like currently the case)
