peek
peek copied to clipboard
phw
Peek countdown recorded in GIF
Peek countdown is recorded in the saved GIF. Take a closer look and you will see the count down is visible for a fraction of a second.
Is this the latest Peek version? There was a fix for this in Peek 1.0.2, see https://github.com/phw/peek/issues/146
Closing this as I think that an older Peek version (< 1.0.2) was used here. Feel free to comment if this is not the case.
I can finally reproduce. Actually the countdown is not included at the beginning, but on the very last frame. Looks like this is happening when recording stops and the UI gets reset again for the next recording.
Ok, can't reproduce it again and looking at the code path I have no clue what could cause it. The timeout really should be hidden until a new recording gets started.
I got another weired case where the countdown was shown neither at the start nor end, but 1 or 2 frames into the animation. Unfortunately I deleted the file.
Really not sure what is happening here. Might be some GTK3 quirk.
@phw - This happened to me recently in v1.2.2. I could see the last screen of the countdown right at the start of my gif. I will see can I record an example for you. Only workaround for me was to turn off the countdown.
Actually this even happens to me without the countdown active in many cases, but it is not reliable reproducable. Just sometimes I get a gray frame. This currently has highest priority for me, I want to get this fixed for the next release. In the worst case I have to add some random timeout.
I pushed a change from which I hope will fix this issue. But as this is so hard to reproduce for me I can't be sure. I would aprreciate if someone could test the development version a try and use this for a while to see if this issue is gone.
Either build from source or use the Flatpak dev version (see README), this is already up-to-date.
Hooray! I haven't had the issue, too, so far. Let's hope this really fixed it. I will do a new release soon.
I just had it again :( Countdown visible in the first frame. I have to investigate again.
For me, it seems to happen when the cursor is active when the countdown gets to zero and it starts recording.
Thank you for looking into the issue I posted. I'm hopeful you guys would be able to find a solution.
I just experienced this bug as well, but can't seem to reproduce. It only happened in the very first recording after installing Peek, and it put the "1" part of the countdown into the first 3 frames of the gif. Hopefully that is useful. If you need the file, let me know.
Just a wild guess, can the frame-rate conversion from high to low (down-sampling) can introduce an unintended frame to the gif due to the frame index rounding?
Also experiencing this issue, almost every time. Happy to help test things.
$ uname -a
Linux e480 5.0.0-23-generic #24~18.04.1-Ubuntu SMP Mon Jul 29 16:12:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ X -version
X.Org X Server 1.20.4
$ gnome-shell --version
GNOME Shell 3.28.4
$ peek -v
Peek 1.3.1
Happens to me too on 1.3.1. As @dlbnco mentioned, disabling "Capture mouse cursor" in Preferences fixes it so it's possibly related to that.
Happening for me in 1.4.0 as well. As with earlier reports, the frame containing "1" appears at the end of affected animations.
$ uname -a
Linux stephen-x1 5.3.0-19-generic #20-Ubuntu SMP Fri Oct 18 09:04:39 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ gnome-shell --version
GNOME Shell 3.34.1
$ peek -v
Peek 1.4.0
Hello i confirm this issue in random times. I recorded several times the same screen, with different formats and different delays. Sometimes it happens other times not ( Peek Version 1.4.0 ) I hope it can be resolved soon :) Anyway thank you for the project!
I can also confirm this happens at random every so often.
Linux [hostname] 5.4.0-42-generic #46~18.04.1-Ubuntu SMP Fri Jul 10 07:21:24 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
GNOME Shell 3.28.4
Peek 1.5.1
