I've installed 4:15.08.0+git20150908.0238+15.04-0 from the Kubuntu-CI ppa. In this Kdenlive version I cannot properly reposition the playhead in the timeline. I've loaded a project, trying to edit it. A. clicking on a new position in the timeline moves the blue mark atop of frame ruler in the timeline. But it does not move the white playhead. When I press play, then most of the time playing starts from the blue mark, repositioning the playhead. B. using the keyboard to move the playhead doesn't work. Neither cursor keys nor Home/End etc. I can see the blue mark moving according to the keyboard commands, but the white playhead doesn't move. C. Albeit my ShuttlePro v2 is properly detected and I have setup all keys, Kdenlive does not recognise it when I use the ShuttlePro. Jog/shuttle/buttons show no effect.
Compiled recent kdenlive git repo (master) and gave it a try: problems still exist.
I've managed to narrow the problem: when the number of MLT threads is set to one, then the playhead acts correctly most of the time. With 3 MLT threads, the playhead does not correctly reposition. In addition, I've now noticed that single frame stepping doesn't work either using the cursor keys or the ShuttlePRO v2 dial with 3 MLT threads, but it starts working as expected with only a single thread. However, from time to time, even with only a single MLT thread there are playhead errors; I could imagine that the problem is not with MLT but with the way Kdenlive interacts with a multithread-enabled MLT lib. Also, the playhead problem were not present in Kdenlive 15.04, but appeared around 15.08/15.09.
kdenlive 15.09.0+git20150921 MLT 0.9.9+git20150921.a5290952-0ubuntu0~sunab~vivid1 I can confirm this occurs with kubuntu 15.04 on above version. play-head can initially be moved as normal when project is first opened then has the problems described. reducing mlt threads to 1 play-head seems to work ok and keyboard shortcuts also start working again
*** Bug 354808 has been marked as a duplicate of this bug. ***
got sometime the same playhead problem does not reposition . i think that should come from codec stuff .... ? Description : Whatever i do with the timeline cursor _black arrow_ (from project monitor or from the project timeline) , the "project monitor" preview will always move forward in the clip. Until the end, and then impossible to going backward in the clip. version 15.04.2 / KDE Frameworks 5.9.0 / melt 0.9.6 / Xubuntu 15.04 / avconv version 11.2-6:11.2-1 (MLT Thread have never be other than 1) Typically something not working with this kind of clip : avprobe version 11.2-6:11.2-1, Copyright (c) 2007-2014 the Libav developers built on Jan 18 2015 05:12:33 with gcc 4.9.2 (Ubuntu 4.9.2-10ubuntu2) Input #0, avi, from '00305.MTS.avi': Metadata: encoder : Lavf56.1.0 Duration: 00:04:58.00, start: 0.000000, bitrate: 24983 kb/s Stream #0.0: Video: mjpeg, yuvj422p, 800x600 [PAR 4:3 DAR 16:9], 50 fps, 50 tbn Stream #0.1: Audio: mp3, 48000 Hz, 2 channels, s16p, 128 kb/s # avprobe output same without sound , no working avprobe version 11.2-6:11.2-1, Copyright (c) 2007-2014 the Libav developers built on Jan 18 2015 05:12:33 with gcc 4.9.2 (Ubuntu 4.9.2-10ubuntu2) [avi @ 0x189e900] non-interleaved AVI Input #0, avi, from '00305.MTSNOSOUND.avi': Metadata: encoder : Lavf56.1.0 Duration: 00:04:57.96, start: 0.000000, bitrate: 24851 kb/s Stream #0.0: Video: mjpeg, yuvj422p, 800x600 [PAR 4:3 DAR 16:9], 50 fps, 50 tbn # avprobe output this one always working : avprobe built on Jan 18 2015 05:12:33 with gcc 4.9.2 (Ubuntu 4.9.2-10ubuntu2) Input #0, avi, from 'Bubbles__Slow__013.mp4.avi': Metadata: encoder : Lavf56.1.0 Duration: 00:02:56.04, start: 0.000000, bitrate: 3494 kb/s Stream #0.0: Video: mjpeg, yuvj422p, 800x600, 25 fps, 25 tbn # avprobe output does the problem could come from the [PAR 4:3 DAR 16:9] ?
*** Bug 356185 has been marked as a duplicate of this bug. ***
Given that this bug now has at least two duplicate bugs posted, I'd say it's pretty safe to say it can be marked as confirmed...
(In reply to Kubuntiac from comment #6) > *** Bug 356185 has been marked as a duplicate of this bug. *** i do'nt think it is the same problem in two reports.
I'm the reporter of 356185 and the description in this bug, as well as the workaround (changing MLT threads from 3 to 1) match my experience precisely. What suggests that they're different issues?
Issue is still present with recent git master on fast machines, such as core i7's. Updating the bug tittle to correctly reflect the cause of this issue.
I confirm this issue in OpenSuSE of several versions. Having MLT 6.0.2 and KDE 4.14.18 over OpenSuSE Leap 42.1-x64, Kdenlive presents this problem on versions: 15.12.3, 16.04.1 and Kdenlive5 v16.04.1. This I checked on a MackBookPro as well as on a box AMD/Nvidia with 6 cores of 3Ghz. see: https://forum.kde.org/viewtopic.php?f=265&t=133096&p=357706#p357706 I also confirm that returning Threads to 1, solves the issue.
I observe the same (or very similar) problem with kdenlive 16.08 on Ubuntu 16.04 (installed from the ppa:kdenlive/kdenlive-stable). Clicking the timeline twice in a row at *very* close points locks up more often than not.
Created attachment 100726 [details] backtrace of all threads
The bug is relatively easy to reproduce, see https://youtu.be/YlbYchCCn8k P.S.: I can share those clips and the project file.
I can confirm this behaviour on Kdenlive version 17.04.0 using Melt 6.4.1 on Arch Linux. When melt threads are 2, the playhead acts weird but works okay after switching to 1.
I'm noting this happens on my machine too (arch linux kdenlive 18.04.1 mlt 6.8.0 on intel i7-6500U), and the workaround of reducing MLT thread count to 1 works. I'm also noting that I can't step through individual frames with right or left keyboard buttons when I have >1 thread, but I can with only 1 thread. I suspect this is related to this issue. I'm also noting that on demanding multi-track videos, that with >1 thread I notice that pressing spacebar to initiate playback will result in playback playing like half a second and then restarting playback a few times (similar to how a CD player would loop when stuck on a bad disc). However on the same video with only 1 thread, the playback won't experience that multiple false start looping problem, but will instead simply take a little bit longer to get rolling. I'm thinking while this might be related to the issue of the playhead not working properly...(maybe the multiple threads send conflicting information about the progress of processing of the start frame, which confuses the playhead cursor). I can't find this issue in the issue tracker...so I'm mentioning it here cause I think might be the same underlying issue.
It seems that this report is related to very old unmaintained version. A lot changed since then, especially the timeline got a complete rewrite and it is likely that this has been fixed. Feel free to reopen this bug or create a new report if this is still happening with the latest version (https://kdenlive.org/en/download/)