My issue on this got closed for being duplicate so just commenting that I have the same issue.
EDIT:
Something I didn't mention in my issue was that I was playing MKV files.

I have the same issue every now and then, but also do have unexpected key repeats in other places, that I can't really put anywhere. Looks like a error in the GNOME Shell/Wayland stack.

@thebitstick @fbruetting Are you using GNOME Shell? Which version and system? Wayland or Xorg?

GNOME Wayland, 3.30.2, on F29.
Mentioned this in my closed issue but I am using the Flatpak version from Flathub.

Fedora Silverblue 29 with Gnome 3.30.2 on Wayland.

I tested this under Xorg and could not reproduce it at all, so the error is probably not in gnome-mpv, but in GTK or libinput. I reported it here

Not sure if it helps but I'm also experiencing this issue on Fedora 29 Gnome. However the issue does not present if I open the videos in MPV.

This is resolved for me with libinput 1.14.1 and mutter 3.34.0, if anyone can confirm I would suggest closing this issue.

Seems to be fixed for me as well.

For me on Fedora Silverblue 31 beta it’s sadly still not fixed (with exactly those versions). Sometimes it jumps 5s, sometimes 7s, sometimes 20s and sometimes directly to the end. I also don’t understand what libinput or mutter does have to do with time skipping? I would asume that time skipping is a pure application-internal function…?

Libinput is the library that handles the key presses, which are then passed on to Celluloid/GNOME-MPV. You can find the version number with libinput --version and mutter --version. Are they lower than the listed libinput 1.14.1 and mutter 3.34.0?

Ditto not fixed on Debian Testing/Bullseye. Mutter is 3.34, libinput is 1.14.1, but the steps in the player are just as inconsistent as before.

Note: the issue also occurs when running the player in Weston. I would say it's most likely not related to Mutter.

Libinput may handle key presses, but I can’t image that pressing a key once, gives various amounts of keypresses solely to Celluloid, whereas it works perfectly fine everywhere else.

Additionally, the varying steps are not multiplyers of a base value, like 5/10/15, but totally arbitrary like 7 or 10 seconds. In the end it’s Celluloid itself, which translates key presses into an amount of time to skip. And I suspect the bug to crawl around there.

Agreed with above. If mutter is not the problem, that leaves either libinput or GTK. I can't see something as fundamental as keypresses being broken in libinput without system-wide repercussions, and as for GTK, I have tested playing videos in Wayland Firefox and could not reproduce this issue. The problem is most likely in Celluloid.

@fbruetting, @SimonPilkington: Can you check if this still happens with --input-ar-rate=0?

input-ar-rate=0 actually fixes the problem for me.

Using exact seek instead of keyframes seek also fixes the problem.

❯ io.github.celluloid_player.Celluloid --input-ar-rate=0
Unknown option --input-ar-rate=0

It goes either in your mpv.conf or in the additional mpv options in the Celluloid configuration dialog.

In my short testing, it then still jumps in unpredictable intervals between 5 and 10 seconds. And it’s really arbitrary, as when you repeatedly skip backwards and immediately afterwards skip forwards, there might be up to a ten seconds displacement (i.e. 1:30 (arrow left)⇒ 1:25 (arrow right)⇒ 1:37, where the last value shout rather be 1:30 or 1:31)

This is due to keyframes seeking, and is expected. If you wish to have exact seeking like you described, you must rebind your left and right arrows to use exact seeking. By your description, input-ar-rate=0 fixes the problem for you as well.

I did exactly that. I put that into the appropriate configuration dialog field you mentioned.

You can't rebind keys in the configuration dialog. You must use an input.conf with this content:

LEFT seek -10 exact
RIGHT seek 10 exact

The issue is still present on Arch Linux as of 2020-04-23.

Please note that mpv itself is not affected by the issue.

It seems to me when such a wrong long-seek occurs, that there is a greater time span between e.g. arrow-right-keydown and the video resuming playback at the new location, compared to a step that seeks for the correct amount.

Therefore my hypothesis is that the bug is triggered when seeking takes more time, for example when by chance more video data needs to be read to complete the seek. The cause would then be that the arrow-right-keyup event is not processed while this seeking/reading is taking place, instead only afterwards with a delay, which then causes the auto-repeat to kick in and not only a single step is seeked, but multiple steps.

This would be consistent with these observations:

• input-ar-rate=0 works around the issue
• seeking with the mouse wheel on the seek bar does not exhibit the buggy behavior
• the faulty long-seeks appear to be of various, seemingly arbitrary lengths

Arch Linux celluloid package, version 0.18-1, build date 2019-11-09

GNOME Shell 3.36.1 on Wayland, Linux 5.6.6-arch1-1 x86_64

@gnome-mpv this is definitely your bug see comment of eomanis, I can reproduce in Manjaro KDE

I agree with eomanis' analysis, but we still need to figure out if the key event is being delayed in Celluloid or mpv.

Celluloid sends key events to mpv using the keyup/keydown input commands, so there are a few possibilities here. There could be a delay in Celluloid causing the input commands to be sent late, or mpv takes too long to process the commands, or a combination of both.

Confirming this is an issue for me as well.

Pressing the seek keys (left and right arrows) will seek arbitrarily, same for 1 second seek (with shift).
It even occured that it would seek for so long that I would be "stuck" in full screen (and it wouldn't respond to any other input).

Kernel: 5.4.0-42-generic 
DE: Plasma 
WM: KWin 
CPU: AMD Ryzen 7 3700X (16) @ 3.600GHz 
GPU: AMD ATI Radeon RX 5600 OEM/5600 XT / 5700/5700 XT 
Memory: 11069MiB / 15991MiB 

Same problem on openSUSE Tumbleweed, Gnome 40 at Wayland and 0.20 version of celluloid.

It is very frustrating to navigate on video with constantly random time jumps.

Is there any downside to binding the left and right keys to seek exactly by default (like what @SimonPilkington does above)?

Is there any downside to binding the left and right keys to seek exactly by default (like what @SimonPilkington does above)?

@J-James: Seeks might take longer on slower machines, and if @eomanis's analysis is correct, that could make the problem worse in some cases. input-ar-rate=0 should be a more reliable workaround, but then you won't be able to hold a key down to do multiple seeks.

A reliable workaround is to pause the video playback before seeking.

And as confirmed by many others, this bug does not happen in mpv itself, only in Celluloid.

input-ar-rate=0 is not a solution for me, because I'd still like to be able to do frame-by-frame seeking using different input keys, e.g.

LEFT frame-back-step
RIGHT frame-step
Shift+LEFT seek -10
Shift+RIGHT seek 10

You must use an input.conf with this content:

LEFT seek -10 exact
RIGHT seek 10 exact

This is what fixed it for me. I made an input.conf file, dropped those two lines in, and loaded it into celluloid, and now it works exactly as expected. I can tap a single time to seek my chosen amount, hold the button to continue seeking, and use < & > to seek frame by frame. I imagine the default should be for time based seeking to use exact seeking, while leaving everything else unchanged.

I'm not sure why, but for me it seems as though I can no longer reproduce this bug on GNOME 46, on the same video files for which I used to experience this bug. Very strange, seeing as this bug clearly affects Plasma users as well.

1+ having thia problem with celluloid 0.27 running on fedora 40. tweaking config file didn't fix.