Comment 10 for bug 1198555

I'm affected too. I looked into the code and the cause are the functions on_txtIn_value_changed and on_txtOut_value_changed which try to sanitize the start and end times of the clip.

on_txtIn_value_changed checks if the start time is not bigger than the end time, but it is called before before the txtOut (end time) is set, so it always checks agains an end time of 0. This can be fixed with the patch from Bjorn Hjortsberg which first sets the end time and then the start time.

on_txtOut_value_changed checks if the end time is at least as big as the start time and if the end time is no bigger than the clip length. The first check doesn't do harm if we change the order of the initializing as the check is then performed with a start time of 0. The second check is not valid though: If you slow down the clip you have to enter an end time according to slowed time which can be larger than the clip length. And if you want the last frame of a clip to be visible after the clip is finished, you need a bigger end time than clip length too.

I attached a patch which includes the patch from Bjorn Hjortsberg to reorder initialization and additionally removes the bogus check of the end time against the clip length.