Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a play next button to the long press menu #6872

Merged
merged 44 commits into from
Sep 18, 2021

Conversation

z3r0r4
Copy link
Contributor

@z3r0r4 z3r0r4 commented Aug 7, 2021

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

Adds a play next button in the long press menu of a video, as asked for in #4136.

  • add getPlayerNextIntent in NavigationHelper
  • handle not Append Only Intent in Player class
  • add nextOn*Player functions in NavigationHelper
  • create new StreamDialogEntry: next
  • add new entry to the BaseListFragment
  • add Strings for names

Before/After Screenshots/Screen Record

Before After

Fixes the following issue(s)

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR.

Due diligence

Critique / Todo

  • remove my comments
  • reduce code duplication
  • add translation strings

@z3r0r4 z3r0r4 changed the title added mvp play next button in long press menu Added a play next button to the long press menu Aug 7, 2021
@AudricV AudricV added feature request Issue is related to a feature in the app GUI Issue is related to the graphical user interface player Issues related to any player (main, popup and background) labels Aug 8, 2021
to make long press entry more descriptive

Co-authored-by: opusforlife2 <53176348+opusforlife2@users.noreply.github.com>
Copy link
Member

@Stypox Stypox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for adding this requested feature :-)

Sorry for the many things I asked you to do, feel free to ask for help or delegate something to me if you can't figure it out ;-)

app/src/main/res/values/strings.xml Outdated Show resolved Hide resolved
Co-authored-by: Stypox <stypox@pm.me>
@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Aug 9, 2021

Thank you for adding this requested features :-)

Sorry for the many things I asked you to do, feel free to ask for help or delegate something to me if you can't figure it out ;-)

My pleasure!
Thank you for the thorough review. Some of the requested changes should have been quite obvious optimizations when the goal is more than a mvp.
As long as it isnt urgent i'll get it done by myself (hopefully this week).
I might be back for some clarification on how to integrate your code though.

@SameenAhnaf
Copy link
Collaborator

A few bugs found.

  1. Play queue become inaccessible once 'Play next' is selected. User needs to click on Background or selected player button. Also, some videos get multiple times although selected just once.
    https://drive.google.com/file/d/1BJnia6hJJasVy_LY-90n9eK4UQH7Czp2/view?usp=drivesdk

  2. There are multiple bugs here. Watch the video for more details.
    https://drive.google.com/file/d/1BHzXe_Wf1YdcACAjEmAo5RmmLComv4ni/view?usp=drivesdk

@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Aug 10, 2021 via email

@MD77MD
Copy link

MD77MD commented Aug 11, 2021

just s suggestion... could we call it "enqueue next"... also more consistent.

this is what VLC uses if I remember correctly.

@Stypox
Copy link
Member

Stypox commented Aug 13, 2021

@MD77MD mmmh yeah, I agree with you

@opusforlife2
Copy link
Collaborator

Hmmm. If there is only the current video in the queue, Enqueue and Enqueue Next will have the same function. Should the button check for >1 items in the queue before showing?

z3r0r4 and others added 6 commits August 15, 2021 16:20
Co-authored-by: Stypox <stypox@pm.me>
…d RESUME_PLAYBACK/ deprecate enqueueNextOn*Player and enqueueOn*Player methods

add getPlayerIntent, getPlayerEnqueueIntent and getPlayerEnqueueNextIntent without selectOnAppend and RESUME_PLAYBACK/ deprecate those with
add section comments
removed redundant methods
removed redundant methods
@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Aug 15, 2021

A few bugs found.

1. Play queue become inaccessible once 'Play next' is selected. User needs to click on Background or selected player button. Also, some videos get multiple times although selected just once.
   https://drive.google.com/file/d/1BJnia6hJJasVy_LY-90n9eK4UQH7Czp2/view?usp=drivesdk

2. There are multiple bugs here. Watch the video for more details.
   https://drive.google.com/file/d/1BHzXe_Wf1YdcACAjEmAo5RmmLComv4ni/view?usp=drivesdk

I cant seem to replicate these anymore, would it be possible for you to check again @SameenAhnaf ?

@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Aug 15, 2021

I do have to note a new bug tho:
The play next option is inaccessible when selecting videos inside of a playlist.

I think it might not be referenced in the code which generates the dialog inside of playlist, dont know yet where to check though

@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Aug 15, 2021

I do have to note a new bug tho:
The play next option is inaccessible when selecting videos inside of a playlist.

I think it might not be referenced in the code which generates the dialog inside of playlist, dont know yet where to check though

b8ebda7 fixes this hopefully

z3r0r4 and others added 2 commits September 12, 2021 21:16
Co-authored-by: Stypox <stypox@pm.me>
Co-authored-by: Stypox <stypox@pm.me>
Copy link
Member

@Stypox Stypox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for keeping asking for changes, I hope this is the last one. Just to be sure, please make sure that the if (player is open) before enqueueing is removed everywhere, and that the play next action is available in every long press menu of each fragment. Thank you :-)

@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Sep 13, 2021

I've checked the fragments mentioned in this comment and I could not find a dialog which doesnt include a play next action.

Copy link
Member

@Stypox Stypox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@Stypox Stypox merged commit 70354eb into TeamNewPipe:dev Sep 18, 2021
@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Sep 18, 2021

my pleasure.
Thank you for the helpful feedback!

This was referenced Oct 2, 2021
@@ -82,7 +84,6 @@ private NavigationHelper() {
intent.putExtra(Player.PLAY_QUEUE_KEY, cacheKey);
}
}
intent.putExtra(Player.RESUME_PLAYBACK, resumePlayback);
Copy link
Member

@TobiGr TobiGr Oct 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NewPipe stopped resuming playback for all streams. This PR seems to be the cause of this.

Can you please explain, why the resumePlayback parameter has been removed from all methods? It was not true everywhere before. What was the reason to make it true all the time?

Also, why has this line been removed? Shouldn't it be

        intent.putExtra(Player.RESUME_PLAYBACK, true);

if resumePlayback was always true?

CC @z3r0r4 @Stypox

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it work if you readd that line?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From #7268:

Pressing the "background" button while a video is playing does not resume the stream, but still starts at the beginning.

Copy link
Member

@Stypox Stypox Oct 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, resumePlayback should always be true like you said, I don't know why I didn't notice it was removed altoghether. But now I was asking whether by readding the line you commented on (and replacing resumePlayback with true) fixes the issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to find out how to fix it now

TobiGr added a commit that referenced this pull request Oct 17, 2021
@TobiGr TobiGr mentioned this pull request Oct 17, 2021
5 tasks
Copy link
Member

@Stypox Stypox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I analyzed things a little bit, here is what I saw:

  • the only places where resumePlayback was false for enqueue actions were the ones I pointed out in the . review comments
  • enqueueuing can currently happen in two ways
    • when no video is already playing. In this case having resumePlayback=true makes sure the video is resumed, otherwise it isn't. Before this PR the only situation when it can happen that a video is enqueued when none were already playing and resumePlayback is false, is when the user long-presses the background or popup buttons in the video detail fragments (the first two . review comments; the third one can never be triggered when no video is already playing since the enqueue option would not be shown in the stream dialog menu in that case).
    • when something is already playing. In this case the resumePlayback value is simply ignored and the stream will start from the beginning when its turn will come. So having resumePlayback=false in the stream dialog menu (the last . review comment) does not make a difference to having it set to true.
    • => I think we can safely set resumePlayback=false for every enqueue action, since it only really makes a difference when there is no player running and long-pressing the control buttons in video detail fragment, playlist & channel. This way a user could start a video with resumePlayback=true by normal-pressing the background/popup button, and with resumePlayback=false by long-pressing the background/popup button. And in my opinion it makes sense not to resume playback when enqueueing.
  • this PR accidentally sets resumePlayback=true for every single action (being it enqueue or not). This is an error, mostly caused by not noticing that:
    • there were places where the enqueue action had resumePlayback=false
    • the playOnMainPlayer, playOnPopupPlayer and playOnBackgroundPlayer functions also used getPlayerIntent. After removing the resumePlayback parameter from getPlayerIntent Android Studio didn't give any error on those functions, since there was another overload of getPlayerIntent with parameters (Context, Class, PlayQueue, boolean), but the last parameter was playWhenReady instead of resumePlayback!

I will soon create a PR reinstantiating resumePlayback as it was before, except setting it to false in all enqueue actions as I explained above. Is this ok @TobiGr @Redirion ?

@@ -1096,8 +1097,8 @@ private void openPopupPlayer(final boolean append) {
toggleFullscreenIfInFullscreenMode();

final PlayQueue queue = setupPlayQueueForIntent(append);
if (append) {
NavigationHelper.enqueueOnPopupPlayer(activity, queue, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@@ -1155,7 +1156,7 @@ private void openNormalBackgroundPlayer(final boolean append) {

final PlayQueue queue = setupPlayQueueForIntent(append);
if (append) {
NavigationHelper.enqueueOnBackgroundPlayer(activity, queue, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

Comment on lines -69 to -78
if (type == AUDIO) {
NavigationHelper.enqueueOnBackgroundPlayer(fragment.getContext(),
new SinglePlayQueue(item), false);
} else if (type == POPUP) {
NavigationHelper.enqueueOnPopupPlayer(fragment.getContext(),
new SinglePlayQueue(item), false);
} else /* type == VIDEO */ {
NavigationHelper.enqueueOnVideoPlayer(fragment.getContext(),
new SinglePlayQueue(item), false);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.

@TobiGr
Copy link
Member

TobiGr commented Oct 20, 2021

@Stypox That depends on how long you need to create the PR. If you can do it today, please do it. Otherwise I suggest to revert this PR and re-do it. We need to publish a fix quickly.
(If you create a PR, please target release/0.21.13)

@Stypox
Copy link
Member

Stypox commented Oct 20, 2021

I don't think I'll make it in time for today; tomorrow I will have time for sure though

Edit: maybe I found some time

Stypox added a commit that referenced this pull request Oct 20, 2021
TobiGr pushed a commit that referenced this pull request Oct 20, 2021
@TobiGr TobiGr mentioned this pull request Oct 21, 2021
5 tasks
@z3r0r4
Copy link
Contributor Author

z3r0r4 commented Oct 25, 2021

It seems to be solved, still here's the specific commit where I deprecated the needed function and my comment on it for future reference.
I think I should have been more clear with my objection / notice.
bea56dd (deprecated here, removed in the next ones)
#6872 (comment) (minor comment hinting to the problem)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issue is related to a feature in the app GUI Issue is related to the graphical user interface player Issues related to any player (main, popup and background)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

add „pre-queue“ option Feature Request: Add "Play next" button
10 participants