Kdenlive   bug tracker Home page

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001207KdenliveUser Interfacepublic2009-10-12 18:542010-09-22 17:54
Reportertbartdev 
Assigned Toddennedy 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platform32 bit intel and alikeOSGentoo LinuxOS Version2008.0
Product VersionRecent git 
Target Version0.7.8Fixed in Version0.7.8 
Summary0001207: Playback stops too early
DescriptionWhen playing back certain clips (AVC.1 file from consumer camera, or the sample provided in http://www.kdenlive.org/mantis/view.php?id=1041 [^]) the playback position stops too early when playing the clip on the timeline (some +/- 10 frames too early). It never plays until the actual end of the clip.

This (or a related bug?) also results in timeline redrawing errors at the end of clips and/or cuts not really being where expected (also some frames off..)
Steps To Reproduce1) Take flv clip from http://www.kdenlive.org/mantis/view.php?id=1041 [^] and remove .txt extension.
2) Shortly laugh about the skilled cameraman they gave us for our gig.
3) Drag clip onto timeline.
4) Playback clip, it should end a little after the drummer hits the crash.
5) Actually it does before.
Additional InformationMLT and KDEnlive as of today, 12 Oct 2009.
Built with SVN/git ebuild under up-to-date Gentoo.
TagsNo tags attached.
Build/Install MethodOther Method?
Attached Filestxt file icon kdenlive-1207.txt [^] (2,014 bytes) 2010-02-24 07:03 [Show Content]
txt file icon kdenlive-1207-2.txt [^] (4,070 bytes) 2010-02-25 09:33 [Show Content]
txt file icon kdenlive_1207_al.txt [^] (9,413 bytes) 2010-03-04 06:35 [Show Content]

- Relationships

-  Notes
(0004141)
ddennedy (developer)
2009-10-13 06:50

Sorry, but I can not reproduce. I used your sample file. When I ask ffmpeg to convert the video to a still image sequence, I get 43 images. When I ask melt to do the same (with -profile quarter_pal), I get the same result. When I play with Kdenlive or melt, I get very close to the same output as I get with ffplay, VLC, or totem (~1.7 sec).
Maybe it is your FFmpeg version. Please provide it. I am using
  built on Sep 15 2009 19:01:07, gcc: 4.4.1
FFmpeg SVN-r19873
libavutil 50. 3. 0 / 50. 3. 0
libavcodec 52.35. 0 / 52.35. 0
libavformat 52.38. 0 / 52.38. 0
(0004166)
tbartdev (reporter)
2009-10-15 17:43

Well, just checked.
Mplayer plays it fine and gives me 1.7 secs.
melt -profile quarter_pal stops at frame 42 and plays it correctly till the end.
ffplay plays it correctly till the end.

I don't think it is ffmpeg, then.

However, here goes my ffmpeg output:
tbart@blackknight ~ $ ffmpeg -version
FFmpeg version 0.5, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib --mandir=/usr/share/man --enable-static --enable-shared --cc=i686-pc-linux-gnu-gcc --disable-debug --disable-network --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-libdc1394 --disable-demuxer=v4l --disable-demuxer=v4l2 --disable-demuxer=oss --disable-muxer=oss --enable-x11grab --enable-pthreads --disable-altivec --cpu=core2 --disable-vhook --enable-gpl --enable-postproc --enable-avfilter --enable-avfilter-lavf --enable-swscale --disable-stripping --enable-hardcoded-tables
  libavutil 49.15. 0 / 49.15. 0
  libavcodec 52.20. 0 / 52.20. 0
  libavformat 52.31. 0 / 52.31. 0
  libavdevice 52. 1. 0 / 52. 1. 0
  libavfilter 0. 4. 0 / 0. 4. 0
  libswscale 0. 7. 1 / 0. 7. 1
  libpostproc 51. 2. 0 / 51. 2. 0
  built on May 14 2009 13:53:34, gcc: 4.3.2

kdenlive also has all the frames if I manually move the playback position. I just does not play until the end.
I just noticed that this also happens in the clip monitor without the clip being on the timeline.
!! If I right click the clip and deactivate Real time (drop frames) it (nearly) completes playing the clip. !!
(Note however that this is a 2x2,5GHz Penryn Thinkpad, and I don't think I have performance issues..)
I can try building FFmpeg SVN, do I then have to rebuild anything else as well?
(revdep-rebuild will tell me I guess..)
(0004169)
tbartdev (reporter)
2009-10-17 00:02

Tested with
blackknight ~ # ffmpeg -version
FFmpeg version SVN-r19928, Copyright (c) 2000-2009 Fabrice Bellard, et al.
  configuration: --prefix=/usr --libdir=/usr/lib --shlibdir=/usr/lib --mandir=/usr/share/man --enable-static --enable-shared --cc=i686-pc-linux-gnu-gcc --disable-debug --disable-network --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-libdc1394 --disable-indev=v4l --disable-indev=v4l2 --disable-indev=oss --disable-outdev=oss --enable-x11grab --enable-pthreads --disable-vdpau --disable-altivec --cpu=core2 --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --enable-avfilter-lavf --disable-stripping --enable-hardcoded-tables
  libavutil 50. 3. 0 / 50. 3. 0
  libavcodec 52.35. 0 / 52.35. 0
  libavformat 52.38. 0 / 52.38. 0
  libavdevice 52. 2. 0 / 52. 2. 0
  libavfilter 0. 5. 0 / 0. 5. 0
  libswscale 0. 7. 1 / 0. 7. 1
  libpostproc 51. 2. 0 / 51. 2. 0
  built on Oct 16 2009 23:39:29, gcc: 4.3.2
FFmpeg SVN-r19928
libavutil 50. 3. 0 / 50. 3. 0
libavcodec 52.35. 0 / 52.35. 0
libavformat 52.38. 0 / 52.38. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 0. 5. 0 / 0. 5. 0
libswscale 0. 7. 1 / 0. 7. 1
libpostproc 51. 2. 0 / 51. 2. 0

no change, still stops too early. same on completely different hardware (at least 4 years older 2800+ Sempron notebook)

Any hints where I can start searching? I am willing to try out whatever you think could be helpful, as I'd really like to help but my programming skills are pretty limited...
(0004171)
ddennedy (developer)
2009-10-18 06:04

I saw the problem you described in Kdenlive's Clip Monitor, but not melt - the MLT command line tool. Also, when I put the clip on the timeline by itself, I also saw the problem. I believe this is due to the way Kdenlive detects the end of the clip/project. I tested this hypothesis by placing another clip after your sample clip with some gap between them, and then it does play through to the end. Next, I then tested rendering the clip alone on the timeline, and the rendered output stops roughly half way between where kdenlive stop and the real end.

I will continue looking into this.
(0004195)
ddennedy (developer)
2009-10-20 05:41

The rendering side of this was fixed in MLT git commit e867729.
Next, I will look at Kdenlive, but the rendering part was more critical.
(0004221)
tbartdev (reporter)
2009-10-29 16:22

great!
i am ready to test as soon as kdenlive gets the necessary changes as well!
(0004474)
j-b-m (administrator)
2010-01-03 18:14

Seems fixed now (svn rev. 4195), please test
(0004579)
tbartdev (reporter)
2010-01-25 15:22

well... it's a lot better now, the cursor positioning seems to be more correct, but my sample video still does not play till the end.

The drummer hits the cymbal somewhere around the last frame. I can only see that in kdenlive when I
a) put another video (or a copy of the same) after it
b) deactivate Real time (drop frames) in the clip monitor, but then audio and video are not in sync

shall I do a desktop capture of how it looks like?
(0004581)
akirk (reporter)
2010-01-25 23:24
edited on: 2010-01-25 23:27

In other messages I've inquired about the 'flash' or missing frames at the end of clip/zone/project playback. I've traced it to consumer_sdl.c. this->running is set to 0 BEFORE the last frames of a clip have been displayed.
set breakpoint on 660 with the condition that this->running = 0
set a breakpoint on 793.

use this in renderer.cpp

static void consumer_frame_show(mlt_consumer, Render * self, mlt_frame frame_ptr)
{
   // detect if the producer has finished playing. Is there a better way to do it?
   if (self->m_isBlocked) return;
   Mlt::Frame frame(frame_ptr);
#ifdef Q_WS_MAC
   self->showFrame(frame);
#endif
   int i = mlt_frame_get_position(frame_ptr);
   self->emitFrameNumber(i);
   if (frame.get_double("_speed") == 0.0) {
       kDebug() << " AKAK stop: speed 0 pos: " << i;
       self->emitConsumerStopped();
   } else if (frame.get_double("_speed") < 0.0 && i <= 0) {
       kDebug() << " AKAK stop: speed < 0 pos: "<< i;
       self->pause();
       self->emitConsumerStopped();
   } else kDebug() << " AKAK pos " << i; // use this to see that the next-to-last frame or more is always dropped
}

you will see that 793 is hit and sets running=0 before the last of the queue is displayed, dumping the display loop out at line 515.

(0004622)
akirk (reporter)
2010-02-03 22:04

Is the obnoxious slotStart() call in rendererStopped put there to hide this defect? After all, when I play a clip to the end, I want it to stay there as I most likely want to look at those last few frame to see if I need to cut.....
(0004624)
j-b-m (administrator)
2010-02-03 22:51

Sorry for not replying earlier... It is still not clear for me if the problem is in MLT or in Kdenlive.

The slotStart() call was introduced because several users asked that feature (rewinding when clip played until the end).

I now just changed that (svn rev. 4288) so that the monitor stays at the last frame, but when pressing play on the last frame, clip monitor automatically rewinds to the first frame before starting to play, seems to make more sense.
(0004625)
akirk (reporter)
2010-02-03 23:06

Thanks. That is a excellent fix.
The -loss of frames- is in MLT. You cover the case that the frame is dropped because it is too late - that's ok and expected. What is happening (I think) is that when you reach the end of the file, i.e. you have queued all the frames - you then set runnning=false before all the frames have been displayed.
(0004628)
ddennedy (developer)
2010-02-03 23:45

MLT has a thread that "renders ahead" into a buffer queue. When it gets to the end of a project, the thread that feeds this thread exits its loop and sets running = false, but there are still frames in the buffer queue.
(0004629)
akirk (reporter)
2010-02-04 00:52
edited on: 2010-02-04 01:03

If I read the code correctly, when running = false you quit the output (display) loop and never use those frames.

(0004631)
akirk (reporter)
2010-02-04 01:02

j-b-m: the rewind code is causing - only occasionally a lockup in clip monitor.
Start kdenlive (with no project). Add clip. Click Play. Frame # moves to 1 but nothing is displayed. Add another clip and I think then all is ok.
(0004633)
j-b-m (administrator)
2010-02-04 11:13

akirk: the issue you described was unrelated but should be fixed now
(0004636)
ddennedy (developer)
2010-02-04 19:08

akirk, I am not ignoring you or the issue. I only have a little time, and I am finalizing something that is a lot of work. I will visit this in a couple of days. In case you are curious and reviewing the code, bear in mind that Kdenlive uses the sdl_preview consumer and the push model into encapsulated sdl_still and sdl consumers, which complicates this matter further. Thank you for your patience.
(0004639)
akirk (reporter)
2010-02-04 21:33

j-b-m: thanks.
ddennedy: Thanks for the feedback. If you can easily describe (point me to the code) of how turn on mlt logging, I'll narrow down the problem.
I do appreciate all the time you guys spend on this.
(0004651)
akirk (reporter)
2010-02-05 18:44

Subject: [Kdenlive-devel] skip_frame affecting render
...This might explain why some people are reporting the
rendered output does not have the same cuts as they put on the
timeline......
In the messages I looked at, this issue seems to me to be the problem.
-any hint on the mlt logging?
(0004653)
ddennedy (developer)
2010-02-05 19:29

re: logging
$ melt -debug ... -consumer sdl_preview

helps to grep it, for example:
$ melt -debug ... -consumer sdl_preview 2>&1 | grep deinterlace

within kdenlive, look for Mlt::Factory::init() in src/initeffects.cpp and add a call to mlt_log_set_level(MLT_LOG_VERBOSE).

Debug level is extremely verbose. Sometimes, I just use the VERBOSE level and then modify particular log calls within mlt to use verbose instead of debug.
(0004705)
akirk (reporter)
2010-02-12 02:24

Dan: consumer_sdl_preview, is switching to sdl_still (cause the speed on last frame = 0?) before mlt_deque_count( this->queue ) is empty, (or at least down to 1). I don't understand enough of this code to write a while loop to sleep and check the queue count before I: mlt_consumer_stop( this->play )
Anyway, it's the switching that's killling those frames.
Note that all this testing is with !real_time.
(0004745)
akirk (reporter)
2010-02-23 19:29

mlt commit 8a0b59985f74e39f6fe8d563bb770147e9e07f3b introduces further problems.
Before this commit my test case shows frames 0-86, skips 87&88, shows 89 (the last frame)
This commit shows 0-86, and stops. click one frame forward, it shows 88.
The longer the clip, the more frames are dropped.

This is what/where needs to be done to fix this problem (which is the OPPOSITE of dropping late video frames):

// If we aren't playing normally, then use the still (speed==0 in last frame!)
else if ( speed != 1 )
{
    if ( !mlt_consumer_is_stopped( this->play ) )
        {
            while ( this->parent.queue.count > 1 ) // HOW?
            {
                nanosleep( &tm, NULL ); (time could be < count*duration)
            }
            mlt_consumer_stop( this->play );
        }
    if ( mlt_consumer_is_stopped( this->still ) )
    {
        this->last_speed = speed;
        this->active = this->still;
        this->ignore_change = 0;
        mlt_consumer_start( this->still );
    }
    mlt_consumer_put_frame( this->active, frame );
}
(0004746)
ddennedy (developer)
2010-02-23 19:37

That commit is not intended to address this issue, and I will not revert it. If you think you have a fix for this issue, then submit a proper patch.
(0004748)
akirk (reporter)
2010-02-23 20:36

Sorry, I shoulden't have said: "introduces further problems". It does however reveal this problem perfectly: the last frames of a clip are never displayed.
The code above shows you where and (symbolically) how to fix this problem.
In addition, 'this->last_speed' is never USED. Do whatever you want with this issue, I'm done.
(0004750)
ddennedy (developer)
2010-02-24 07:05

Al, please test the MLT patch kdenlive-1207.txt
I developed the patch on OS X, but it's a little different. I will test it on a Linux system next before committing. Soliciting yours and others feedback on the patch effectiveness.
(0004752)
tbartdev (reporter)
2010-02-24 13:49

Here goes the feedback:

On Linux (in kdenlive), I am absolutely happy, works as expected.
Congratulations and thanks for your effort!
(0004753)
akirk (reporter)
2010-02-24 23:46

Dan, doesn't quite fix it, but this does, perfectly with the clips I've tested:

            else if ( speed != 1 )
            {
                mlt_position remaining = mlt_producer_get_playtime( producer ) - this->last_position;
                //mlt_log_debug( MLT_CONSUMER_SERVICE(&this->parent),"line 348 rem=%d lastp=%d eoft=%d",remaining,this->last_position,eof_threshold);
                if ( !mlt_consumer_is_stopped( this->play ) && ( remaining <= 2 || remaining > eof_threshold ) )
                     mlt_consumer_stop( this->play );
                                if ( mlt_consumer_is_stopped( this->play ) && mlt_consumer_is_stopped( this->still ) )
                 {
                    //mlt_producer producer = mlt_service_get_producer( MLT_CONSUMER_SERVICE( consumer ) );
                    //if ( producer )
                    // mlt_producer_seek( producer, this->last_position );
//cc -I../.. -Wall -fPIC -DPIC -O2 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -DUSE_SSE -DUSE_SSE2 -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -//DARCH_X86_64 -pthread `sdl-config --cflags` -c -o consumer_sdl_preview.o consumer_sdl_preview.c
//consumer_sdl_preview.c: In function ‘consumer_thread’:
//consumer_sdl_preview.c:353: warning: initialization from incompatible pointer type

                    this->last_speed = speed;
                    this->active = this->still;
                    this->ignore_change = 0;
                    mlt_properties_set_int( MLT_CONSUMER_PROPERTIES(this->still), "refresh", 1 );
                    mlt_consumer_start( this->still );
                    //mlt_frame_close( frame );
                }
                //else
                //{
                    mlt_consumer_put_frame( this->active, frame );
                //}
            }
            // Otherwise use the normal player
            else
            {
                if ( !mlt_consumer_is_stopped( this->still ) )
                    mlt_consumer_stop( this->still );
                if ( mlt_consumer_is_stopped( this->play ) )
                {
                    this->last_speed = speed;
                    this->active = this->play;
                    this->ignore_change = 25;
                    mlt_consumer_start( this->play );
                }
                mlt_consumer_put_frame( this->active, frame );
            }
Thanks, Al.
(0004754)
ddennedy (developer)
2010-02-25 01:08

Sorry, Al. I can not use what you sent because you simply reverted the patch I said I would not revert.
(0004755)
akirk (reporter)
2010-02-25 01:36

Sorry Dan. The code I reverted was code that didn't work because of the incompatible pointer type (your error). In the kdenlive-1207.txt, at the top, you corrected your erroneous
'mlt_producer producer = mlt_service_get_producer( MLT_CONSUMER_SERVICE( consumer ) )'
to the correct
mlt_producer producer = MLT_PRODUCER( mlt_service_get_producer( MLT_CONSUMER_SERVICE( consumer ) ) );
The patch that you said you wouldnt revert didnt work!!
In addition, it appears that you can't see the other changes I made in your kdenlive-1207.txt that allow it to work.
The code above does work, yours doesn't.
(0004756)
ddennedy (developer)
2010-02-25 01:49

Al, maybe you are under the impression that Kdenlive is the only app using MLT, but it is not. In fact, Kdenlive is working around a glitch in the sdl_preview consumer affecting a different application that that commit affected. That glitch can be seen by using melt ... -consumer sdl_preview at the command line and switching between paused and play states.

I had trouble reading your code because it was not in patch format. Thanks for testing, but I can not accept your code contribution. If you can tune what I did without reverting, then it would help.
(0004757)
ddennedy (developer)
2010-02-25 09:50

After some additional study I realized it would not reliably play to the end under certain runtime, frame-dropping conditions. I do appreciate your test feedback and persistence, Al, because it did cause me to analyze further.

I attached a new patch to be applied against git HEAD (kdenlive-1207-2.txt). This one encompasses some ideas you proposed earlier, Al, while still retaining the behavior I need in the commit on which you reported regression. Took a long time to make this (this time on Linux). I ran into some race conditions on certain types of actions seeking and toggling play/pause near the end of the movie, but I think it is reliable now. Needs a bit more exercise until I am confident, but it is late now.

P.S. The pointer warning is benign because a producer is a service (what mlt_service_get_producer() returns). It was essentially an implicit cast that caused a warning, and the new explicit cast makes the warning go away without any real change - C is weakly typed, after all. Hey, I am just glad to see someone else digging into the MLT code. :-)
(0004760)
akirk (reporter)
2010-02-25 20:30

Dan: I applied kdenlive-1207-2.txt. All looks good except the 25th frame is always dropped, and the display pauses briefley. ?this->ignore_change problem?
The fix for that (for me) is to back out your changes on lines 89&90 of the patch file- leave this->ignore_change=0 at that point. I'll test further and post tonight.
tx, Al
(0004761)
ddennedy (developer)
2010-02-25 20:40

Actually, I think that change to setting the ignore_change is a case of accidental cruft I left in the patch. I made that change while troubleshooting the race condition I mentioned, but it did not help it, and I did not back out that change.

Also, after I uploaded the patch here, I moved these lines:
+ if ( duration - this->last_position < 10 )
+ this->last_position = duration - 1;

to be immediately after
+ while ( ! mlt_consumer_is_stopped( this->play ) )
+ {
+ struct timespec tm = { 0, 10000000L }; // 10 ms
+ nanosleep( &tm, NULL );
+ }

This further limits the "snapping to the end." The snapping is there because frames could be dropped during normal playback near the end causing the last_position to not be updated - during real_time normal playback there is no guarantee that last few frames are actually played by the normal consumer.
(0004775)
akirk (reporter)
2010-03-03 03:51

Dan: sorry haven't got back to you, was in hospital 3 days. As of todays mlt commit, I have a major problem of the audio hanging kdenlive/melt at the end of a clip - sometimes. I think it is related to:
while ( ! mlt_consumer_is_stopped( this->play ) )
 {
 struct timespec tm = { 0, 10000000L }; // 10 ms
 nanosleep( &tm, NULL );
 }
if this code is not hit, no hang.
The hang is with a continuous audio tone, seemingly un-related to what might be the last note, but I'm unsure of that. Hope this helps.
(0004776)
ddennedy (developer)
2010-03-03 05:55

Does this hang also cause Kdenlive to no longer seek and play correctly?
(0004777)
ddennedy (developer)
2010-03-03 08:41

I reproduced the audio not stopping and fixed it.
I also fixed "I ran into some race conditions on certain types of actions seeking and toggling play/pause near the end of the movie...." This was only noticeable when using higher than default buffer and prefill values - not utilized in kdenlive - but possible on melt when I was doing some additional testing.
(0004779)
akirk (reporter)
2010-03-03 17:58

Thanks, I'll update and check here.
(It even forced me to power off..)
(0004782)
akirk (reporter)
2010-03-04 06:48

Dan. I've uploaded kdenlive_1207_al.txt. This breaks melt, but does allow kdenlive playing clips and zones of any length and position without dropping frames. It does cause a crash when closing app. I'm sure I'm doing something illegal in consumer_sdl.
The sound problem is still there. In my debugging on sound clips, I would end up (at speed=0) with the printout showing that frame[duration-1] had speed 0, but that frame[duration+1] and frame[duration+2] had already been played!!!!!
Hope this helps in any little way.
(0004784)
ddennedy (developer)
2010-03-04 21:53

What is wrong with my latest commit?
(0004812)
ddennedy (developer)
2010-03-11 23:18

Fixed in MLT 0.5.2.

Al, Re "playing clips and zones of any length and position without dropping frames"

If real_time > 0, then it drops frames by design. I now think you are trying to resolve a different problem than described in this bug. This is all I am willing to do on this bug at this time. If you can clearly describe your problem or goal, then please open a new bug with it. However, in your last comment, you provided no comment on the latest commit or a description of the problem your patch attempts to address.

- Issue History
Date Modified Username Field Change
2009-10-12 18:54 tbartdev New Issue
2009-10-12 18:54 tbartdev Build/Install Method => Other Method?
2009-10-13 06:46 ddennedy Status new => assigned
2009-10-13 06:46 ddennedy Assigned To => ddennedy
2009-10-13 06:50 ddennedy Note Added: 0004141
2009-10-13 06:50 ddennedy Status assigned => feedback
2009-10-15 17:43 tbartdev Note Added: 0004166
2009-10-17 00:02 tbartdev Note Added: 0004169
2009-10-18 06:04 ddennedy Note Added: 0004171
2009-10-20 05:41 ddennedy Note Added: 0004195
2009-10-29 16:22 tbartdev Note Added: 0004221
2010-01-03 18:14 j-b-m Note Added: 0004474
2010-01-25 15:22 tbartdev Note Added: 0004579
2010-01-25 15:22 tbartdev Status feedback => assigned
2010-01-25 23:24 akirk Note Added: 0004581
2010-01-25 23:27 akirk Note Edited: 0004581 View Revisions
2010-02-03 22:04 akirk Note Added: 0004622
2010-02-03 22:51 j-b-m Note Added: 0004624
2010-02-03 23:06 akirk Note Added: 0004625
2010-02-03 23:45 ddennedy Note Added: 0004628
2010-02-04 00:52 akirk Note Added: 0004629
2010-02-04 00:53 akirk Note Edited: 0004629 View Revisions
2010-02-04 01:02 akirk Note Added: 0004631
2010-02-04 01:03 akirk Note Edited: 0004629 View Revisions
2010-02-04 11:13 j-b-m Note Added: 0004633
2010-02-04 19:08 ddennedy Note Added: 0004636
2010-02-04 21:33 akirk Note Added: 0004639
2010-02-05 18:44 akirk Note Added: 0004651
2010-02-05 19:29 ddennedy Note Added: 0004653
2010-02-12 02:24 akirk Note Added: 0004705
2010-02-23 19:29 akirk Note Added: 0004745
2010-02-23 19:37 ddennedy Note Added: 0004746
2010-02-23 20:36 akirk Note Added: 0004748
2010-02-24 07:03 ddennedy File Added: kdenlive-1207.txt
2010-02-24 07:05 ddennedy Note Added: 0004750
2010-02-24 13:49 tbartdev Note Added: 0004752
2010-02-24 23:46 akirk Note Added: 0004753
2010-02-25 01:08 ddennedy Note Added: 0004754
2010-02-25 01:36 akirk Note Added: 0004755
2010-02-25 01:49 ddennedy Note Added: 0004756
2010-02-25 09:33 ddennedy File Added: kdenlive-1207-2.txt
2010-02-25 09:50 ddennedy Note Added: 0004757
2010-02-25 20:30 akirk Note Added: 0004760
2010-02-25 20:40 ddennedy Note Added: 0004761
2010-03-03 03:51 akirk Note Added: 0004775
2010-03-03 05:55 ddennedy Note Added: 0004776
2010-03-03 08:41 ddennedy Note Added: 0004777
2010-03-03 17:58 akirk Note Added: 0004779
2010-03-04 06:35 akirk File Added: kdenlive_1207_al.txt
2010-03-04 06:48 akirk Note Added: 0004782
2010-03-04 21:53 ddennedy Note Added: 0004784
2010-03-11 23:18 ddennedy Note Added: 0004812
2010-03-11 23:18 ddennedy Status assigned => resolved
2010-03-11 23:18 ddennedy Fixed in Version => future version
2010-03-11 23:18 ddennedy Resolution open => fixed
2010-03-30 17:05 xzhayon Fixed in Version future version => Recent git
2010-03-30 17:07 xzhayon Target Version => future version
2010-09-14 11:01 j-b-m Fixed in Version Recent git => 0.7.8
2010-09-14 23:00 j-b-m Status resolved => closed
2010-09-22 17:54 Granjow Target Version future version => 0.7.8


Copyright © 2000 - 2014 MantisBT Team
Powered by Mantis Bugtracker