Autoplaying + Timestamps in URLs

QuirkyRobots commented

2021-01-14 09:31:30 +01:00

(Migrated from github.com)

Typically when you use a time bookmark, it plays the content automatically.
It would be nice if the LBRY framework also did this for a smother experience.

Example:

$(document).ready(function () {
    if(window.location.href.contains("?t=") > -1) {
       // autoplay
    }
});

Typically when you use a [time bookmark](https://odysee.com/@DollarVigilante:b/2021-The-Great-Reset,-Lockdowns,-Genocide-and-Censorship:9?t=1584), it plays the content [automatically](https://youtu.be/McInmQt3eOM?t=6). It would be nice if the LBRY framework also did this for a smother experience. Example: ```js $(document).ready(function () { if(window.location.href.contains("?t=") > -1) { // autoplay } }); ```

DispatchCommit commented

2021-01-26 03:27:17 +01:00

(Migrated from github.com)

may be resolved by: https://github.com/lbryio/lbry-desktop/pull/5372

👍 1

tzarebczan commented

2021-01-26 19:52:13 +01:00

(Migrated from github.com)

Looks like it is, let us know if you see issues @ElectronEsq ! Thanks for filing btw.

👍 1

QuirkyRobots commented

2021-01-28 01:30:09 +01:00

(Migrated from github.com)

Has it been deployed yet? It's not working for me. I've tried in 3 browsers and incognito with no cache. Tried with Odysee and LBTY TV but you still have to press the play button.

tzarebczan commented

2021-01-28 05:28:35 +01:00

(Migrated from github.com)

Are you already playing the video? I think if it's paused, it won't work. Going to reopen to make sure we take that into account and start automatically.

Test: https://lbry.tv/@jiggytom:e/test-yt-upload-1:1

Are you already playing the video? I think if it's paused, it won't work. Going to reopen to make sure we take that into account and start automatically. Test: https://lbry.tv/@jiggytom:e/test-yt-upload-1:1

QuirkyRobots commented

2021-01-28 05:51:48 +01:00

(Migrated from github.com)

Are you already playing the video? I think if it's paused, it won't work. Going to reopen to make sure we take that into account and start automatically.

Test: https://lbry.tv/@jiggytom:e/test-yt-upload-1:1

No videos autoplay with a timestamp link for me. You still have to press play.

Example:

This should auto play at 50s.
https://odysee.com/@Electron:e/bonking-parrots:c?t=50

> Are you already playing the video? I think if it's paused, it won't work. Going to reopen to make sure we take that into account and start automatically. > > Test: https://lbry.tv/@jiggytom:e/test-yt-upload-1:1 No videos autoplay with a timestamp link for me. You still have to press play. **Example**: This should auto play at 50s. [https://odysee.com/@Electron:e/bonking-parrots:c?t=50](https://odysee.com/@Electron:e/bonking-parrots:c?t=50) ![image](https://user-images.githubusercontent.com/29914179/106091496-4f56f200-6178-11eb-8fb6-973f5c618bb8.png)

kauffj commented

2021-02-22 21:23:32 +01:00

(Migrated from github.com)

Tom check if fixed, if so close, otherwise restore to groomed

tzarebczan commented

2021-03-04 18:55:33 +01:00

(Migrated from github.com)

Still doesn't auto play on https://lbry.tv/@jiggytom:e/test-yt-upload-1:1 when timestamps are clicked with latest video fixes branch

It does autoplay from the url params via page load though (but I thought this always worked)

Still doesn't auto play on https://lbry.tv/@jiggytom:e/test-yt-upload-1:1 when timestamps are clicked with latest video fixes branch It does autoplay from the url params via page load though (but I thought this always worked)

DispatchCommit commented

2021-03-04 19:14:22 +01:00

(Migrated from github.com)

I'm confused as to what "working" and "not working" are now.

As I understand the intended behavior to be:

If a URL is opened and has a timestamp in it, then set position to timestamp and (attempt) autoplay from seek position.
If a timestamp on the page is clicked then:
- If player is playing, seek to timestamp and continue playback
- If player is paused, seek to timestamp and remain paused

And this is the behavior that I see when interacting with the page currently.

(though I have identified an issue with the player now if playback has ended and the autoplay next video overlay is present then clicking on a timestamp does not properly disable the autoplay nor the autoplay overlay.

If we are going to restore this ticket to grooming, it needs to more clearly indicate the expected behavior and how the current behavior differs.

I'm confused as to what "working" and "not working" are now. As I understand the intended behavior to be: - If a URL is opened and has a timestamp in it, then set position to timestamp and (attempt) autoplay from seek position. - If a timestamp on the page is clicked then: - If player is playing, seek to timestamp and continue playback - If player is paused, seek to timestamp and remain paused And this is the behavior that I see when interacting with the page currently. ![timestamps-test](https://user-images.githubusercontent.com/45262335/110009764-4eaeff80-7cd2-11eb-98fc-1d7e05fbd8ba.gif) (though I have identified an issue with the player now if playback has ended and the autoplay next video overlay is present then clicking on a timestamp does not properly disable the autoplay nor the autoplay overlay. If we are going to restore this ticket to grooming, it needs to more clearly indicate the expected behavior and how the current behavior differs.

infinite-persistence commented

2021-03-04 22:27:02 +01:00

(Migrated from github.com)

Direct URL (https://odysee.com/@DollarVigilante:b/2021-The-Great-Reset,-Lockdowns,-Genocide-and-Censorship:9?t=1584) never worked for me, and seems like still not working (bigPlayButton still visible) whether or not I enabled Autoplay in the settings.

Still doesn't auto play on https://lbry.tv/@jiggytom:e/test-yt-upload-1:1 when timestamps are clicked with latest video fixes branch

I think this is the scenario of Autoplay=OFF in the settings, <video> not initialized yet, and then trying to click a timestamp in the Description. This is a known issue as back then I don't know how to cleanly start the video from markdownlink/view.jsx

Direct URL (https://odysee.com/@DollarVigilante:b/2021-The-Great-Reset,-Lockdowns,-Genocide-and-Censorship:9?t=1584) never worked for me, and seems like still not working (bigPlayButton still visible) whether or not I enabled Autoplay in the settings. ---- > _Still doesn't auto play on https://lbry.tv/@jiggytom:e/test-yt-upload-1:1 when timestamps are clicked with latest video fixes branch_ I think this is the scenario of `Autoplay=OFF` in the settings, `<video>` not initialized yet, and then trying to click a timestamp in the Description. This is a known issue as back then I don't know how to cleanly start the video from `markdownlink/view.jsx`

DispatchCommit commented

2021-03-04 22:42:01 +01:00

(Migrated from github.com)

Autoplay=OFF in the settings

I thought the autoplay option in settings was for turning the "next video" autoplay on or off. I realize that phrasing is not very clear so what I mean is the feature shown in this screenshot:

And not the setting that determines if videos autoplay or not. The video player should always try to autoplay the video element. The only time a video should not automatically begin playing is if the browser prevents autoplay or if the player is embedded on a page.

> `Autoplay=OFF` in the settings I thought the autoplay option in settings was for turning the "next video" autoplay on or off. I realize that phrasing is not very clear so what I mean is the feature shown in this screenshot: ![image](https://user-images.githubusercontent.com/45262335/110033698-93489400-7cee-11eb-9722-d071d21c2643.png) And *not* the setting that determines if videos autoplay or not. The video player should *always* try to autoplay the video element. The only time a video should not automatically begin playing is if the browser prevents autoplay *or* if the player is embedded on a page.

infinite-persistence commented

2021-03-04 22:45:58 +01:00

(Migrated from github.com)

The Autoplay in the settings has been controlling both the "play next" and "play directly when entering a video page", or at least that's what I've been seeing since 2020. Not sure if it's accidental or not.

But I think given that we can't add extensions or tweak the browser settings on Desktop, that behavior seem to make sense. Pretty handy to me, as sometimes I just want to read the Description and save bandwidth. But I also see your point that a video-centric site should just always autoplay on clicked

The `Autoplay` in the settings has been controlling both the "play next" and "play directly when entering a video page", or at least that's what I've been seeing since 2020. Not sure if it's accidental or not. But I think given that we can't add extensions or tweak the browser settings on Desktop, that behavior seem to make sense. Pretty handy to me, as sometimes I just want to read the Description and save bandwidth. But I also see your point that a video-centric site should just always autoplay on clicked

DispatchCommit commented

2021-03-05 05:24:44 +01:00

(Migrated from github.com)

we can't add extensions or tweak the browser settings on Desktop

Well... kind of...

So for "normal" web browsing, Autoplay is dependent on the browser allowing (unmuted) playback for a site. Now I'm going to be talking specifically about chromium, and other browsers, like brave may operate differently, set different thresholds, or not ever allow autoplaying altogether.

For Chrome, whether a site is allowed to autoplay, with sound, the browser uses a media engagement index score calculated from past visits and sessions on a site. You can actually view all the scores for sites by browsing to:
chrome://media-engagement/

That page will tell you the various scores associated with sites. For more info on this and a much clearer explanation of what's going on, read this article: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes

So we can end in situations where a browser blocks the video.js autoplay, but we still our normal video to video autoplaying feature on. I don't think it makes any sense to connect the setting to control video.js autoplaying on load and the site autoplaying adiditional videos. If these are connected, I think we should separate the two.

Auto playing a video muted, gets past some of the restrictions put in place by browsers, but leads to a poor user experience and should be avoided / removed in the future.

Now that we have that background knowledge out of the way, the fine details...

we can't add extensions or tweak the browser settings on Desktop

While I believe I understand the point you are making, and you're right, to an extent.
We do actually have some control over (some) requirements.

1 . Chrome's Pre-Seeded AutoPlay list
2. Command Line Flags

So satisfy the requirement(s) for the pre-seeded, you can review this document for a little info: https://sites.google.com/a/chromium.org/dev/audio-video/autoplay/autoplay-pre-seeding-in-chrome

Needless to say, that's not a very reliable and failsafe option. However, setting a command line flag is extremely simple, and does allow us to tweak the browser settings for electron.

In order to disable the MEI requirement for autoplay, we could simple specify this:

app.commandLine.appendSwitch('autoplay-policy', 'no-user-gesture-required');

And that would disable the autoplay gesture requirement for sound and videos that wish to autoplay on electron.

That line would just need to be added to the main electron index file, at or near line 50 as of the time of recording. Here is a permalink in case you wish to follow along yourself at home:
lbryio/lbry-desktop@eb0e0cb7cc/electron/index.js (L53)

On the web, we're at the mercy of the browser and specific implementation though, and may need to nudge the user into an interaction in order to be able to begin granting unprompted, un muted autoplays. So we just attempting to detect if play started, and show a UI element / popup button to help guide the user to player / media interaction.

Now that you understand more than you ever needed about autoplay, the question becomes is this an MEI issue, or an issue with a missing player.play() call?
I think there's a chance this issue may be caused by a low MEI for the browser/domain and no an actual issue with the software. (at least not that can be solved on the web. LBRY Desktop is allowed quite a few more freedoms. But the lesser known MEI score ends up blocking default AutoPlay for LBRY / odysee / local dev site / etc.

If the above is the cause of the problem, we'll be chasing this potentially for months / years and that could have highly subjective results. If the issue is a missing .play() call somewhere, then that's likely another issue entirely, and likely due to any potential M3U8 files that may "double load" into the video player due to having to wait for the mimetype.

Hopefully that makes some sense, It's really hard to accurately describe 2 distinct actions / features with identical names.

(I'm just trying to make sure I spend time looking into actual issues and not browser "features" and just wasting time with this MEI value being the ultimate judge)

> we can't add extensions or tweak the browser settings on Desktop Well... *kind of*... So for "normal" web browsing, Autoplay is dependent on the browser allowing (unmuted) playback for a site. Now I'm going to be talking specifically about chromium, and other browsers, like brave may operate differently, set different thresholds, or not ever allow autoplaying altogether. For Chrome, whether a site is allowed to autoplay, with sound, the browser uses a media engagement index score calculated from past visits and sessions on a site. You can actually view all the scores for sites by browsing to: `chrome://media-engagement/` That page will tell you the various scores associated with sites. For more info on this and a much clearer explanation of what's going on, read this article: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes So we can end in situations where a browser blocks the video.js autoplay, but we still our normal video to video autoplaying feature on. I don't think it makes any sense to connect the setting to control video.js autoplaying on load and the site autoplaying adiditional videos. If these *are* connected, I think we should separate the two. Auto playing a video muted, gets past some of the restrictions put in place by browsers, but leads to a poor user experience and should be avoided / removed in the future. --- #### Now that we have that background knowledge out of the way, the fine details... > we can't add extensions or tweak the browser settings on Desktop While I believe I understand the point you are making, and you're right, to an extent. We *do* actually have *some* control over (some) requirements. 1 . Chrome's Pre-Seeded AutoPlay list 2. Command Line Flags So satisfy the requirement(s) for the pre-seeded, you can review this document for a little info: https://sites.google.com/a/chromium.org/dev/audio-video/autoplay/autoplay-pre-seeding-in-chrome Needless to say, that's not a very reliable and failsafe option. However, setting a command line flag is extremely simple, and does allow us to tweak the browser settings for electron. In order to disable the MEI requirement for autoplay, we could simple specify this: ```js app.commandLine.appendSwitch('autoplay-policy', 'no-user-gesture-required'); ``` And that would disable the autoplay gesture requirement for sound and videos that wish to autoplay on electron. That line would just need to be added to the main electron index file, at or near line 50 as of the time of recording. Here is a permalink in case you wish to follow along yourself at home: https://github.com/lbryio/lbry-desktop/blob/eb0e0cb7ccabf24b4f8091db0ba8835b241bcfac/electron/index.js#L53 On the web, we're at the mercy of the browser and specific implementation though, and may need to nudge the user into an interaction in order to be able to begin granting unprompted, un muted autoplays. So we just attempting to detect if play started, and show a UI element / popup button to help guide the user to player / media interaction. Now that you understand more than you ever needed about autoplay, the question becomes is this an MEI issue, or an issue with a missing `player.play()` call? I think there's a chance this issue may be caused by a low MEI for the browser/domain and no an actual issue with the software. (at least not that can be solved on the web. LBRY Desktop is allowed quite a few more freedoms. But the lesser known MEI score ends up blocking default AutoPlay for LBRY / odysee / local dev site / etc. If the above is the cause of the problem, we'll be chasing this potentially for months / years and that could have highly subjective results. If the issue is a missing `.play()` call somewhere, then that's likely another issue entirely, and likely due to any potential M3U8 files that may "double load" into the video player due to having to wait for the mimetype. Hopefully that makes some sense, It's really hard to accurately describe 2 distinct actions / features with identical names. (I'm just trying to make sure I spend time looking into actual issues and not browser "features" and just wasting time with this MEI value being the ultimate judge)

👍 1

DispatchCommit commented

2021-03-05 09:20:49 +01:00

(Migrated from github.com)

sometimes I just want to read the Description and save bandwidth

I think it would make more sense to simply just add a second option for controlling video autoplaying when opening a page in that case. The prop already exists for it as it's needed to detect and disable autoplaying for embeds. Would just need a second checkbox to control that value separately from the "autoplay next video" option.

I also dislike that the "autoplay next video" setting is buried on a settings page that you can't easily modify while watching a video. I think that option should be available on the video page as well by the video player so it may be modified easily without navigating away

> sometimes I just want to read the Description and save bandwidth I think it would make more sense to simply just add a second option for controlling video autoplaying when opening a page in that case. The prop already exists for it as it's needed to detect and disable autoplaying for embeds. Would just need a second checkbox to control that value separately from the "autoplay next video" option. I also dislike that the "autoplay next video" setting is buried on a settings page that you can't easily modify while watching a video. I think that option should be available on the video page as well by the video player so it may be modified easily without navigating away

QuirkyRobots commented

2021-03-05 14:19:04 +01:00

(Migrated from github.com)

Autoplay should work fine. It works for logged out videos on LBRY TV for example. I suspect that it's not working for me and others in this case, because I/we have the autoplay feature turned off.

If this is the case, I guess the code will first need to make sure the "autoplay(off)" feature isn't preventing the autoplay from working on timestamped links.

Autoplay should work fine. It works for logged out videos on LBRY TV for example. I suspect that it's not working for me and others in this case, because I/we have the autoplay feature turned off. If this is the case, I guess the code will first need to make sure the "autoplay(off)" feature isn't preventing the autoplay from working on timestamped links. ![image](https://user-images.githubusercontent.com/29914179/110120488-d72fbc00-7e08-11eb-842b-97240d55f564.png)

mayeaux commented

2021-05-12 20:12:04 +02:00

(Migrated from github.com)

Tested myself and autoplay with a timestamp works fine.

tzarebczan commented

2021-05-12 20:47:40 +02:00

(Migrated from github.com)

I think the last discussion we had about this was to ensure that even if the video is paused or autoplay is disabled, that clicking the timestamp would still start the video. Forgot to mention that in this issue.

👍 1

mayeaux commented

2021-05-12 21:21:46 +02:00

(Migrated from github.com)

Okay, I can confirm that if autoplay is turned off via settings then it doesn't autoplay given a timestamp.

I also confirmed that calling player.play() from the console did autostart the video from the given timestamp point.

$(document).ready(function () {
    if(window.location.href.contains("?t=") > -1) {
       // autoplay
    }
});

This code which was posted by @ElectronEsq is a pretty quick and dirty way to autoplay in all instances.

Probably a good approach would be to hook into an event, such as canplay and then call player.play() to force autoplaying the video in all instances where a timestamp exists.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canplay_event

Not exactly sure where to drop that code yet but would be a pretty easy PR if someone knew the appropriate place to drop that code and if everyone is willing to sign off on that design.

Okay, I can confirm that if autoplay is turned off via settings then it doesn't autoplay given a timestamp. I also confirmed that calling `player.play()` from the console did autostart the video from the given timestamp point. ``` $(document).ready(function () { if(window.location.href.contains("?t=") > -1) { // autoplay } }); ``` This code which was posted by @ElectronEsq is a pretty quick and dirty way to autoplay in all instances. Probably a good approach would be to hook into an event, such as `canplay` and then call `player.play()` to force autoplaying the video in all instances where a timestamp exists. https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canplay_event Not exactly sure where to drop that code yet but would be a pretty easy PR if someone knew the appropriate place to drop that code and if everyone is willing to sign off on that design.

👍 1

QuirkyRobots commented

2021-05-13 04:18:22 +02:00

(Migrated from github.com)

This code which was posted by @ElectronEsq is a pretty quick and dirty way to autoplay in all instances.

You mean: Electron's code was simple, but eloquent! 😂

> This code which was posted by @ElectronEsq is a pretty quick and dirty way to autoplay in all instances. You mean: Electron's code was simple, but eloquent! 😂

QuirkyRobots commented

2021-05-14 06:03:48 +02:00

(Migrated from github.com)

@mayeaux Nice. Looks good!

tzarebczan commented

2021-10-08 23:24:25 +02:00

(Migrated from github.com)

Issue moved to OdyseeTeam/odysee-frontend #34 via ZenHub

Issue moved to [OdyseeTeam/odysee-frontend #34](https://github.com/OdyseeTeam/odysee-frontend/issues/34) via [**ZenHub**](https://www.zenhub.com/)

Rows
Columns

Autoplaying + Timestamps in URLs #5309

Now that we have that background knowledge out of the way, the fine details...