I came across an issue with using UMovieSceneSequencePlayer::PlayTo in code - the actual frame that the sequence paused on seemed to be inconsistent and inexact. I narrowed this issue down to the fact that UMovieSceneSequencePlayer::UpdateTimeCursorPosition_Internal does not actually update PlayPosition if it detects that playback needs to pause.
Take a look at the else branch in this function that handles the case of PauseRange.IsSet() (among a few other conditions):
`// If the desired evaluation will take us past where we want to go we need to use a clipped range provided by the PauseRange, otherwise use the normal one.
FMovieSceneEvaluationRange Range = PauseRange.IsSet()
? FMovieSceneEvaluationRange(PauseRange.GetValue(), PlayPosition.GetOutputRate(), bReversePlayback ? EPlayDirection::Backwards : EPlayDirection::Forwards)
: UpdatePlayPosition(PlayPosition, NewPosition, Method);`You can see from this line of code that UpdatePlayPosition is only called if PauseRange is not set. The result of this is that when Pause() is finally called and the sequence player checks PlayPosition for the current time to pause at, the value will still be the time before PauseOnFrame was detected.
To fix this for our codebase, I’ve added this code in the `if (PauseRange.IsSet())` block at the bottom of this else block:
const FFrameTime PauseOnTime = FFrameRate::TransformTime(bReversePlayback ? PauseRange->GetLowerBoundValue() : PauseRange->GetUpperBoundValue(), PlayPosition.GetOutputRate(), PlayPosition.GetInputRate()); UpdatePlayPosition(PlayPosition, PauseOnTime, Method);I probably wouldn’t recommend this as the real fix, since it does some extra back-and-forth conversions between DisplayRate times and TickResolution frames (and I’m not sure if this needs to happen before the UpdateMovieSceneInstance call), but the idea is there. PlayPosition needs to be updated here to match PauseOnFrame, or the sequence won’t actually pause on that exact frame, and the time it does actually pause on will be frame-rate dependent.
We’re on 5.5 right now, but it looks like this is still an issue that affects 5.6.