Unified player should be optional, makes the app useless in certain scenarios

[nbmrjuhneibkr]

Checklist

• I am using the latest version.
• I checked, but didn't find any duplicates of this issue in the repo.
• I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

1. Add tracks to the background queue.
2. Try playing a video in NewPipe.
3. Background queue is erased.

New "unified player" makes the app useless if I want to use background player independently from the video player. I'm filing this as a bug, because this is something that worked perfectly fine in v0.19, but is completely broken now due to some questionable features being implemented in v0.20.

Actual behaviour

When I have tracks in the background queue (either playing or paused), and then try to watch a video in NewPipe, my background queue (which is valuable user data) gets erased without any warnings. This is default behavior in 0.20. The option "Ask for confirmation before clearing a queue" (which is disabled by default) adds a warning (that sometimes doesn't work - #4459 ), but does nothing to solve the actual problem. The fact that this option even needs to exist now is a clear indication that current implementation is wrong.

I have music and podcasts in my background queue pretty much 24/7, which means that I can't use NewPipe as a video player anymore without constantly losing my queue. And combined with #4458 this means that now I can't even open a video from NewPipe in another player without losing my background queue.

Expected behavior

There should be an option to use background player independently from the video player, just like in previous versions. These players serve a different purpose, and may be used for very different types of content.

Device info

• Android version/Custom ROM version: Android 11
• Device model: Pixel 3a

[hipunk]

Yes! Pleeaase make it optional!

I can only speak for myself, but let me tell you this:
I'm almost always listening to something using newpipe with the background player. Podcasts and music, it happens very often.
In 0.19 and earlier: if somebody sent me a youtube link in e.g. WhatsApp or Discord or whatever, I'd tap it and open it with newpipe using its popout player (most of the time, that is).
Now, with 0.20.0 I can't do that anymore, because if I'd do that, the music or podcast wouldn't only pause playing, it'd even stop & vanish from the queue. So now I oftentimes choose to open the youtube link with my browser, e.g. Chrome, in order to prevent the music or podcasts from getting lost. You devs should really be aware of this.

Do you, as a dev, really want your users to use your app less than before?

[opusforlife2]

Hmmm... option to have separate queues for the 3 players? Maybe pick and choose 2 players to have a common queue (like main and popup, but separate background queue)?

[nbmrjuhneibkr]

I don't use the popup player, so I can't comment on that, but there definitely needs to be an option to have a separate queue for the background player. Lots of people keep their audio and video players separate from each other.

[opusforlife2]

I would love that option as well. What you play in the background player is usually very different from what you play in the main or popup players.

[avently]

@nbmrjuhneibkr

New "unified player" makes the app useless

but is completely broken

questionable features

So you think that when you talk like this the devs will want to help you?

[nbmrjuhneibkr]

I'm thinking that it's rather strange that the devs let a major regression like this make its way into release after such a long development process.

All of the statements you quoted are factually correct in the context of this issue.

[opusforlife2]

The problem is precisely that "long development process" you mention. Because this was such a massive change, there were bound to be lots of bugs in the final release, even though we tried to spot as many of them as possible. Now what we need is rapid user feedback and some small releases to address critical bugs, and eventually those of lesser and lesser urgency in further releases.

[nbmrjuhneibkr]

The problem with this one is that it isn't really a bug, but rather a deliberate design decision that completely removes previously possible usage scenarios due to its limitations. I submitted it as a bug anyway, and described my reasons for doing this.

[opusforlife2]

I wasn't addressing this bug in particular, but just the general flood of new issues opened after the release was published. We expected this would happen. Now we will work to address them one by one.

[panacist]

for the seek of playing 360p videos on my replicant os i do give my vote on this! unified player should be optional.

[opusforlife2]

@panacist Wat. What does that have anything to do with this issue?

[kapodamy]

seconding for making it optional, there so many bugs (or weird behaviors) thats make imposible to use

[opusforlife2]

Oh hey, long time no see, @kapodamy! Why are you not on the IRC channel?

[streaps]

I would agree, these are not code bugs, but usability bugs = bad UI design and bad UX due to sudden changes in the behaviour. The new version is kind of depressing (UX wise. It seems the app is more stable, crashing less often and a bit snappier).

[yiiii777]

So you think that when you talk like this the devs will want to help you?

Maybe devs wants new fork of entire project?

For me, version 0.20 is totally unusable for me, I was very angry and downgraded to 0.18... But when YouTube will change their interface, what options remains for me? Maybe I can find any other player? Or write another, "very tiny and simple, without bloatware" app? Like newpipe was sometime...

[yiiii777]

crashing less often and a bit snappier

Got in few minutes of usage

[Stypox]

Got in few minutes of usage

Will be fixed in 0.20.1

[hp8wvvvgnj6asjm7]

the latest release was a total gnome move. Can someone please fork this project before it gets out of hand?

[opusforlife2]

the latest release was a total gnome move. Can someone please fork this project before it gets out of hand?

You're a Github user. Be proactive and use the Fork button. :P

[hp8wvvvgnj6asjm7]

@opusforlife2 is this a nice way of saying, go fork yourself? :D

[opusforlife2]

That is genuinely hilarious. I bow to your comedic genius. xD

[kubo6472]

ClassicPress 2.0?

[cyber199]

While I don't disagree with the unified player, I can see the background queue being erased as being a problem. I could see a user trying to enqueue a YouTube video or Soundcloud song in the background while listening to their queue and accidentally erasing the list. The background player, i.e. the one with no video, would benefit from not being unified with the foreground players (fullscreen and popup) in this scenario.

[Stypox]

I like the "add to playlist" button

[nbmrjuhneibkr]

Originally this issue was called "Unified player should be optional", not "Option to have separate queues". There is no need to have multiple queues for the usage scenario described in this issue. In v0.19 the background audio queue was totally unaffected by the video playback, and videos were never added to any queue when you simply watched them in NewPipe. If this behavior was available in 0.20 (as an option) instead of being completely removed, there would've been no need to come up with convoluted workarounds like the one described in #4460 (comment) (that doesn't really solve the actual problem described here).

[Flashwalker]

Originally this issue was called "Unified player should be optional", not "Option to have separate queues".

Yep, you are right

[nbmrjuhneibkr]

This issue was never about "watching them later", it's about watching them immediately, without any changes to existing background queue. Please read the "Steps to reproduce the bug" section again.
There is no need to have any media notifications for a single video that is being played in NewPipe.
All of this was already implemented and worked just fine in v0.19.

[nbmrjuhneibkr]

Why do you need to manage multiple queues at the same time?

I don't. Did you even read my comments? I don't need video to be added to any queue when I simply press the Play button and watch it. I don't need any media notifications while it's playing either.
This is how it already worked in v0.19 and earlier. Have you ever used NewPipe before v0.20?

This issue is not a feature request, because the feature already existed in NewPipe, and we know exactly how it's supposed to work.

[nbmrjuhneibkr]

I'm sorry, @opusforlife2 , but I have to change the title of this issue back to the original one. It seems like new title creates more confusion and leads to people suggesting workarounds that are unrelated to the actual issue.

[avently]

There is no need to have any media notifications for a single video that is being played in NewPipe.

It's not true.

I don't need any media notifications while it's playing either

You don't know how all the code works. It's not about what you want it's about how to make the player working. Notification is the only solution for playing something in android in a service.

This is how it already worked in v0.19 and earlier. Have you ever used NewPipe before v0.20?

It's not true too. Did you ever used NewPipe 0.19 before? When popup and background players work both notifications appear. Two notifications, not one. In case of three players there should be three notifications at a time. Did you understand or not? If not, ask your questions. Maybe by understanding the underlying changes you'll be able to find a solution for your problem

[avently]

I would say that it is possible to have separate queues but one service/notification. But someone needs to find a way to control all three queues in a comfortable way. That's hard. Let's say you're playing something in main player. Then you want to play something in background player. Main player pauses but UI is visible (play button and others, video is shown instead of thumbnail). Notification changes it's content to background queue instead of main player.

Then you choose to play something in popup. Same as with previous example. But I don't know how to access background queue. probably via additional button in mini player at the bottom. So one button in mini player switches to background queue after pressing. Popup and main player still shows a picture of the paused video and it's controls but sound plays from backgroud queue. And click on notification will guide you to background queue.

Whenever you play something within other player like popup or main, queue switches to it as well as notification.

For this to work you need to have two cached player's UI for popup and main so they can coexist.
And you need additional button in mini player when background queue is exist.
And you need to have three queue available at a time. The switching between them should be an easy thing to do.
And you have to return back buttons like "Play in popup", "play in background".

Actually all this idea is not hard to implement. Of course this behavior should be optional.

[nbmrjuhneibkr]

@avently

You don't know how all the code works.
Notification is the only solution for playing something
When popup and background players work both notifications appear.

Yes, I don't know how the code works, but I do know how NewPipe behaves now and how it differs from pre-v0.20 behavior. My reference is this - https://github.com/XiangRongLin/NewPipe-preuinified , since it's still maintained and works properly on my device. This version does not display any notifications when a single video is being played in foreground, and, more importantly, this does not affect the background player queue/notification in any way. Also, I never said anything about the popup player, since I have no experience using it.

I would say that it is possible to have separate queues

As I already said, at its core this issue was never about having control over multiple queues, since they are not needed for the usage scenario described in this issue.
The goal should be pretty simple: play individual video without ever adding it to any queue, thus leaving the background queue unaffected by video playback. This is how NewPipe v0.19 worked, and it's one of the main reasons why #4918 is pinned.

[goyalyashpal]

thanks @nbmrjuhneibkr for sharing Newpipe-preunified's repo. Is that repo updated to contain the latest fixes for playing youtube i.e. does youtube videos play in your device on that app??

[nbmrjuhneibkr]

@yashpalgoyal1304 It's NewPipe 0.19.8 + NewPipeExtractor 0.20.11 (and maybe some additional fixes). It is fully functional (at least for now).

[MapleWheels]

@avently

You don't know how all the code works.
Notification is the only solution for playing something
When popup and background players work both notifications appear.

Yes, I don't know how the code works, but I do know how NewPipe behaves now and how it differs from pre-v0.20 behavior. My reference is this - https://github.com/XiangRongLin/NewPipe-preuinified , since it's still maintained and works properly on my device. This version does not display any notifications when a single video is being played in foreground, and, more importantly, this does not affect the background player queue/notification in any way. Also, I never said anything about the popup player, since I have no experience using it.

I would say that it is possible to have separate queues

As I already said, at its core this issue was never about having control over multiple queues, since they are not needed for the usage scenario described in this issue.
The goal should be pretty simple: play individual video without ever adding it to any queue, thus leaving the background queue unaffected by video playback. This is how NewPipe v0.19 worked, and it's one of the main reasons why #4918 is pinned.

What do you guys think about this solution? #5864 (comment)

[Flashwalker]

... My reference is this - https://github.com/XiangRongLin/NewPipe-preuinified , since it's still maintained and works properly on my device...

Oh, hallelujah! At last someone made that fork!

[goyalyashpal]

this is also the side-effect of unified player rework, right?: #5304

[AbakumovAlexandr]

So, where is a resolution for this issue now at (2 years later)?

I've read multiple related issues and still have no idea why the separate queues for foreground\background players had to be broken unconditionally. This really limited valid use cases of the app a lot.

[cyber199]

_{Mod note: don't quote unnecessarily.}

I did not know this fork was a thing. I have been using the old NewPipe Legacy app alongside standard NewPipe just to avoid the very problem of not interrupting my existing queue when someone sends me a video.