Using Kdenlive from current GIT master, when a bin clip is reloaded, the path to the kdenlive file is being appended to original clip path as will be shown in the locate clips dialog upon reopening the saved project. Upon reopening the saved project, the saved files are not found due to the extra appended path from the kdenlive file, and the locate clips dialog comes up. This is GIT master only, does not occur on 16.08.2. Todays test was kdenlive from master as of 11-1-2016 though yesterdays tests with git master from 10-31-2016 also did this. MLT from GIT master as of 10-31-2016, Movit is enabled (Movit is current as of yesterday). OS is Debian Unstable current as of 10-21-2016. To duplicate, build and install kdenlive from current (as of 11-1-2016) git master. Start kdenlive and drop some video clips into the bin. Optionally put one on the timeline so it will be easier to make a tiny change and save the project. It does not matter whether you save it to the same directory containing the clips or not. Close and reopen the project, it should open OK. Now reload one clip, as is necessary right now with movit to get the thumbnail to appear in the bin.Change anything on the timeline and save the project. Close the project and try to reopen it. The reloaded clip is not found, and the dialog for finding the clip shows the path to the saved kdenlive file appended to the path of the clip, even if they are in the same directory. The find clips dialog does work and the project can then be opened, but would be impractical on a project containing archived clips from dozens of different directories. If no clips are reloaded, projects open fine. Would expect this when reopening a project in which clips had been reloaded as well. Probably from the "First steps towards "portable" projects (using relative paths)" portion of https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=8996c30e56b5ff6126adf828fdd7681320a5f7af and appears both before and after https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=d56831ea499f82c4e604d2b39aa855781c66b9ee "Use relative path in .mlt files created by clip jobs"
Git commit 1d1595e7d14ef6b0560dc93940f9c23ed96a4ce7 by Jean-Baptiste Mardelle. Committed on 02/11/2016 at 08:32. Pushed by mardelle into branch 'master'. Fix various regressions introduced with project folder change M +0 -1 src/doc/documentchecker.cpp M +4 -1 src/doc/kdenlivedoc.cpp M +1 -1 src/kdenlivesettings.kcfg M +2 -8 src/project/dialogs/projectsettings.cpp M +1 -1 src/project/projectmanager.cpp M +5 -1 src/ui/configproject_ui.ui M +39 -72 src/ui/projectsettings_ui.ui http://commits.kde.org/kdenlive/1d1595e7d14ef6b0560dc93940f9c23ed96a4ce7
https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=1d1595e7d14ef6b0560dc93940f9c23ed96a4ce7 did not fix this in my tests. Files used were in different directories than the .kdenlive file, did not test same directory but that made no difference before.
I cannot reproduce your problem. Can you go in Kdenlive Settings > Project Defaults, and make sure "custom project folder" is unchecked ? Restart Kdenlive and try to reproduce. If bug is still here, can you attach the project file here and let me know the original path of the source video clip ?
I made sure that "custom project folder" was unchecked, still got problems if any clip had been reloaded (and ONLY if a clip had been reloaded). If no clips are reloaded the projects open fine. Attaching two kdenlive project files: one before and one after reloading a clip. In the first file (clip not reloaded) the clip path is /home/luke/VIDEO/ZZ_Scratch/TEST/FILE0008.MOV In the second file (clip reloaded prior to save) the path comes up as VIDEO/ZZ_Scratch/TEST/FILE0008.MOV Meaning we now have a different problem. Instead of appending the path to the project file to the path (as before) it is now stripping part of the path to the clip.
Created attachment 102021 [details] Kdenlive file after first fix, clip not reloaded This is a valid file on my desktop and my system and opens fine because no clips have been reloaded
Created attachment 102022 [details] Kdenlive file after first fix, clip reloaded This file was saved after reloading a clip, part of the path to that clip has been stripped and the clip must be found again to load the file.
Git commit 41565402d462e0853241e822f51d056f12f6634a by Jean-Baptiste Mardelle. Committed on 04/11/2016 at 10:02. Pushed by mardelle into branch 'master'. Fix path corruption on clip reload M +1 -0 src/bin/bin.cpp M +4 -7 src/mltcontroller/bincontroller.cpp M +3 -2 src/renderer.cpp M +2 -0 src/timeline/clip.cpp http://commits.kde.org/kdenlive/41565402d462e0853241e822f51d056f12f6634a
Thanks for the project files. I was able to reproduce and bug should be fixed now. It is normal to have stripped paths in the project file. Mlt's xml format specs has a "root" property in the top level element that defines a base path, all paths in the file are then relative to that root. In some conditions, Kdenlive mixed different "root", resulting in that corruption