Notifications can be disabled manually even after permission has been granted once.
Always check if they are enabled before notifying the user.
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
Duration data in the player code incosnistently typed. Half code
uses ints and half uses longs. Recieve longs in this function to
allow both halfs of player code just use the function without
nasty long to int downcasting warnings/errors in code
This allows disabling these track types when stream info has been not
loaded while the ExoPlayer instance is.
It is now possible to do so with the background player, in order to
disable fetching video and text tracks for manifest sources,
especially used for livestreams.
Also set the recovery first before reloading play queue manager in the
useVideoAndSubtitles method of the Player class.
onNext() is called after onSubscribe() when creating a PlayQueueAdapter. For that reason the last broadcasted event is applied to the UI state although it is already reflected in the PlayQueue that was used to initialize the adapter.
This is the intended behavior of the previously used event broadcaster of the type BehaviorSubject<>. The broadcaster's type was changed to PublishSubject<> which does not emit the last event after onSubscribe().
Ref: https://github.com/TeamNewPipe/NewPipe/issues/9669
Room has been convereted into a KMP library in the latest stable releases and
annotation processing requires KSP which only generates kotlin classes
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
- audioTrackTextView: layout_width=0dp + layout_weight=1
- Make it singleLine with ellipsize="end"
- When not fullscreen, hide metadataView so an empty weighted container doesn’t reserve space
- Result: controls stay visible on small screens; longer labels can use space on larger screens
This commit fixes one way ghost notifications could be produced (although I don't know if there are other ways). This is the call chain that would lead to ghost notifications being created:
1. the system starts `PlayerService` to query information from it, without providing `SHOULD_START_FOREGROUND_EXTRA=true`, so NewPipe does not start the player nor show any notification, as expected
2. the `PlayerHolder::serviceConnection.onServiceConnected()` gets called by the system to inform `PlayerHolder` that the player started
3. `PlayerHolder` notifies `MainActivity` that the player has started (although in fact only the service has started), by sending a `ACTION_PLAYER_STARTED` broadcast
4. `MainActivity` receives the `ACTION_PLAYER_STARTED` broadcast and brings up the mini-player, but then also tries to make `PlayerHolder` bind to `PlayerService` just in case it was not bound yet, but does so using `PlayerHolder::startService()` instead of the more passive `PlayerHolder::tryBindIfNeeded()`
5. `PlayerHolder::startService()` sends an intent to the `PlayerService` again, this time with `startForegroundService` and with `SHOULD_START_FOREGROUND_EXTRA=true`
6. the `PlayerService` receives the intent and due to `SHOULD_START_FOREGROUND_EXTRA=true` decides to start up the player and show a dummy notification
Steps 3 and 4 are wrong, and this commit fixes them:
3. `PlayerHolder` will now broadcast `ACTION_PLAYER_STARTED` when the service connects, only if the player is not-null
4. `PlayerHolder::tryBindIfNeeded()` is now used to passively try to bind, instead of `PlayerHolder::startService()`
