Sequencer: Invalid timecode values makes strip drawing a mess. #65723

New Issue

tintwotin · 2019-06-11T15:13:28+02:00

tintwotin commented

2019-06-11 15:13:28 +02:00

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: Intel(R) UHD Graphics 600 Intel 4.5.0 - Build 24.20.100.6137

Blender Version
Broken: version: 2.80 (sub 74), branch: blender2.7, commit date: 2019-06-08 13:24, hash: 81b68f7279
Worked: (optional)

Short description of error
When invalid values are used in the timecode panel the strips will become a mess.

Exact steps for others to reproduce the error
Add a movie strip.
Open the Sidebar - Timecode.
Play around with the sliding values.

Gif of the procedure and the bug:

**System Information** Operating system: Windows-10-10.0.17763 64 Bits Graphics card: Intel(R) UHD Graphics 600 Intel 4.5.0 - Build 24.20.100.6137 **Blender Version** Broken: version: 2.80 (sub 74), branch: blender2.7, commit date: 2019-06-08 13:24, hash: `81b68f7279` Worked: (optional) **Short description of error** When invalid values are used in the timecode panel the strips will become a mess. **Exact steps for others to reproduce the error** Add a movie strip. Open the Sidebar - Timecode. Play around with the sliding values. Gif of the procedure and the bug: ![TimeCode_clamping.gif](https://archive.blender.org/developer/F7098646/TimeCode_clamping.gif)

tintwotin commented

2019-06-11 15:13:28 +02:00

Added subscriber: @tintwotin

Richard Antalik commented

2019-06-11 15:18:04 +02:00

Added subscriber: @iss

Richard Antalik commented

2019-06-11 15:18:04 +02:00

Is this new issue?
I mean it should be easy to fix, but not sure if I should look for what caused this.

Is this new issue? I mean it should be easy to fix, but not sure if I should look for what caused this.

tintwotin commented

2019-06-11 16:42:44 +02:00

Just checked 2.73. Same bug.

Richard Antalik was assigned by Sebastian Parborg

2019-06-17 14:27:26 +02:00

tintwotin commented

2019-07-10 23:56:34 +02:00

Added subscriber: @WilliamReynish

tintwotin commented

2019-07-10 23:56:34 +02:00

I don't know if changing the 'End' value to a label is a fix for the above mentioned bug?

But as shown in the gif in the bug report, it also includes the Strip & Hold Offset values. So maybe it's better to leave End as it was(as a know bug), until there is time for a proper fix, or if not, then use the alignment code from Playhead for the End value, so it won't be misaligned?

I don't know if changing the 'End' value to a label is a fix for the above mentioned bug? ![image.png](https://archive.blender.org/developer/F7585873/image.png) But as shown in the gif in the bug report, it also includes the Strip & Hold Offset values. So maybe it's better to leave End as it was(as a know bug), until there is time for a proper fix, or if not, then use the alignment code from Playhead for the End value, so it won't be misaligned?

Richard Antalik commented

2019-07-11 00:12:13 +02:00

In #65723#717723, @tintwotin wrote:
I don't know if changing the 'End' value to a label is a fix for the above mentioned bug?

Nope. It's quite easy to limit the value.
I will get to this eventually but this bug is super low priority

> In #65723#717723, @tintwotin wrote: > I don't know if changing the 'End' value to a label is a fix for the above mentioned bug? Nope. It's quite easy to limit the value. I will get to this eventually but this bug is super low priority

tintwotin commented

2019-07-11 00:21:00 +02:00

According to this comment it is a way to workaround that bug:

According to this comment it is a way to workaround that bug: ![image.png](https://archive.blender.org/developer/F7586184/image.png)

Campbell Barton commented

2019-07-11 01:28:12 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-07-11 01:28:12 +02:00

These were internal variables for cutting strips and not meant to be exposed.

Editing these values can easily create an invalid state.

Further, these values are hard to understand.

Unless a fix is trivial, would remove these buttons for 2.8x release.

We could have an operator to reset these start/end cut values, eg: "Reset Cut Limits", which users can run if they need to set the limits back to the source strip.

These were internal variables for cutting strips and not meant to be exposed. Editing these values can easily create an invalid state. Further, these values are hard to understand. Unless a fix is trivial, would remove these buttons for 2.8x release. ---- We could have an operator to reset these start/end cut values, eg: "Reset Cut Limits", which users can run if they need to set the limits back to the source strip.

tintwotin commented

2019-07-11 08:01:53 +02:00

The offset(hard/soft cut) values have been exposed as buttons in many years(without limits on invalid values). Here they are in Blender 2.72:

The offset(hard/soft cut) values have been exposed as buttons in many years(without limits on invalid values). Here they are in Blender 2.72: ![image.png](https://archive.blender.org/developer/F7589822/image.png)

Campbell Barton commented

2019-07-11 09:29:13 +02:00

You're right, (was looking at the edit strip panel which only has start frame & length).

The way they are presented makes them more prominent in 2.8.

Lowering priority since this issue isn't new in 2.8x.

You're right, (was looking at the edit strip panel which only has start frame & length). The way they are presented makes them more prominent in 2.8. Lowering priority since this issue isn't new in 2.8x.

tintwotin commented

2019-07-11 12:42:50 +02:00

So is the UI change with 'End' going to be rolled back for now?

Richard Antalik commented

2019-07-11 12:54:13 +02:00

Nope.

Master is frozen.
only critical bugfixes are allowed

Nope. Master is frozen. only critical bugfixes are allowed

Campbell Barton commented

2019-07-29 04:13:27 +02:00

Knife-cut and Transform have checks to ensure invalid start/end cases don't happen.

Some buttons were exposed that allow this - which is unfortunate.

This case looks like a bug and isn't properly handled by tools & draw code.

Instead of using buggy/low quality code as an excuse to make this weakness more prominent, why not try and solve the problem?

Possible solutions:

Separate RNA properties to expose to the interface, frame_final_end_ui for example.
Add clamping to frame_final_end, then use a function strip.frame_final_set(start=a, end=b) so these values can be updated, or omitted to use the current value.

Knife-cut and Transform have checks to ensure invalid start/end cases don't happen. Some buttons were exposed that allow this - which is unfortunate. This case looks like a bug and isn't properly handled by tools & draw code. Instead of using buggy/low quality code as an excuse to make this weakness more prominent, why not try and solve the problem? Possible solutions: - Separate RNA properties to expose to the interface, `frame_final_end_ui` for example. - Add clamping to `frame_final_end`, then use a function `strip.frame_final_set(start=a, end=b)` so these values can be updated, or omitted to use the current value.

tintwotin commented

2019-08-09 14:15:21 +02:00

@iss Could this be added to a VSE To Do list here on developer.blender.org?

Richard Antalik was unassigned by Dalai Felinto

2019-12-23 16:34:07 +01:00

Campbell Barton commented

2020-03-10 07:04:00 +01:00

Note that one of the issues caused by not properly clamping values leads to a crash #74603 (Video Sequence Time slider ignores handle offset constraints (leading to crash)).

Richard Antalik commented

2020-03-10 09:15:22 +01:00

Closed as duplicate of #74602

Richard Antalik closed this issue

2020-03-10 09:15:22 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Sequencer: Invalid timecode values makes strip drawing a mess. #65723