TeamNewPipe
Add Enqueue button in "Always Ask" Share Menu
Checklist
- [x] I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
- [x] I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
- [x] This issue contains only one feature request. I will open one issue for every feature I want to request.
Describe the feature you want
Until newPipe 0.20.2, while playing a video in background or pop-up mode, sharing another video from others apps to newPipe would enqueue them directly. However this is changing in the upcoming release because it was determined to be bad UX #4562. therefor I am raising this issue to discuss an alternative for it.
A direct quote from developer:
When sharing a video to NewPipe and a play button is pressed, replace the current queue instead of enqueueing. Enqueueing can still be achieved opening info and then enqueueing, but enqueueing directly was bad UX since the user would not see what happened.
Is your feature request related to a problem? Please describe it
These are my related conversations with the developer about this issue: https://github.com/TeamNewPipe/NewPipe/pull/4562#issuecomment-712496743, https://github.com/TeamNewPipe/NewPipe/pull/4562#issuecomment-719837705
To summarize: when a video is shared, enqueueing to pop-up or background mode was done directly, however Stypox suggested an alternative to direct enqueueing by shareing video to newPipe, then opening its details from menu, then long pressing enqueue button... however this was a tedious alternative as it would take too much time and effort to do so compared to old method, especially if multiple videos are to be enqueued.. (you can try enqueueing 5 video yourself to see the vast difference).
also when sharing to pop-up or background mode, users actually do not really want video details... they actually just wants the video to be enqueued... if the users indeed wanted video details they would have choosen the first option (video details). ..more so, it results in wasting data for loading the video details page for each video.
Additional context
The alternative for old enqueueing method should be as easy as the old method (enqueueing directly).. it sould avoid wasting to much time and data.
@opusforlife2 suggested when the share menu appears, long pressing on pop-up or background option would enqueue the video ... my suggestion isn't far away from his but more intuitive if that's the right word. Instead of long pressing, a ( + )"plus sign" or something similar is to be added next to both modes on the right.
The work done in #4425 "Replace specific enqueue options with one" could be used to inspire more alternatives.
How will you/everyone benefit from this feature?
Makes life a little bit easier... but seriously, try enqueueing 5 video yourself in both ways to see the vast difference.
We don't need anything so complicated. Just an additional "Enqueue" option in the "Always Ask" menu will be enough. It should only show when a stream is open.
Long pressing inside a menu seems like bad UX, anyway.
Your title should directly state what you want. Your feature request in one line. Not a description of the situation or what will happen in the future.
Your title should directly state what you want. Your feature request in one line. Not a description of the situation or what will happen in the future.
I had hard time describing this, because this problem is not there yet. and in order for newcomers to understand what I'm talking abou i had to build up from scratch .... i think next time I'm just gana pretend it's already there ... building the explanation for the issue was not worth the amount of time i spent.
You can freely explain in your own words in the issue body. The title though has to contain certain keywords so interested users will know they are opening the correct issue.
I think enqueuing is too specific for this dialog. The point of the dialog is to define a default action which should be run automatically while opening a link outside from NewPipe - that's why there is "Just once" and "Always" ;)
Enqueing like this is coupled to the situation that there's already NewPipe playing a stream, therefore this action wouldn't stand "for its own" like the others do (I hope you understand what I mean :'))
Good point. What if the "Always" button is greyed out if Enqueue is selected?
Or, or, when a user shares a link to Newpipe and another stream is open, we could show a dialogue saying "Stream already playing:
Play now, Enqueue, Cancel".
So it seems you can do this with newer versions according to @Stypox, but the steps are awful [1]. First, change your NewPipe default from "Background player" to "Show info". Then, here is what you have to do for each video to be added:
- Long press link
- Click Open With NewPipe App
- Long press Background
Compared to previous:
- Long press link
- Click Open With NewPipe App
I will continue to use the old version [2] until this is resolved.
- #4562 (comment)
- https://github.com/TeamNewPipe/NewPipe/releases/tag/v0.20.2
@89z better yet, you can instal the legacy version 20.2 of newpipe to handle shared links, and normal newpipe (or block adds version) for normal use. this way you can still enjoy the latest version with all its features.
this is what we have to do when no buddy cares to listen anymore 🙁
@MD77MD how do you get 2 different versions of the same app installed at the same time?
@MD77MD how do you get 2 different versions of the same app installed at the same time?
actually new publicity is a bit different with a different signature... that's why android consider them aa two different apps because they effectively have two different signatures
this is the link to newpipe legacy version: (or ] can find it yourself from from the TeamNewpipe page;
https://github.com/TeamNewPipe/NewPipe-legacy/releases/tag/v0.20.2
P.S: only up to v0.20.2 still have enqueue, later versions dont lost this feature.
An unfortunate break in functionality from the earlier versions, hope a simple UX can return. The "official" flow described by @89z is far too convoluted for such an obvious task.
I just don't get why issues about this functionality are being closed one by one without solving it?
@s1awek Duplicate issues are not required to solve a single problem? A single issue needs to stay open regarding this.
So what issue is now active? Because so far all the issues I've been watching so far been closed.
@s1awek Duplicate issues are not required to solve a single problem? A single issue needs to stay open regarding this.
So what issue is now active? Because so far all the issues I've been watching so far been closed.
This one here you just commented is still active.
the only thing we're good at here in newpipe is closing issues not solving them lol
@MD77MD Just wondering if Google have some spies here just to destroy development process from inside ;)
Hello,
I'm new to this project. However, my daily routine relies on the "enqueue" to background player heavily, and I actually never use NewPipe UI but sharing video streams from YouTube app instead. My use case looks like:
- Open YouTube App.
- Search my favorite talk shows and share to NewPipe background player.
- Continue enqueue few shows since I'll listen to them while driving.
I'm not sure what is the policy of the core UI team. I just did a minimum fix since I REALLY needed to do this every single morning. :) My fix added "Enqueue background" option to the menu which means "enqueue to background player only" to avoid UI confusion:
You can find the release apk here: https://github.com/SavantOne/NewPipe/releases/tag/v0.20.11-patch
I'll probably patch once a while depending on the official NewPipe release. I cannot rely on old 0.20.2 forever since YouTube may change constantly as we all know. Let me know if you think I should send PR for this change and appreciate if someone from the core team can point me to the test process and/or review process.
Hello,
I'm new to this project. However, my daily routine relies on the "enqueue" to background player heavily, and I actually never use NewPipe UI but sharing video streams from YouTube app instead. My use case looks like:
- Open YouTube App.
- Search my favorite talk shows and share to NewPipe background player.
- Continue enqueue few shows since I'll listen to them while driving.
Since I'm not sure what is the policy of the core UI team. I just did a minimum fix since I REALLY needed to do this every single morning. :) My fix added "Enqueue background" option to the menu which means "enqueue to background player only" to avoid UI confusion:
You can find the release apk here: https://github.com/SavantOne/NewPipe/releases/tag/v0.20.11-patch
I'll probably patch once a while depending on the office NewPipe release. I cannot rely on old 0.20.2 forever since YouTube may change constantly as we all know. Let me know if you think I should send PR for this change and appreciate if someone from the core team can point me to the test process and/or review process.
@s1awek this what i was complaining about, how many issues where opened and closed for this simple fix, actually it was a function that was already there and removed by devs. and believe it or not, but i had much talk with dev about not removing it before they did... they told me no one needs it, however as you see people do need it.
anyway, i wish you would not accuse people just like that.
@MD77MD
anyway, i wish you would not accuse people just like that.
You referring to "google spies" i mentioned earlier? I did not accuse anyone that was just a joke mate. Maybe a bad one though.
@MD77MD
anyway, i wish you would not accuse people just like that.
You referring to "google spies" i mentioned earlier? I did not accuse anyone that was just a joke mate. Maybe a bad one though.
I see, i guess i took it the wrong way... cheers...
btw thank you @chouhanyang for fix,
anther workaround i mentioned earlier, is to use newpipe legacy version 20.2 of newpipe to handle shared links, because best version still has that automatic enqueue function. that is until this fix is merged (god knows when😆)
You can find the release apk here: https://github.com/SavantOne/NewPipe/releases/tag/v0.20.11-patch
Installed this 4x now (twice on 2 phones) and I don't see the enqueue option.
@thinsoldier it's probably because now you have 2 NewPipe icons in share menu. Just pick a second one when sharing or you can just completely uninstall original app.
I suggested a better solution in #5840.
Your wish: Add "Enqeue" option in "Always ask" share memu My wish: Include a separate option "Auto-enqueue videos shared from other apps if a media is playing" in settings.
Most expectedly, if a media has been already playing, I will enqueue the next video. If a user is never or rarely supposed to enqueue videos, he can disable or enable this option at any time.
There's no need to tripple tap (choose background player or popup again). Rather, double tap (1. Click Share, 2. Choose Newpipe) every time is enough.
There should be no "+" icon beside background player and popup as it may cause accidental touches. Plus, the UI should always stay clean and minimalist.
"Enqeue" option can't be directly included in "Preferred "Open" Action". There will have to be options like "Start playing on the background or enqeue" and "Start playing on popup or enqeue". That actually sounds pretty confusing. A separate option could easily solve the problems.
I suggested a better solution in #5840.
Your wish: Add "Enqeue" option in "Always ask" share memu My wish: Include a separate option "Auto-enqueue videos shared from other apps if a media is playing" in settings.
Most expectedly, if a media has been already playing, I will enqueue the next video. If a user is never or rarely supposed to enqueue videos, he can disable or enable this option at any time.
There's no need to tripple tap (choose background player or popup again). Rather, double tap (1. Click Share, 2. Choose Newpipe) every time is enough.
There should be no "+" icon beside background player and popup as it may cause accidental touches. Plus, the UI should always stay clean and minimalist.
"Enqeue" option can't be directly included in "Preferred "Open" Action". There will have to be options like "Start playing on the background or enqeue" and "Start playing on popup or enqeue". That actually sounds pretty confusing. A separate option could easily solve the problems.
to tell you the truth, both options are needed, as both have there own use case scenario. however i did not dear to ask for both. moreover the feature you are asking for was originally there and was oddly removed by one of the devs.
so i would suggest to keep both requests, perhaps one of them would go through.
@MD77MD You are right, bro. Users should be given the flexibility to do so in both ways. However, "Enqeue background" option should be replaced by only "Enqeue" option. Anyone may ask for enqeuing videos on popup as well.
@chouhanyang thank you for the contribution. Could you open a PR for that? I wasn't able to implement that properly before since there were crashes, could you open a PR so that we can discuss the implementation and merge it?
this what i was complaining about, how many issues where opened and closed for this simple fix, actually it was a function that was already there and removed by devs. and believe it or not, but i had much talk with dev about not removing it before they did... they told me no one needs it, however as you see people do need it.
@MD77MD Right from the beginning I think everyone agreed this could be added, but since there were problems with the implementation we (I) preferred not to provide a broken implementation, since a workaround is available. @chouhanyang did the right thing: he looked into the problem and found a way to solve it. Your tone instead is just counterproductive: complaining does not help, and one of the reasons I've not contributed much to NewPipe lately is because of such comments. If you think an issue is particularly important but we developers have a different idea, then try to help us anyway you can, e.g. describing the issue perfectly, providing various possible implementations and behaviours, analyzing pros and cons, explaining alternative solutions & showing why your solution is better, taking into consideration all of the consequences of a feature (like a more cluttered ui), ... (ideally learning Java and opening a PR, but that doesn't count). You did some of this, and you helped clear some doubts, but the bad comments just ruin everything. If, when a developer has the time to implement a feature, he finds a well-described one, where an agreement has already been reached between both parties and there is a clear solution that just needs implementing, it is far more likely that he will take it up. Instead, if he finds an issue where the proposed feature could benefit a user group but hurt another, where there is no pros-cons analysis and where there are hateful comments, probably he will just do something else (and maybe even feel frustrated).
An example of what I'm describing is https://github.com/TeamNewPipe/NewPipe/pull/4534#issuecomment-741700417 Before my comment there were many possible implementations available, but it wasn't clear which one would be the best. After my comment, instead:
- three different alternatives have been proposed. Finding clever ideas is something everybody can do, if only they dedicate some time to it. I probably spent one hour thinking (just thinking!) about how to solve #4534 (fun fact: here are the sketches I drew)
- the implementation details for each possible alternative were clear
- pros and cons were analyzed and tradeoffs were clear
- a clear consensous was reached
The only problem was that I had to write that comment myself: if it had been already there I would have probably taken up the issue much earlier and I wouldn't have wasted time on implementing a solution which at the end was discarded. Anyway, at least the discussion was constructive, there were no putting-off comments: if that were the case I would have probably just ignored them and done something else. It is really really frustrating to try to mediate between the needs and the opinions of many people, when nobody is willing to change their mind ever so slightly until the perfect solution is proposed by someone else. And sometimes there is not even a perfect solution.
@Stypox Thanks for the pointer. A pull request is created and feel free to review/comment. In the mean time, I just setup an dev environment with physical device debugging, and it's pretty fun. Let me know if I could help a bit on other issues if you have in mind. And appreciate your contribution to this project.