I have found a corruption in the Bin.

1- Add a Color Clip
2- Add a Title Clip
3- Corruption: The Color Clip becomes the Text Clip and the Text Clip name changes to Text and you can't edit nor select it.

When adding an SVG this also happens.

A video is worth a thousand words.

Hi

Using latest kdenlive from refactoring_timeline, when I try to add a JPEG file to the project bin, I get a crash with the following backtrace:
https://paste.kde.org/phutyhwd7

I tried with 17.08.2 (using MLT from git master) and with the appimage snapshot and they both work. By doing a git bisect, I traced the problem to be inside this commit:
[20407bdaf7876c4082258adc289d92b485cd5bdd] Huge cleanup of clip creation and jobs

I tried to track down the differences for the thumbnail generation but that commit changes it a lot, so I am not entirely sure what is causing the problem.
One difference I noticed is that before that commit, KThumb::getFrame() was being called without forceRescale, so I changed that in the code and it does fix the crash, but the thumbnail is not generated correctly anyway, so I think there might be some more changes affecting this behavior.

I've got some spare time for the next week, so I would like to help fixing this (and also try to help with the other blockers) so if you guys can give me any hint on what I could try to debug this properly, I would really appreciate.

Hi,

I'm probably the one to blame for both issues there :)

So now the architecture looks like that right know. When you add a clip:

• A placeholder is created in the bin, with the correct QModelIndex, but no thumbnail (basically the producer is not loaded, so the item is not usable). It should be greyed out at that point
• Asynchronously, a job responsible for loading the producer is run. When it finishes, the producer is associated to the corresponding bin item, and the item becomes usable. Note that at this point, we still don't have any thumbnail.
• Finally, several jobs are run concurrently on the clip to finish loading. For eg. thumbs and audiothumbs. The crash @boiko describes happens during this phase (a thumb job)

So I probably made a mistake while factoring out the thumbnail creation part. It used to be computed within the ProjectClip class (which reimplemented its own job management, and that was a mess). So I guess the easiest way is to see how the getFrame used to be called from within that function and correct the code in ThumbJob accordingly.

As for @afarid problem, it looks like an index problem. Can you confirm which version you are using Farid ? git or AppImage ?

I am using the AppImage Alpha5 which JB provided. Gonna see if I can get an AUR package of the refactoring so I can help debugging some bugs since I found a crash undoing.

Thanks @boiko for your help and welcome to the team. <3

So, any hints on where/what/how I could debug that? I can certainly dig the code myself, but any pointers on exactly what could have caused it would speed things up :)

Thanks

Oh, looking at your log, it seems you have activated movit, the GPU accel library.
When working with movit and creating thumbnaily, we should not use the original bin producer that has several movit related filters attached.
If you look at line 75 in thumbjob.cpp, you can see:
m_prod = m_binClip->originalProducer();

This has to be changed when movit is enabled, using a cloned producer.
We should probably update ProjectClip::thumbProducer() and use it instead of originalProducer() in that thumbjob.cpp line mentionned above.

ProjectClip::thumbProducer() should simlpy be updated to return a std::shared_ptr<Mlt::Producer> instead of a pointer. THat should do the trick.

Let me know if you need more infos/help.

Bingo!

Changing it to use the thumbProducer did the trick, thanks for the hint.
I have sent a phabricator differential, but bear with me as it is my first time using phabricator :)

https://phabricator.kde.org/D8808

Here is the archive that valgrind produced after testing some actions in the bin like selecting and moving the arrows up and down, as well as jkl and playback.