0.19 => 0.20+ regressions

[nbmrjuhneibkr]

It has been almost 6 months since the controversial release of NewPipe 0.20, and very little has been done since then to bring back feature parity with NewPipe v0.19.
This is why I wanted to create a new meta-issue with all regressions that have not been properly addressed yet. I know that this does not align with contribution guidelines, but I don't see a better way to increase chances of this ever being resolved.

These are the ones that I remember, but maybe I missed something. Feel free to add more (0.20+ regressions only, not general requests/bugs). Links only - actual issues still need to be submitted separately.

1. Make "unified player" optional, allow video playback without interrupting background queue: Unified player should be optional, makes the app useless in certain scenarios #4460
   The largest change and the largest issue in 0.20. One of the main reasons why Limited time support for v0.19.8 #4918 exists.

2. New behavior of the system "back" button, which is extremely counter-intuitive: An option to disable the video history/queue control with the "back" button #4479 When using back button it goes to the previously watched video, not the channel #5724
   Related: Back button behaviour with no backstack #4569

3. Manual rotation control for full-screen mode (one of the features that used to make NewPipe more flexible than the official YT app): [Feature request] Lock screen rotation status #2925 Add back orientation switch button in full screen #4500

4. Manual full-screen mode control instead of a "smart" button that disappears when system-wide auto-rotation is enabled: Always show the full screen button #4478

5. Auto-fullscreen: Can't go directly to fullscreen when tapping thumbnail #4152 (also related to rotation control), [androidtv] Enable option to play automaticly in fullscreen #4387

6. Share/select video quality without playing the video (when autoplay is disabled): Regression - Share and other buttons in video details #4039 With Autoplay disabled, I cannot select the video quality or interact with other controls before/without playing it #4458 Share video URL without playing the video #5484
   Fixed only partially: video quality still can't be selected without playing the video, share button is now hidden in a drop-down menu, which makes it more difficult to access.

Related (rotation/fullscreen/etc.): #4414

[TBN-MapleWheels]

Just wanted to say that I concur. Issue #4460 is the primary regression. It was apparently supposed to be fixed in version 0.20.3 according to the tracker but it was not completed for whatever reason and was just silently dropped.

[MapleWheels]

Yes, this is a double post, just because GitHub is being silly with multi-profile and not letting me edit the above comment anymore for whatever reason.

The legacy version of 0.19.8 + newest extractor is starting to have more and more issues with parsing/playing videos or audio, I suspect due to no changes being performed in regards to non-extractor changes needed for YT. My fear is v0.19.8 becomes unable to play enough videos to the point where it can't be realistically used, so I feel like we're running out of time.

[TacoTheDank]

Even though I'm not bothered by any of these, I support the notion for these issues to be addressed 👍

[nikhilCad]

Number 5 is the one that bothers me the most.

[nbmrjuhneibkr]

@SameenAhnaf
avently is the developer who is responsible for most of these changes in v0.20. He always acts extremely defensive about anything that he implements.

[MapleWheels]

@nbmrjuhneibkr What should we do then? We need to take steps ASAP. Maybe, force him to make a fork? Sorry, I am getting aggressive. But all users should never suffer for a single person's mistakes. This app is not his personal property.

Agreed. I understand that a lot of work goes into this app but, even if we are just users, this project was intended for mass consumption, so changing a multi-developer consumer product based on personal preference is extremely irresponsible.

Sadly I'm a C# oriented dev (full stack ASP.NET, TypeScript + Angular and Unity) so I can't help with maintaining or developing a fork.

EDIT: I just noticed this. How the hell was a new developer allowed to come in and completely reshape the project without any oversight or feed back????? Look at Avently's contribution activity timeline.

Their contributions started with these massive changes with no feedback or effective oversight. Guys, there's a process for these things for a reason. I understand that this is not a company but there's a reason that we enploy these development processes and procedures.

I might actually use this project as a study case to present to management since they were trying to do something similar recently (sales and marketing team's ideas).

[atmosfar]

Please stop mass tagging people into new issues.

[MapleWheels]

Yes, please. This is not good behaviour and looks poorly.

I would like to ping 1-2 developers (TobiGr or Opus, Avently) for their responses/feedback to the criticisms levied here if that's okay.

Or is there someone else in charge of PRs/Quality Control?

[Stypox]

@nbmrjuhneibkr thank you for creating this list! Everything looks already clearer. I think we should now take one issue at a time, collect possible solutions, delve deeply into the implementation, reach an agreement and implement it. I created a column in the 0.21.x project.

By the way, yes, we shouldn't have merged unified-ui without first checking every possible outcome of it, and that's our fault, but at the same it was discussed, discussed, and discussed again, reviewed multiple times, checked and rechecked. And it was already avently's second attempt at implementing unified UI. And # 2907 stayed open for many months, so many users were pressing to merge it. For me personally none of these issues are a problem, so I didn't notice them (obviously my fault, I should have examined more usecases). What I mean is that we didn't merge it without care, but I agree that we failed to check everything that needed checking and we could have handled it way better. I hope you understand :-)

[nbmrjuhneibkr]

@Stypox Looks like that link is 404.

Edit: it works now.

[Stypox]

@nbmrjuhneibkr oh, I can see it just fine, maybe access is restricted to members?

[avently]

Ok, many opinions, it's another one.

1. Disagree
2. Agree to have the idea optional. Just because it can be changed with one line of code + lines for an option in the settings. I talked about that many months ago but you and anyone else didn't even tried to listen. I could even tell what text and where should be written but it looks like you want to talk instead of to receive a solution.
3. Disagree
4. Disagree
5. Agree. This is what actually useful for some situations and I didn't notice it before I listened opinions of other people. There is a PR exists already which should address this issue. Didn't tested it but it should be fine. Again, you know that there is a work happens around this issue but you still forces the talk about it. That's strange.
6. Absolutelly agree. The problem happens when video can't be parsed and a user needs to have an access to open in browser button but he can't do it in this case. Share button and Kodi is needed too for someone. However quality selector can be located as it is since per-video qiality is not often used and it's convinient to change the quality after you started to see a video itself.

For every "disagree" you can find my post with explanation of my opinion in the linked issues.

This is why I wanted to create a new meta-issue with all regressions that have not been properly addressed yet.

Then will we see meta issue of meta issues?

He always acts extremely defensive about anything that he implements

I often acts defensive for the things I like even if I didn't make them. But it only happens when there is not alternative vision that I think is righter than mine in the situation. 5 and 6 are examples when I saw that people's opinion can be right too and in some cases it can be useful. And also note that when I do code I think of it many times before start of coding. Because I try to do the best possible and universal solution and I know what and why the idea is soo great and what arguments I have in order to defend my opinion.

@TacoTheDank

Even though I'm not bothered by any of these, I support the notion for these issues to be addressed

So you like how things are working but ok to change the behavior to the one you don't like? Or you want to have the new behavior optional?

@SameenAhnaf

Extremely sorry but I can see "avently" arguing in almost every issue. As a typical user, I don't know what to say

Maybe because I have arguments but you don't? No, I'm seriously. When I think something is important I can say why and I have the arguments.

Maybe, force him to make a fork?

You probably have even no idea what you're talking about. How you would force me?

But avently never gets my point

I will get your point when this will be a point not just "+1"

Sorry, I am getting aggressive

It's fine, most of the people who don't like the new changes are quite aggressive. I don't know why it happens. Maybe because they think that their opinion is not matters but it's not true. I feel good about critique of me or my work. I would pass a stress test but the agression you and others have is counter-productive and gives only negative impact on your ideas. Other devs see that at some point in the future you can just kick them from the good feeling because they didn't implemented a thing you wanted. They work years here for free but people like you have no respect. I spend more than a year to create the unified player. And what did I receive? You know. But I don't care because I do it because it is a right thing and this is how the app should work.

@MapleWheels

I just noticed this. How the hell was a new developer allowed to come in and completely reshape the project without any oversight or feed back????? Their contributions started with these massive changes with no feedback or effective oversight

One of the things I don't like is a lie. Did you even look at the #2907 ? I don't think so. By looking at it you would noticed that the PR was 7 months old when it got merged. This is the most commented thread in NewPipe repo. And it has tons of opinions from many people. Most of issues we discussed were fixed in that PR and my following PRs right after it. It went through multiple reviews by multiple people. So if you have a choice to say incorrect information and to check it first then check it first and tell us correct information.

I would like to ping 1-2 developers (TobiGr or Opus, Avently) for their responses/feedback to the criticisms levied here if that's okay

Yeah, that's ok for me.

@Stypox

For me personally none of these issues are a problem, so I didn't notice them (obviously my fault, I should have examined more usecases)

I don't think it's your fault. No one can expect that kind of "feedback" after 7 month of day-to-day discussion.

So to summarize. If someone thinks that he find a better way of doing something be carefull with your words. If you examine all feedback we (probably mostly me) got you could notice that there wasn't discussion, that was like "return old version back, *****". It's non-productive language. It's a cheet-code for you: be kinder and people will love to listen your ideas with arguments and solutions for both sides of discussion.

[nbmrjuhneibkr]

1 Disagree
3 Disagree
4 Disagree
For every "disagree" you can find my post

Very constructive, thanks. How about finding your comments and linking them here yourself? Surely, this wouldn't be any more difficult than it was for me to find the issues and link them here.

This is the most commented thread in NewPipe repo. And it has tons of opinions from many people. Most of issues we discussed were fixed in that PR and my following PRs right after it.

Here's the problem: most users don't follow the development, they just use the app. So when developers (or one developer, in this case) come up with huge changes, it's important to roll them out gradually and actively seek out user feedback. No matter how perfect everything may seem during development, it may still turn out to be a disaster once it rolls out to actual users with their various real-world usage scenarios. And then they will start complaining. When they see that a lot of their complaints are ignored, they will complain more, making the situation even more unpleasant. That's how it works.

when there is not alternative vision that I think is righter than mine
and I know what and why the idea is soo great and what arguments I have
Maybe because I have arguments but you don't?
You probably have even no idea what you're talking about.
I will get your point when this will be a point
people who don't like the new changes are quite aggressive. I don't know why it happens.
but the agressive you and others have is counter-productive and gives only negative impact
but people like you have no respect
But I don't care because I do it because it is a right thing and this is how the app should work.
be carefull with your words

Oh... I don't think that there's even a reason for me to comment on any of this. It kind of speaks for itself.

[avently]

Classic. So you just copied something without a context and think you are right. Ok. This is what I was talking about. Useless discussion with you. I'll skip your opinion next time if it will be provocating as this one.

[nbmrjuhneibkr]

The context is right above my post, not hard to find. This is just a highlight reel.

On a more constructive note, I'd like to point out that the 1st issue is first for a reason: it's the 1st most liked (followed by this meta-issue) and the 3rd most commented open issue submitted in the last 12 months. It's also directly related to one of the 3 currently pinned issues.

[iamthesenate1]

In my opinion 4 is very important for older devices (see my comment from #4478)

[MapleWheels]

One of the things I don't like is a lie. Did you even look at the #2907 ? I don't think so. By looking at it you would noticed that the PR was 7 months old when it got merged. This is the most commented thread in NewPipe repo. And it has tons of opinions from many people. Most of issues we discussed were fixed in that PR and my following PRs right after it. It went through multiple reviews by multiple people. So if you have a choice to say incorrect information and to check it first then check it first and tell us correct information.

I completely missed this is so I apologize. However, I would still like to note that regardless of the process, this issue has still occurred post-launch and has not been addressed for multiple months.

Ok, many opinions, it's another one.

1. Disagree
2. Agree to have the idea optional. Just because it can be changed with one line of code + lines for an option in the settings. I talked about that many months ago but you and anyone else didn't even tried to listen. I could even tell what text and where should be written but it looks like you want to talk instead of to receive a solution.
3. Disagree
4. Disagree
5. Agree. This is what actually useful for some situations and I didn't notice it before I listened opinions of other people. There is a PR exists already which should address this issue. Didn't tested it but it should be fine. Again, you know that there is a work happens around this issue but you still forces the talk about it. That's strange.
6. Absolutelly agree. The problem happens when video can't be parsed and a user needs to have an access to open in browser button but he can't do it in this case. Share button and Kodi is needed too for someone. However quality selector can be located as it is since per-video qiality is not often used and it's convinient to change the quality after you started to see a video itself.

Okay, so here is why 01 is such an issue. Between 0.19 and 0.20, there was a large change in the user workflow for the app in regards to background queues as follows;

Use Case 1: Watch a video by directly selecting it in NewPipe.

Given:

• Let us say that the background queue already exists.
• Let us say that the background queue contains a unique combination and/or customized ordering of its songs when compared to all other playlists.
• Let us say a playlist named "Quick Save" exists.

Relevant Behaviors:

• NewPipe's current "Save to Playlist" function when used for a queue will append the queue to the end of the playlist, not overwrite it.

Steps to watch a video:
Under 0.19:

• Navigate to the video and play it.
• Resume the background queue at the song you were at when done.

Under 0.20:

• Navigate away from the desired video to the "Playlists" tab/view.
• Delete the existing "Quick Save" playlist.
• Navigate to the currently active queue.
• Select "Save to Playlist".
• Select "New Playlist".
• Type in the name for the new playlist as "Quick Save" and save it.
• Navigate back to the originally desired video.
• Play the video.
• When done, navigate back to the "Playlists" tab/view.
• Select "Quick Save".
• Select "Enqueue in Background".
• Navigate to the new active queue.
• Select the song you were originally playing.
• If necessary, seek the track back to its previous position based on user memory.
• Done.

---

Use Case 2: Watch a video by selecting "Open with NewPipe" on a link from the Android popup modal from another app. In this example: browsing the web with music playing.

Given:

• Let us say that the background queue already exists.
• Let us say that the background queue contains a unique combination and/or customized ordering of its songs when compared to all other playlists.
• Let us say a playlist named "Quick Save" exists.

Relevant Behaviors:

• NewPipe's current "Save to Playlist" function when used for a queue will append the queue to the end of the playlist, not overwrite it.

Steps to watch a video:
Under 0.19:

• Select the relevant link to the video.
• Select "NewPipe" in the popup modal for application selection in Android.
• Watch the video in NewPipe.
• Resume the background queue at the song you were at when done.
• Continue browsing (or other previous action).

Under 0.20:

• The user must remember to do this every time, anytime the user fails to do so results in the background queue being entirely overwritten/wiped!
• In Android: Navigate away from the current app and open NewPipe.
• Navigate to the "Playlists" tab/view.
• Delete the existing "Quick Save" playlist.
• Navigate to the currently active queue.
• Select "Save to Playlist".
• Select "New Playlist".
• Type in the name for the new playlist as "Quick Save" and save it.
• Exit the NewPipe app interface.
• In Android: Navigate/Switch back to the original app you were using.
• Select the relevant link to the video.
• Select "NewPipe" in the popup modal for application selection in Android.
• Watch the video in NewPipe.
• When done; Navigate back to the "Playlists" tab/view.
• Select "Quick Save".
• Select "Enqueue in Background".
• Navigate to the new active queue.
• Select the song you were originally playing.
• If necessary, seek the track back to its previous position based on user memory.
• In Android: Navigate/Switch back to the original app you were using.
• Done.

Some questions/notes:
Q: "Why do you have a unique queue arrangement not saved to a playlist?"
A: Because most of the time, I build a custom queue starting from a playlist and then adding/removing songs based on my usage scenario and mood. I do this extremely often, especially when playing music with other people/on speakers where the queue has been customized for this.

Major Note: If the user's current song/track was a music/song mix/compilation when using the current option for 0.20, the playback position will be wiped and the user must attempt to remember and manually seek to that position in the track.

This is clearly and unarguably a major regression in usability. If I vehemently argued against something like this at my job, I'd lose a lot of weight with management in regards to my input and opinion. Even if my use cases did not encompass the above, it's clearly something that needs to be considered for other users of the product.

[avently]

@MapleWheels this was constructive, thanks. What's your proposal? You see a problem, but what's the solution? How should UI be look like, notifications, switching between players, adding suggested video to playing queue, managing multiple sources (background, popup, main players) in mini player?

[MapleWheels]

@MapleWheels this was constructive, thanks. What's your proposal? You see a problem, but what's the solution? How should UI be look like, notifications, switching between players, adding suggested video to playing queue, managing multiple sources (background, popup, main players) in mini player?

So, in my opinion, the issue stems from being able to resume the queue as it was before viewing the video. What I was describing with the "Quick Save" was essentially a caching function. There are a couple of ways that I can see handling this; A. a phantom queue, B. Queue state caching. Either of which, could be configured via options. I think option B might be easier and more transparent.

With a phantom queue, directly playing a video or source in focus would create a hidden secondary queue. This would take focus and exist for the duration of the video or otherwise and would be removed at the end of the video, being replaced by the original queue state.

Option B, "Queue Caching" would be a prompt presented to the user; if an active queue exists in background mode with more than one item in it, playing a new video would prompt the user to either delete/overwrite the queue or "cache it". Caching will save the current queue state, including the last played song and playback position. Activating this behaviour will expose an option "Resume Background Queue"/"Resume Previous Queue" (or otherwise aptly named). Selecting this at any point will overwrite the current queue with the old one. If the user completes a video, there should be a popup modal prompting if the user would like to resume the previous queue at that time, if not, the option would still exist until they either enqueue another playlist or multiple background videos.

Example:

Scenario: Implementation of "Queue Caching".

Use Case 1: The user plays a video in full focus with a background queue already active.

Given:

• Let us say that the user already has a queue in background mode (audio only).
• The user is already in NewPipe's main view.

Steps:

• The user selects a video.
• The video page with the video not playing is loaded (with comments, suggestions, etc.).
• The user selects "Play" (selecting the video element).
• A popup modal appears "Would you like to cache the current play queue to resume after?" with "Yes" or "No".
• The user selects "Yes".
• Internally: The play queue is saved as-is (playback positions and track selection included).
• The video is played.
• When the user either exits the video (at the end or whenever they choose). They will see at the top of the NewPipe views they are in, a button that says "Resume Previous Queue" and next to it "Discard".
• User Options:
• • A1. At any time, the user selects "Resume Previous Queue".
• • A2. The current queue is discarded and overwritten by the cached queue, including playback positions and track selection.
• • A3. The track begins playing.
• • B1. At any time, the user selects "Discard".
• • B2. The cached queue is discarded.
• The cached queue option modal is removed from view.

---

Use Case 2: Watch a video by selecting "Open with NewPipe" on a link from the Android popup modal from another app. In this example: browsing the web with music playing.

Given:

• Let us say that the user already has a queue in background mode (audio only).
• The user is already in NewPipe's main view.

Steps:

• The user selects a video link in another app.
• the user selects "Open with NewPipe".
• A popup modal appears "Would you like to cache the current play queue to resume after?" with "Yes" or "No".
• The user selects "Yes".
• Internally: The play queue is saved as-is (playback positions and track selection included).
• The video is played.
• The user selects the NewPipe queue from the notifications section in android.
• In the active queue view, the user will see at the top of the NewPipe views they are in, a button that says "Resume Previous Queue" and next to it "Discard".
• User Options:
• • A1. At any time, the user selects "Resume Previous Queue".
• • A2. The current queue is discarded and overwritten by the cached queue, including playback positions and track selection.
• • A3. The track begins playing.
• • B1. At any time, the user selects "Discard".
• • B2. The cached queue is discarded and the queue remains as is.
• The cached queue option modal is removed from view.
• The user switches back to the app they were using by double-tapping the "active apps view" android navigation button (quick swap).

What this is essentially doing is streamlining the "Quick Save" playlist usage from my previous post and including desired functionalities for its use case (resume playback on the same track with the previous playback position).

I have attached a couple of quickly made mockups that hopefully show what I am picturing in the interface. Let me know what you think. I'd make more mockups for Use Case 2, as well as details for Mini Player, Popup Player, etc. but I'm pressed for time today.

Regards,

[avently]

@MapleWheels
Thanks for the time and detailed explanation!
From my point of view this behavior is really hard to understand. It's counter-intuitive and inflexible. Sorry if I chose rude words (I have a high standart for everything I do and this is what I would think if it was my idea) but the behavior is really unacceptable.

Almost everything that depends on user's choice with alerts is a bad design and should be avoided. These buttons on main fragment is not useful there too.

It's inflexible because there are multiple players and play queues. In the released version you can switch lightning fast from one player to another and go back to previous video from history. By adapting your solution I don't really know how to manage the queue, how to play another playlist and how to go back.

It's counter-intuitive because of the need the buttons in main fragment. How would someone know that these buttons actually exist? How it should work on Android TVs? There is no way to access main fragment without closing a video view on TVs.

Sidenote: it's a good sign that you started to think about solution instead of thinking what word to choose for naming a developer. This way you understand complexity of the app's architecture and how things co-exists. Any change in NewPipe can ruin someone's usecase because NewPipe has many features.

If your solution will be implemented you'll stand with me answering why you broke someone's usecase :)

I will try to read one more time later maybe my understanding of what you wrote is wrong.

[opusforlife2]

@MapleWheels I just want to applaud you for the time and dedication you put into crafting those two comments. 👏

[avently]

@MapleWheels this is part of my solution, take a look
#4460 (comment)

Some additional things came to mind like the ability to control all three queues from a list-like button in mini player: space divided by three tabs for each queue

[MapleWheels]

@MapleWheels
Thanks for the time and detailed explanation!
From my point of view this behavior is really hard to understand. It's counter-intuitive and inflexible. Sorry if I chose rude words (I have a high standart for everything I do and this is what I would think if it was my idea) but the behavior is really unacceptable.

Almost everything that depends on user's choice with alerts is a bad design and should be avoided. These buttons on main fragment is not useful there too.

It's inflexible because there are multiple players and play queues. In the released version you can switch lightning fast from one player to another and go back to previous video from history. By adapting your solution I don't really know how to manage the queue, how to play another playlist and how to go back.

It's counter-intuitive because of the need the buttons in main fragment. How would someone know that these buttons actually exist? How it should work on Android TVs? There is no way to access main fragment without closing a video view on TVs.

If your solution will be implemented you'll stand with me answering why you broke someone's usecase :)

I will try to read one more time later maybe my understanding of what you wrote is wrong.

I can see the issue with non-touch-based devices having issues with this. Okay, so my idea might not work for that use case.

@MapleWheels this is part of my solution, take a look
#4460 (comment)

Some additional things came to mind like the ability to control all three queues from a list-like button in mini player: space divided by three tabs for each queue

I think you're on the right track there but, I would say a better way to maybe implement that is a phantom queue that exists for in-focus video viewing only. The fundamental issue for 05 is wiping the background queue when playing videos in-focus/full view.

For the "Play in Popup" vs "Play in Background", if you added an "Enqueue in Background" that appended to the existing list I think it would work.

The default behaviour would have to be that playing a video directly in-focus/full view results in this phantom queue (not directly controllable) existing for the lifetime of the video being played in focus/popup/etc. "Play in background" should overwrite the existing queue and "Enqueue in background" would instead append it to the current queue.

If the default behaviour to selecting play on a video is to preserve the existing queue, it solves the issues of opening a YouTube link via another application/external link wiping the queue accidentally.

At the top of the active video play window, you could have the "headphones" icon (play in the background) prompt the user for "Enqueue" versus "Play" (overwrite). Enqueue would add this video to the queue and switch the current background track to the now enqueued video and automatically seek the track to the playback position that it was at when it was in full-screen view mode. The phantom queue would now be cleared.

Switching from background mode to full view mode for the enqueue functionality would simply be to play the current track as an in-focus video. Completing the video would not remove or do anything to the current queue, it would instead just play the next item in the queue as expected of a normal queue. This part is the same behaviour that exists now of switching between video-mode and background/audio-only mode in v0.20.

If the user manually navigated away from the current video (it stops playing) that is now part of the queue and selected another video, it would perform the same phantom queue behaviour. If the user does not, it would just begin playing all of the queued tracks in video mode. This latter part is essentially the same behaviour that exists now of switching between video-mode and background/audio-only mode in v0.20.

An important note is that the action to clear the queue must be intentional. The goal here is to just offer a way to play a selected video while preserving the existing queue as a default behaviour. If this issue is handled, then the rest is fine.

Also, I am both tired and slightly inebriated (heh) so I'm going to revisit this comment tomorrow. Please tell me anything you need clarity on so I know where I was spouting garbage XD. I will write up some user flows and use cases tomorrow for anything you'd want them for (as long as I have time).

@MapleWheels I just want to applaud you for the time and dedication you put into crafting those two comments. 👏

Thanks.

[MapleWheels]

Also, @avently Sorry for the rude behaviour before, I'm too used to work where when dealing with other departments, being nice doesn't get shit done.

[avently]

@MapleWheels #5940

[rancidfrog]

@nbmrjuhneibkr You missed an important issue.
Queue playback bugs.
With the integration of all players, unified, queues have issues.
Switching to main, for example can cause queue to clear. Sharing to Newpipe clears queue, and there is no way to enqueue currently.
This should be main concern as the whole idea of unifying players is to simplify playback, but this brought about many bugs and use-cases which have been ignored.