View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000362KdenliveUser Interfacepublic2008-11-18 12:592010-11-15 13:54
Assigned Toj-b-m 
PrioritynormalSeverityminorReproducibilityhave not tried
Platformi386OSlinuxOS Versionkubuntu
Product VersionRecent git 
Target VersionFixed in Version0.7.1 
Summary0000362: weird/wrong behaviour when moving 'crop from start' in a layout with 3 clips e.g.
DescriptionThe right edge of the second clip slips over, and sometimes under, the start of the third clip when moving 'crop from start' (the left edge) of the second clip to the left.

Also undo is broken after that action.
Steps To Reproduce- Make a new project.
- Put 3 regions/parts (not the whole clips) of 3 clips on the timeline, one after another with no gaps.
- Move the right edge of the second clip to the left.
- do 'ctrl + z'.

Additional InformationIn general I really like this behaviour, when moving the left edge of the third clip to the left, which enlarge this clip.
So, it would be nice if this would work also with clips in between, like the example above, where the following clips will be moved then without creating gaps.
But maybe this should be initiated by modifier keys like:

- shift + left/right == change the length of the clip AND project.
- ctrl + left/right == change the length of the clip but NOT of the project; this means that the adjacent clip will be changed in length.
- alt + left/right == just move the I/O region (the frames) but not the clips position on the timeline.
TagsNo tags attached.
Build/Install Method(select)
Attached Files? file icon kbw.gdb.output.CEH16398 [^] (24,548 bytes) 2008-11-19 20:46
? file icon capture0008.ogv [^] (3,036,296 bytes) 2008-11-30 18:02

- Relationships

-  Notes
madsdyd (administrator)
2008-11-19 20:43

I get a crash for 2714 when I try to do the steps to reproduce (attaching backtrace)

Is that the same you get.

And, is this really two bugs: no undo for that operation, and that you want to be able to move the remaining track when you uncrop a middle clip?
cinephiliac (updater)
2008-11-27 02:08

Reminder sent to: reinhard


This issue is marked as fixed in the latest svn revision (2736). Could you update your Kdenlive (run the KBW again if that's how you installed) and let us know if this problem has been fixed for you?


reinhard (reporter)
2008-11-28 00:50


Yes I still use kbw (kdenlive svn 2740) and in general the initial problem is fixed, but I just wondering why I can't move the left edges of clip 1 + 2...

Another problem is when moving the right edge of clip 1 or 2 a bit too much to the right (upon the clip on the right side). In this case a black frame will created, because the right edge jumps one frame to the left.

And also yes to 'want to be able to move the remaining track when you uncrop a middle clip', but this may be changed into a feature request for now.
Actually the focus should be on providing basic editing functionality...

cinephiliac (updater)
2008-11-28 22:08

Hi Reinhardt,

I'm having trouble understanding your description of this problem. As far as I can see, all track edges are able to be moved left or right wherever there is extra footage. A couple of things would help:

1. Limiting each bug report to only 1 issue / wish.
2. Describing how you create this problem step-by-step (see the "Steps to Reproduce" part of [^] for an example)
3. An image or video screengrab that shows the problem.
4. Explaining what you mean by clip 1+2. Do you mean a specific clip on track#1 and another specific clip on track#2, or are you referring to three segments on one track, the first being #1, the second being#2 and the third being 0000003?

The clearer the bug description, the faster we can get it fixed. :)


(a confused) Cinephiliac
reinhard (reporter)
2008-11-30 17:49


I'm sorry confusing you, but I'm not a native english speaker, but I try my best ;)

About 1.
The new problem seems to be some kind of a follow up of the initial issue, so I thought I simply put it into the same thread, but the next time I will start a new issue.

About 2.
Since I answered to this issue I still used the same 'layout' as described above in "Steps to Reproduce".
This means - still 3 segments in one track.

About 3.
I've tried to upload a screengrab session, but I failed due to limited upload bandwith... but I will try again.

About 4.
Yes, 3 sequenced segments in one track.
And the left edge of segment 1 and 2 can't be moved.
And e.g. the right edge of the first segment will be shortened by 1 frame when you drag this right edge a bit too much too the right (rev. 2740).
I will try now to upload a screengrab... ;)

madsdyd (administrator)
2008-11-30 22:08

svn 2736 stops the crash. There are still issues with the clip resizing though. We need a concise description of the current, and intended behaviour. Unfortunately I am not able to create it right now.

There are some weirdness in some of this, and also a feature request.
reinhard (reporter)
2008-12-21 17:38

ok, you are right - we should isolate the real issue here.
This seems to be the changing of 'crop from start:' which seems to work only for the last clip in timeline (still assuming 3, or more, clips in a row).
So, actually (rev. 2809), 'crop from start:' can't be changed (by moving the left edge to the right side) by any of the previous clips to the left.

At least personally I think it should be possible to change 'crop from start:' for ANY clip in the timeline... ;)
madsdyd (administrator)
2008-12-28 23:52

Some changes to this behaviour has been commited in svn rev. 2816.

I do not understand what this issue is about any longer, but I have made some observations myself. I find two issues that I believe are flawed:

a) Moving the right edge of a clip will *sometimes* move it left.
b) Moving the left edge of a clip, will allow it to grow right, if there is room

I think a) is a bug. b) is highly confusing and potentially damaging.

Since I believe a) to be a bug, I am acknowledging.

Steps to reproduce:

- start kdenlive
- add a clip to the timeline
- cut into three ([a][b][c]).
- zoom in on the ab cut
- gently drag the green triangle of a to the right. Observe how the right end of a may move left(!)
- now, drag the right end of b a little to the left, getting something like: [a][b][space][c]
- drag the left side of b to the left, observe how b grows to the right.

I am unsure what the intended behaviour should be? But these issues confuses me...
madsdyd (administrator)
2008-12-30 00:25

Svn commit 2852 (part of 0.7.1) fixes issue b) from comment 1951.

a) is still present, when zoomed into the cut, but appears to not be present when not zoomed in.

What to do? Is this little flaw acceptable?
administrator (administrator)
2008-12-30 18:06

a) was not fixed because I could not reproduce it. It needs to be fixed, so I will look at it.

- Issue History
Date Modified Username Field Change
2008-11-18 12:59 reinhard New Issue
2008-11-19 20:43 madsdyd Note Added: 0001256
2008-11-19 20:43 madsdyd Status new => feedback
2008-11-19 20:46 madsdyd File Added: kbw.gdb.output.CEH16398
2008-11-27 02:08 cinephiliac Note Added: 0001438
2008-11-28 00:50 reinhard Note Added: 0001450
2008-11-28 22:08 cinephiliac Note Added: 0001454
2008-11-30 17:49 reinhard Note Added: 0001461
2008-11-30 18:02 reinhard File Added: capture0008.ogv
2008-11-30 22:08 madsdyd Note Added: 0001468
2008-12-21 17:38 reinhard Note Added: 0001869
2008-12-28 23:52 madsdyd Note Added: 0001951
2008-12-28 23:52 madsdyd Status feedback => acknowledged
2008-12-30 00:25 madsdyd Note Added: 0001972
2008-12-30 18:06 administrator Note Added: 0001979
2010-11-15 13:53 ttill Build/Install Method => (select)
2010-11-15 13:53 ttill Assigned To => j-b-m
2010-11-15 13:53 ttill Status acknowledged => resolved
2010-11-15 13:53 ttill Resolution open => fixed
2010-11-15 13:53 ttill Fixed in Version => 0.7.4
2010-11-15 13:54 ttill Status resolved => closed
2010-11-15 13:54 ttill Fixed in Version 0.7.4 => 0.7.1

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker