Change timestamp behavior

[snappyapple632]

Describe the feature you want

Timestamps should seek in the Unified Player instead of starting a pop-out player.

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

N/A

Additional context

N/A

How will you/everyone benefit from this feature?

Timestamp-based pop-out players are the inferior solution compared to instantly seeking in the unified player.

[B0pol]

why bug @opusforlife2 @TobiGr?

[opusforlife2]

Unexpected behaviour compared to Youtube and Invidious?

[opusforlife2]

That's how I differentiate between the two, anyway.

Bug: did something and got an unexpected result.
Feature request: wanted to do something and was unable to do so.

[B0pol]

It is expected here. We did not change code about this therefore we do not expect the behavior to change.

[opusforlife2]

You're speaking from the perspective of a developer here. There is probably no bug in the code, sure. But from a user's perspective, there is a bug in the behaviour. No user would tap on a timestamp and expect to see a popup of the same video. And it's not documented anywhere in the app that that's something that will happen. Any user who's used this functionality in Youtube or Invidious will expect to jump to that timestamp in the same video, though.

[B0pol]

But then by definition it's a request, feature request

And even as a user. I don't see the difference before and after unified player as you still can't view comments without popup player.

I don't want to scroll up to see the video after clicking on a timestamp, scroll down again for comments, scroll up for another timestamp…

YouTube is completely different because the video continues to play while viewing comments, that's basically our popup mode.

Compare YouTube:

And NewPipe:

The only way to reproduce youtube behavior is popup player

That's why we are launching popup player on timestamp and that's also why it shouldn't change

And please don't mention YouTube's desktop behavior, desktop ≠ mobile

[opusforlife2]

It's definitely not a bug with the unified player, but existing behaviour from the past, so that should be removed from the title, I agree.

[opusforlife2]

YouTube is completely different because the video continues to play while viewing comments, that's basically our popup mode.

Ah yes. I think avently was testing this out at some point, but it wasn't implemented. I forgot why.

I don't want to scroll up to see the video after clicking on a timestamp, scroll down again for comments, scroll up for another timestamp…
YouTube is completely different because the video continues to play while viewing comments, that's basically our popup mode.

Would it not be possible to have the app 'jump' to the top upon tapping a timestamp?

I don't see why someone would tap several timestamps in a row, anyway. That seems like a corner case.

[opusforlife2]

Also, how does this possibility sound? : If the video is paused, then it should scroll up just like it currently does, letting comments or suggested videos fill up the screen. But if the video is playing, then comments and videos should scroll under it.

[snappyapple632]

I didn't see this as unintended behavior, that's why I posted this as a feature request. I felt this suggestion was more relevant and doable now that the player is going to work more like YouTube's. I honestly don't see the reason why timestamps have to make additional instances of the player if we already have a system that works in-line with the user interface.

My suggestion for the comments issue would be to compress the player about half it's height to the upper edge to make more room for the comments.

[avently]

@opusforlife2 let's see from a developer perspective.
When you see that something you make has a label "bug" you think that you made something wrong and it's not make you happy. When you see a "feature request" it means that something new could be added and it's flne.

For you it may may sounds the same but because you don't write a code. It's like saying "a bug" when I disagree with your point in a comment:)

[opusforlife2]

Fair enough.

[Stypox]

#2851

[triallax]

@Stypox why did you close this instead of #2851? This issue has much more discussion surrounding it.

[lomanq]

Hi, i think that you can create an option in settings where the user can choose two differents method:

• First option, when the user click on a timestamp in description o comments, the app starting a pop-out player

• Second option, when the user click on a timestamp in description o comments, the app resume the video in the Unified Player instead of starting a pop-out player.

In this way the user can choose the best option for him.

What do you think about that?

[sryze]

How about this:

1. Short tap on timestamp - fast forward to it in the existing player
2. Long tap - do it in a popup player (current behavior)

?

[yephny]

That makes a lot of sense, sryze. Seems to offer the best of both worlds.

[SameenAhnaf]

1. Short tap on timestamp - fast forward to it in the existing player

Keeping the video static while scrolling comments is a major feature and it'll be added anyway. #4484 should be considered in this regard to make the feature useful on main player.

2. Long tap - do it in a popup player (current behavior)

Long tap gesture should be preserved for copying links in comments and description as suggested in #7097 and #7378. Popup player will be required no more if my first suggestion is implemented, I think.

[goyalyashpal]

Popup player will be required no more if my first suggestion is implemented, I think.

link?

[SameenAhnaf]

@yashpalgoyal1304 #4484

[goyalyashpal]

Would it not be possible to have the app 'jump' to the top upon tapping a timestamp?
- #4241 (comment)

i dont think that that'd be a good idea

• honestly, this was bothering me too.
• but now after reading this explanation by bopol, the current popping up behaviour makes sense.
• my vote will be for this suggestion of adjustable behaviour: popup - vs - just resume in settings by lomanq
• this suggestion of scrolling under vs scrolling over by opusforlife2 is also good food for thought and can be further refined. also yeah, as B0pol said, this can be considered same as popup player.

[goyalyashpal]

... cntd.

• .... as someone simulated it aptly as well : follow the trail at Scroll comments/related streams under video #4484 (comment) to see the video of it
• That popup can be made to feel just like youtube , if it is it automatically scaled and positioned as same as the newpipe video viewerport
• this combined with "seemless switching between modes" will rock (:
  (cant find that issue which mentioned this seemless thingy)

[SomeoneIsWorking]

This behavior got super weird lately. When you tap on a timespan it opens a popup player not from the timestamp but from the position you were watching. Then you can tap the timestamp again to make the popup player jump to that position. Then you can close the popup player and main player resumes from where popup player left. Doesn't resemble an intended behavior.

[SameenAhnaf]

@SomeoneIsWorking This issue is expected to continue playing timestamp on current player. Please have a look at #7427 instead.

[ghost]

This behavior got super weird lately. When you tap on a timespan it opens a popup player not from the timestamp but from the position you were watching. Then you can tap the timestamp again to make the popup player jump to that position. Then you can close the popup player and main player resumes from where popup player left. Doesn't resemble an intended behavior.

same thing happens to me as well, except it takes around 8 seconds for the video to continue playing in popup mode and another 8 to go back to its original place

I think the video should jump to the intended timestamp when you press it, same way how it works across all other apps and frontends

[goyalyashpal]

So, one way - building on the one

• but now after reading this explanation by bopol, the current popping up behaviour makes sense.
  at comment

one way to further improve further improve the experience using popup mode itself:

ONCLICK_TIMESTAMP( TIME )

1. IF current mode is not popup
2. THEN 
    + launch popup player with seek position at TIME with predefined:
    + ... size: best fit (i.e. for portrait: max width), 
    + ... and position: top most
    + ... in such a way that these predefined values doesn't override the 
      already saved user-adjusted popup player parameters
3. ELSE
   change the seek position in popup player to TIME
   END-IF
4. End

[JakubFojtik]

How about just letting users globally configure the player to be used for timestamp clicks? Would at least be useful for audio-only whole-album videos where timestamps seek to different songs. In this case users don't care about the video.

I tried changing InternalUrlsHandler.playOnPopup()`s playOnPopupPlayer to playOnMainPlayer, but that only resets the main player, so there must be some trick to it. playOnBackgroundPlayer works from the second time a timestamp is clicked, just like the popup player does: #4241 (comment).

The best solution seems to be figuring out the sticky video at the top if user wants it. Unlike the popup it would not obstruct content at the top of the page.

[SameenAhnaf]

The best solution seems to be figuring out the sticky video at the top if user wants it

You are right. #4484 should be implemented before this issue. There's no need to make timestamp behavior customizable. Rather, continuous playback on current player is fine.

[yephny]

@adamency In both issues, a toggle would be the ultimate solution as you said. Unfortunately, I doubt the reason we're not getting these features is that the developers are undecided. It's just that they're trying to keep up with the changes made to Youtube on the regular + fixing up bugs + rewriting the entire codebase. I'm not sure if they're going to make any improvements to the current app considering the last point.

[KaKi87]

Maybe there should be two teams : one focused on scraping, the other focused on the rest.

[foxjaw]

@SameenAhnaf I don't see #4484. I think the user was bann3d or shadow3d. What was that issue ?

[SameenAhnaf]

@foxjaw You may keep an eye on #5450 instead to track the same request. Thanks for letting us know about the problem.