Player.js: Disable forward seeking

[monkeylogic]

Expected Behavior

It actually works as documented. So this is just a question I guess. I would like to be able to find the furthest time played before seeking. The reason is so that I can insure users may not seek forward, only backward.

Actual Behavior

When seeked happens, timeupdate also occurs (per the documentation). But this is causing me trouble figuring out the time right before the seek happens so I can be sure not to seek past this point.

Steps to Reproduce

I have come up with a solution, but it seems like there must be a better way.

var curtime = 0;

player.on('timeupdate', function(data) {
    if(data.seconds < curtime + 1 && data.seconds > curtime) {
    // Above is where I hack it.  I only update the current time if the timeupdate is less than a second ago (therefore proabaly not seeked to).  This stops the function from just updating curtime to the seeked time.  But I feel it's not the best way.
        curtime = data.seconds;
    }
});

player.on('seeked', function(data) {
    if(data.seconds > curtime) {
        player.setCurrentTime(curtime);
    }
});

[pixelwiz]

I'm trying to do exactly the same thing. I'm doing it with setInterval. First I tried to record the last timeupdate value for comparison. Then I tried doing it every 3 seconds, but the problem I ran into is sometimes it takes more then 3 seconds to buffer a segment that the user seeked to and by that time the currentTime is already update and allows seek. If I set it to 15 second interval, it pretty much works. But I really don't like doing it this way, seems hacky. There should be a way to just prevent seek forward functionality or at least on seeked to know the from and to time to allow us to compare. But the fact that seeked triggers buffering of that segment immediately is kinda problematic.

[ryanrolds]

:+1:

[xudre]

Looking forward to a solution for this.

[rsmolkin]

Still no API solution to prevent fast forward?

[CarpenterBug]

@rsichel107 do you know the progress of this "enhancement"? This is a very useful feature for tracking.

[rebecca-sich]

Unfortunately there has not been serious progress with this ticket on the team. We can hopefully discuss this as a team soon. Thanks for the ping.

[luwes]

Possible solution is that we expose the video.played property, maybe video.seekable too.

See https://github.com/vimeo/player.js/issues/245

[jybleau]

Thanks @luwes !
Besides played, the seeking property and the seeking event would be useful.
https://jsfiddle.net/jybleau/zes4hbdd/

seekable property seems useful when streaming (?). Maybe it would be also required if we want to implement our own control seek bar, for a better UX.

[luwes]

seeking event is already in production. Getters are coming ^^

[rsmolkin]

Has anyone successfully used the new seeking getters to prevent forward seeking consistently?

[rsmolkin]

@jybleau great implementation example at https://jsfiddle.net/jybleau/zes4hbdd/ but have you been able to get it to work with the Vimeo Player API?

[jybleau]

Thanks @rsmolkin
Since #362 and #373 have been merged and published, I've made a first attempt to adapt my example.
It seems to work so far but requires more work... The player uses the message API and has to wrap almost everything in promises making it slower. Probably acceptable though, and a good start anyway.

https://jsfiddle.net/jybleau/7Lhtcvxk/

[jbhorsewriter7]

Yeah... sometimes it's still letting me skip forward.

[muckinger]

@jybleau
any news / updates here about implementation of feature with Player API?

[jybleau]

@muckinger, do you mean to have this as an integrated feature of the player.js API? If so, it would be a new feature request ticket.

In theory, we have everything available in the API to implement it by ourself.
The implementation example I have is still this one: https://jsfiddle.net/jybleau/7Lhtcvxk/

_(Note it's a forward-seek blocker, you can always seek in the parts of the video that have been already watched)_

So far, no one came up with another attempt, here.

I think it can be used in production with a few more optimizations; it depends on your use case...

[coreybrett]

I'm using the following code to prevent seeking forward. It seems to work for me.

$(document).ready(function () {
    var v1 = new Vimeo.Player(document.querySelector('#v1'));
    var v1maxtime = 0;
    var v1maxtime_old = 0;

    var ontimeupdate = function (data) {
        if (v1maxtime < data.seconds) {
            v1maxtime_old = v1maxtime;
            v1maxtime = data.seconds;

        }
    };

    var onseeked = function (data) {
        if (data.seconds > v1maxtime_old) {
            v1.setCurrentTime(v1maxtime_old);
            v1maxtime = v1maxtime_old;
        }
    };

    v1.on('timeupdate', ontimeupdate);
    v1.on('seeked', onseeked);

});

[jybleau]

@coreybrett nice try, simpler.
But unfortunately with this approach, we can still seek forward when double-clicking further on the timeline, but not by hitting the same position, but by hitting 2 different forward positions and by going further and further while still staying in the downloaded part of the timeline.
Depending on your use case though, it may be sufficient.

Here's your code: Fiddle for Corey's code