Enqueuing/playing a video from history should not queue the whole playlist

[GeluOltean]

Checklist

• I checked, but didn't find any duplicates (open OR closed) 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 feature request. I will open one issue for every feature I want to request.

Describe the feature you want

Hi everyone. This might be a pet peeve of mine, but I think that when enqueuing a particular video from the history, having the whole history playlist queued is a bit strange; I think it would be quite helpful to either treat the history playlist as "special" in this regard, or have the option of toggling this on or off (perhaps not just for the history playlist?).

Is your feature request related to a problem? Please describe it

Additional context

How will you/everyone benefit from this feature?

The reason I ask for this is that I often "compose" playlists with different videos, but if I do it starting from the history playlist and I'm not paying enough attention, the whole of my history gets queued and any videos I add will be shot down all the way to the end, which is a bit unexpected.

[MD77MD]

yeah, this is really Annoying !

btw, this is only happening with pop-up and background playback. regular video playback is fine.

[Wessl]

Is anyone working on this? The way I personally use newpipe is to have on big playlist of all my music on youtube that I then queue songs from, which has been impossible for a while now. Surely this has to be one of the most important bugs in the app at this point? I have no idea what language newpipe is even written in but at this point I'm going to start to try and fix this myself.

[Krysaczek]

Reproduction steps:

• start NewPipe (no video is playing or is enqued), go to history
• press and hold on any video (preferably near the top)
• choose "Start playing in the background"
• [whole history is enqued going from top to bottom]
• press and hold on any of the other videos in history
• choose "Enqueue"
• [said video gets put at the end of a queue and will be played after all of the other history videos]

Workaround I do is to start playing whatever video in background, pause and then enqueue several videos from history or even from search that I want to listen to. Then I go to the near end of the queue and pick the first one I enqueued. This way I circumvent whole enqued history and listen only to the newly added.

Solution could be:

• not enqueueing all of the history (obviously, but queue itself would be temporary/without history)
• enqueueing all of the history (as it is done now) but actually moving the first "Start playing in the background" video at the end of the queue, so it's either last one played and any other enqueued videos do actually start playing right after it (we keep queue history, that's a plus)
• queue with its own history could exist (this is how it worked before), "Start playing in the background" would put the video at the end of the queue history and any other "Enqueue" videos would be put right after

[codyit]

Was going to submit an new issue and I found this.
@SameenAhnaf Should it be flagged as a bug instead of feature request?

1. When I hold press a video and choose "Start playing in the background" my expectation is to action upon that particular video instead of the whole list. I'd think it's a common expectation.
2. Personally I would never enqueue my whole watch history in the background. Similarly I'd expect no one does it.

I'll try to see if I have bandwidth to help fix it.

[SameenAhnaf]

@codyit An issue is marked as bug if the existing code doesn't work as expected. A feature request is for adding completely new code. So, feature requests and bugs are separated by intended behavior of code, NOT the usual behavior

[codyit]

@codyit An issue is marked as bug if the existing code doesn't work as expected. A feature request is for adding completely new code. So, feature requests and bugs are separated by intended behavior of code, NOT the usual behavior

I'm indeed making a case that this was not the intended behavior. If we substitute this to a shopping cart and the action is removal that would be more obvious, i.e. clicking remove on a single item clears your shopping cart.

Without looking at the code my guess is that instead of working on individual object the code is pulling the parent collection of history instead. Even if there were extensive test cases for this I would suspect it was misinterpretation during implementation.

Those are just semantics.. anyway, the only relevant bit for me is whether a PR for this would be accepted? Since according to your dev.md it wont unless it's categorized as a bug.