https://bugs.kde.org/show_bug.cgi?id=364297

            Bug ID: 364297
           Summary: git master 2016-06-14 Clips dragged with spacer tool
                    sometimes loses grouping
           Product: kdenlive
           Version: unspecified
          Platform: Other
                OS: other
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: User Interface
          Assignee: j...@kdenlive.org
          Reporter: evert.vors...@yandex.com

In my usual workflow, I select all the clips I want to work on, and drag them
into the timeline. Then I edit the clips on the timeline for duration and
position, effects and whatever else I feel. Then I press "m", and drag the rest
of the clips closer, press "s" again and repeat the process. 
This way I am not constantly switching between clip monitor and project
monitor, and also I don't have to look for the next clip, it's right there on
the timeline. 

This used to work pretty well until the latest timeline refactoring. 

The worst bug I run into is that sometimes the grouping of audio clips are lost
when I drag them with the spacer tool. Unfortunately it's hard to pinpoint, as
another bug completely crashes gdb and the UI, and the only way I can get it
back is to manually kill gdb, destroying the backtrace. 

Reproducible: Always

Steps to Reproduce:
1. Select and drag a hundred or so clips to the timeline (the problem seems
worse with more clips)
2.resize first clip
3.select spacer tool, drag the rest of the clips closer. 
4. resize second clip, put it on a different line. 
5. drag the rest of the clips closer. 
6. Save project
7. revert to saved project.

Actual Results:  
The grouping between clips and their sound are lost in some occasions, but only
the ones in the clips that were dragged with the spacer tool

Expected Results:  
Clips to retain their grouping through saves. 

I of course use automatic splitting of sound and video. 
When running kdenlive out of a terminal and watching the output, see and error:
"* ** Canot find clip to break: " And then some numbers, which I assume is
frame and track number. 
I have not noticed this error before, and it might be related. On a different
note, Cannot is spelled with two "n" in the middle. ;)
I also see other weirdness on the timeline still, for instance sometimes when I
delete a clip the clip stays there, and I get a warning sound with no error
message. When I then save and restore the clips positioning is messed up,
sometimes, and almost always the grouping have been lost between video and
audio clips.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to