-Upload the attached animation "2-frame-anim", not looped, with ease-in = 0, and ease-out = 0. The BVH is set at 1 frame per second.
-Play the animation.

Observe: The animation lasts 3 seconds. The first 2 seconds it is stuck in frame 1. The third second you see the actual movement from frame 1 to frame 2.
So it plays like this: 1 - 1 - 1 - 2

Expected: the animation should last 1 second, playing like this: 1 - 2

=======

Repro to show there is no interpolation between end- and start-frame when looping:

-Upload the same animation, but now looped, with In(%) = 0 and Out(%) = 100
-Play the animation.

Observe: After frame 2 is reached, the animation suddenly jumps back to frame 1, there is no smooth movement between frame 2 and frame 1.
The animation plays like this: 1 - 1 - 1 - 2/1 - 1 - 1 - 2/1 - 1 - 1 - 2/1 - ...

Most people would expect the animation to loop like this: 1 - 2 - 1 - 2 - 1 - ...

=======

Partial workaround to correct looped animations:

Suppose you want the above animation played like this: 1 - 2 - 1 - 2 - 1 ...

-In your animation program, copy the first frame, and paste it after the last frame.
-Upload the animation with In(%) = 200 / (n + 2)

Where n is the number of frames of your original animation (n = 2 in this example, that gives In(%) = 50%)
The start of a loop, or non-looped animations can't be fixed using this workaround.

=======

When uploading an animation, the first frame of animation is played for 2 frames. (When I say "first frame of animation", I'm referring to the second motion entry in the file; the first entry is usually considered to be a reference, against which the other frames are compared, and isn't supposed to be played.)

This bug has been around for a long time; it's visible to a keen eye in animations dating back over a year, perhaps even longer. But since animations are often a few hundred frames at 30 frames per second, this bug usually only manifests itself as a very brief pause as the animation loops.

In animations at low framerates, the effect is more noticeable. I've created a sample animation that's plays at 1 frame per second to help repro this issue. The animation has 4 frames of animation, not including the reference position. Frames 1 and 4 have the left arm in the down position. Frames 2 and 3 have the arm in the up position. So, played in a loop, the arm should spend an equal amount of time in either position. But with the bug, it spends one second longer in the down position. (I've attached an image to help make sense of this.)

Repro:
1. Upload the attached animation for uploading (tick_tock.bvh) with Priority 4, Looping, and 0 ease-in and ease-out. (If you don't want to spend the L$10, you can just watch it in the animation preview.)
2. Play the animation.
= Observed: The avatar's arm spends more time fully down than it spends fully up.

• Expected The avatar's arm should spend the same amount of time in the down position as in the up position.