Peek: Compte à rebours Peek enregistré en GIF

Est-ce la dernière version de Peek? Il y avait un correctif pour cela dans Peek 1.0.2, voir https://github.com/phw/peek/issues/146

En fermant cela, je pense qu'une ancienne version de Peek (<1.0.2) a été utilisée ici. N'hésitez pas à commenter si ce n'est pas le cas.

Je peux enfin reproduire. En fait, le compte à rebours n'est pas inclus au début, mais sur la toute dernière image. On dirait que cela se produit lorsque l'enregistrement s'arrête et que l'interface utilisateur est à nouveau réinitialisée pour l'enregistrement suivant.

Ok, je ne peux pas le reproduire à nouveau et en regardant le chemin du code, je n'ai aucune idée de ce qui pourrait le causer. Le délai d'attente doit vraiment être masqué jusqu'à ce qu'un nouvel enregistrement démarre.

J'ai eu un autre cas bizarre où le compte à rebours n'était affiché ni au début ni à la fin, mais 1 ou 2 images dans l'animation. Malheureusement, j'ai supprimé le fichier.

Je ne sais vraiment pas ce qui se passe ici. Peut-être une bizarrerie GTK3.

@phw - Cela m'est arrivé récemment dans la v1.2.2. Je pouvais voir le dernier écran du compte à rebours juste au début de mon gif. Je vais voir puis-je enregistrer un exemple pour vous. La seule solution de contournement pour moi était de désactiver le compte à rebours.

En fait, cela m'arrive même sans le compte à rebours actif dans de nombreux cas, mais ce n'est pas reproductible de manière fiable. Parfois, j'obtiens un cadre gris. Cela a actuellement la plus haute priorité pour moi, je veux que cela soit corrigé pour la prochaine version. Dans le pire des cas, je dois ajouter un délai d'attente aléatoire.

J'ai poussé un changement dont j'espère que cela résoudra ce problème. Mais comme c'est si difficile à reproduire pour moi, je ne peux pas en être sûr. J'apprécierais si quelqu'un pouvait tester la version de développement et essayer de l'utiliser pendant un certain temps pour voir si ce problème a disparu.

Soit construire à partir des sources, soit utiliser la version de développement Flatpak (voir README), c'est déjà à jour.

@phw - Construit à partir de la source. Le correctif fonctionne. :)

Hourra! Je n'ai pas eu le problème, aussi, jusqu'à présent. Espérons que cela a vraiment résolu le problème. Je ferai bientôt une nouvelle version.

Je considère cela fermé pour l'instant avec Peek 1.3.0 (sera disponible sous peu).

Je viens de l'avoir à nouveau: (Compte à rebours visible dans la première image. Je dois enquêter à nouveau.

Je viens de l'avoir pour la première fois aussi.

Pour moi, cela semble se produire lorsque le curseur est actif lorsque le compte à rebours arrive à zéro et qu'il commence à enregistrer.

Merci d'avoir examiné le problème que j'ai publié. J'espère que vous pourrez trouver une solution.

Je viens de rencontrer ce bug aussi, mais je n'arrive pas à me reproduire. Cela ne s'est produit que dans le tout premier enregistrement après l'installation de Peek, et il a placé la partie "1" du compte à rebours dans les 3 premières images du gif. J'espère que c'est utile. Si vous avez besoin du fichier, faites-le moi savoir.

Juste une supposition sauvage, la conversion de la fréquence d'images de haut en bas (sous-échantillonnage) peut-elle introduire une trame involontaire dans le gif en raison de l'arrondi de l'index de trame?

Également confronté à ce problème, presque à chaque fois. Heureux d'aider à tester les choses.

$ 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

Cela m'arrive aussi sur 1.3.1. Comme @dlbnco l'a mentionné, la désactivation de "Capturer le curseur de la souris" dans les Préférences corrige le problème, donc c'est peut-être lié à cela.

Cela se passe aussi pour moi dans la 1.4.0. Comme dans les rapports précédents, le cadre contenant «1» apparaît à la fin des animations affectées.

$ 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

Bonjour, je confirme ce problème à des moments aléatoires.
J'ai enregistré plusieurs fois le même écran, avec des formats et des délais différents.
Parfois, cela arrive d'autres fois pas (Peek Version 1.4.0)
J'espère que cela pourra être résolu bientôt :)
En tout cas merci pour le projet!

Je peux également confirmer que cela se produit au hasard de temps en temps.

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

Également confirmé ici sur peek 1.5.1 et Ubuntu 20.04 LTS