Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Seeking backwards while using nativeControlsForTouch breaks playback #6444

Closed
third774 opened this issue Feb 12, 2020 · 11 comments
Closed

Seeking backwards while using nativeControlsForTouch breaks playback #6444

third774 opened this issue Feb 12, 2020 · 11 comments
Labels
outdated Things closed automatically by stalebot

Comments

@third774
Copy link
Contributor

Description

When using the nativeControlsForTouch for option with a DASH manifest, seeking backwards breaks playback.

Steps to reproduce

  1. Open https://codepen.io/third774/pen/xxboOvr
  2. Open Chrome dev tools and turn on device toolbar (for touch controls)
  3. Reload the page (re-initializes player to use native touch controls)
  4. Seek at least 3/4 into the video.
  5. Seek back toward the start of the video (playback will break and not resume here)

Results

Expected

The player should seek backwards and load the appropriate segments to resume playback at the seeked time

Actual

Loading of segments for newly seeked time never happens, and as a result playback never resumes.

Additional Information

Please include any additional information necessary here. Including the following:

versions

videojs

Latest (7.6.6)

browsers

Chrome (at least)

OSes

MacOS, Android

plugins

None
@welcome
Copy link

welcome bot commented Feb 12, 2020

👋 Thanks for opening your first issue here! 👋

If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.
To help make it easier for us to investigate your issue, please follow the contributing guidelines.

@gkatsev
Copy link
Member

gkatsev commented Mar 17, 2020

So, I think this may be due to us switching to middleware in VHS: videojs/http-streaming#161.
That PR seems to cause some issue in VHS 1.x (videojs/http-streaming#378), and we may be reverting it there, though, we don't currently have a plan to revert that PR in master as that issue isn't present in master.

@third774
Copy link
Contributor Author

third774 commented Mar 18, 2020 •
edited
Loading

Cool — thanks for the update! I'll see if building with @videojs/http-streaming's master branch makes this problem go away and report back.

@third774
Copy link
Contributor Author

Hrm — so, I built video.js from source at the tip of master after building @videojs/http-streaming from source and linking it in video.js, the problem still seems to exist.

Did I understand correctly that the problem should not exist in master if switching to middleware in VHS is the root cause?

@gkatsev gkatsev mentioned this issue Mar 18, 2020
Merged
@gkatsev
Copy link
Member

gkatsev commented Mar 18, 2020

Master still uses middleware, so, it won't be fixed. You can try the PR videojs/http-streaming#777 and see if that works.
For master, we may look into doing a hybrid approach or maybe just see if native controls are being used and then not rely on the middleware, still thinking things through.

@third774
Copy link
Contributor Author

Awesome! That PR does indeed fix it. Thanks for everything you do! 🎉

@gkatsev
Copy link
Member

gkatsev commented Mar 19, 2020

You're welcome, then, yes, indeed, the issue is that. We'll have to come up with a solution in master. We're likely going to merge and release that PR in the 1.x release line soon.

gkatsev added a commit to videojs/http-streaming that referenced this issue Mar 26, 2020
@gkatsev
revert: "fix: Use middleware and a wrapped function for seeking inste…
1a4fc1e 
…ad of relying on unreliable 'seeking' events (#161)" (#777)

This reverts commit 6c68761.

This helps address #378 and videojs/video.js#6444.

We still need seekTo for seekToProgramTime.
@stale
Copy link

stale bot commented May 18, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the outdated Things closed automatically by stalebot label May 18, 2020
@third774
Copy link
Contributor Author

✨

@stale stale bot removed the outdated Things closed automatically by stalebot label May 18, 2020
@gkatsev gkatsev mentioned this issue Jun 10, 2020
Merged
@stale
Copy link

stale bot commented Jul 18, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the outdated Things closed automatically by stalebot label Jul 18, 2020
@stale stale bot closed this as completed Jul 25, 2020
@gkatsev
Copy link
Member

gkatsev commented Aug 6, 2020

Also, we reverted the middleware change in the main branch, so, this should be fine with VHS 2.x as well.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
outdated Things closed automatically by stalebot
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gkatsev @third774