Fix enqueuing behavior

[dtcxzyw]

What is it?

• Bugfix (user facing)
• Feature (user facing)
• Codebase improvement (dev facing)
• Meta improvement to the project (dev facing)

Description of the changes in your PR

• Show Enqueue menu item even when the play queue is empty.
• First enqueued video/audio will remain paused by setting playWhenReady to false.
• Buffering the paused video/audio (Tested on my device, but I can't tell from the visual feedback that it's working).

Before/After Screenshots/Screen Record

• Before:

before-mute.mp4

• After:

after-mute.mp4

Fixes the following issue(s)

• Fixes Queueing logic when queue is empty (bug?) #2611
• Fixes Show Enqueue menu item even when no current video playing #8151

APK testing

Debug APK

Due diligence

• I read the contribution guidelines.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication

[Stypox]

Thank you for the contribution! Unfortunately I think we don't want this behavior:

• Enqueue means "Add to the queue", so it doesn't make sense as an action if there is no queue.
• Which player should be opened? Background, popup or main? There is no single answer.
• Why start paused? This would look like a random action happening for the user who isn't aware, and anyway we don't want new random behaviors without a natural meaning.
• Also, there could be issues when the player is still starting and receives another enqueue intent: it might not be happy and react with a crash.

[opusforlife2]

Enqueue means "Add to the queue", so it doesn't make sense as an action if there is no queue.

@Stypox This is how music apps behave. Try Vanilla Music, for example.

Why start paused? This would look like a random action happening for the user who isn't aware, and anyway we don't want new random behaviors without a natural meaning.

See the linked #2611. I would argue this is the natural meaning.

Also, there could be issues when the player is still starting and receives another enqueue intent: it might not be happy and react with a crash.

Can that not be guarded against programmatically? And is it not already possible to cause this in the current release? Enqueuing something while the player is still starting?

Which player should be opened? Background, popup or main? There is no single answer.

I think the enqueuing should be done in the background player. If you're not actively opening the popup or main player using the relevant buttons, and are only building a queue from scratch, you likely don't want to switch to video watching just yet.

[Stypox]

@opusforlife2 then instead of overloading the Enqueue button, I would create a new button named "Start paused in the background" that is only shown when there is no player active/starting.

[opusforlife2]

@Stypox It will have the same purpose, but sure. Will it then be a swap between Enqueue and Start paused based on whether a player instance is already open?

[Stypox]

Will it then be a swap between Enqueue and Start paused based on whether a player instance is already open?

Yes, always either one or the other (or none, while the player is starting), in the same place

[dtcxzyw]

Creating a new button might be more user-friendly.
I try to handle the case that the player is still starting when enqueuing.
Is there anything else that needs to be modified? @Stypox

[Stypox]

No, I think adding a new button "Start paused in the background" to the long-press menu would be enough. Make sure to only show that button if the player is not open (if the player is open but the play queue is null, nothing should be shown; if the player is open and the play queue is not null, then the "Enqueue" should be shown)

[opusforlife2]

I try to handle the case that the player is still starting when enqueuing.

Are you saying this cannot be done, @Stypox? Or that it should not be done in this PR?

[Stypox]

Both ;-)

I mean, everything is doable, but enqueueing things while the player is starting sounds complicated, thus I'd suggest to do it after the player and the ways it can be started have been refactored

[opusforlife2]

@dtcxzyw Then if you're interested in handling the player-still-starting case, keep an eye on #8170 and similar future PRs. Is that okay, @Stypox?

[opusforlife2]

This PR wasn't being blocked by #8170 except for a particular case. Are you interested in going further with this, @dtcxzyw?

[Stypox]

Closing since there has not been an answer for a while, feel free to reopen ;-)