[kdenlive] R: Re: Copying Kdenlive projects and Preview Rendering

Mon Jun 20 14:21:39 UTC 2016

Hi evrybody,
I didn't analyze this problem before because I guessed that the preview rendering feature was not yet complete.
So I believe that before was important to find a way to automatically delete the files and to have the option to select the drive and the path where to place them. Actually I always used different drives for assets, for cache and for rendering files as suggested in all video editor applications user manuals.
My workaround, for deleting rendering files I need no more, is to disable and enable again the clip I want to render again which didn't modify the rendering result. Then I perform a new rendering action. By this way everything works.
Now, I just tried to emulate the exact same situation Harald described but my experience is a little bit different: if I copy the project and I take 2 different versions of it,  the rendering stays in place if the projects are not changed or if I open and close always the same project.
But if I change something in one of the 2 projects, every time I shift from one project to the other, I always lose my rendered zones in both projects.
Actually, I don't understand how on my computer things are working in a different way than on Harald's pc. Probably, I cloned the project by the save-as menu and Harald done it in a different way.
Anyway, I think that projects haven't to share the same rendering files. I believe that each project, even the copies, must have different IDs. Probably, the correct way is to copy the original rendered files in a new folder with the new ID, when a person create the new project or save and old one with a new name.
So I believe that the save as feature, as Harald suggested has to change the ID of the project.
Another workaround could be to use the library for creating a virtual clip of the part you have to duplicate in different projects. Then you can create each time a new project and then import the virtual clip. One the virtual clip is on the timeline you can expand it and modify what you have to. This time when you perform the render action I guess you'll haven't any issues.

Massimo.

----Messaggio originale----
Da: harald.albrecht at gmx.net
Data: 20-giu-2016 16.03
A: "jb"<jb at kdenlive.org>, "Kdenlive"<kdenlive at kde.org>
Ogg: Re: [kdenlive] Copying Kdenlive projects and Preview Rendering

Hi Jean-Baptiste,

good to hear your perspective, as it is very similar to what I tried to 
analyze. I agree that a totally automatic mechanism isn't possible, so I 
see two ways to handle cloning (both may be actually coexisting):

1. cloning from inside Kdenlive as part of the "Save as..." operation. 
In this case I would (hopefully) correctly assume that we should then 
automatically update the document ID as part of a Save-as operation. I 
don't think that we would need an option for this in the save-as dialog, 
but I may be wrong. :)

Adding a clone option in addition to save as has the potential to create 
confusion. While writing this post I asked myself several times whether 
clone creates an independent project, while save-as does not ... or 
would it be the other way round? So I think that keeping save-as is the 
proper way to proceed from here.

2. cloning outside Kdenlive (using a file manager, etc). In case we 
detect that either the location or name of the project has changed 
outside Kdenlive's control then we could ask the user whether the 
project is going to be a new, independing project. With a third "I don't 
understand" that would default to changing the document ID to be on the 
safe side, which wouldn't hurt users anyway.

Option 1. is hopefully a simple thing to do and would be needed anyway. 
Option 2 could act as some safeguard but has also the potential to 
create confusion with inexperienced users as the relocation dialog did 
already in the past. Don't get me wrong: the relocation dialog is fine 
and absolutely required. It's just that the don't-care type of users 
will click it away without thinking, as we've seen in the past several time.

Best regards,
Harald

Am 20.06.2016 um 12:26 schrieb jb:
> Le 20.06.16 à 12:14, Harald Albrecht a écrit :
>> Hi,
>>
>> just want to ask here before filing a bug report: just started work 
>> on two new Kdenlive projects. For convenience, I cloned the first 
>> project in an early stage to be used as the starting point for the 
>> second project. And then I noticed something concerning preview 
>> rendering...
>>
>> 1. While working on the first project, I preview rendered the first 
>> few seconds consisting of the titling for this episode #23. So far, 
>> so good.
>>
>> 2. Then worked on the second project and replaced the title for this 
>> separate episode #24. Now, the fun starts: when preview rendering the 
>> same zone for the titling, Kdenlive happily picked up the preview 
>> rendering from episode #23, which I can clearly see as preview now 
>> uses the wrong titling.
>>
>> So, this brings me to my question: does the document identity 
>> correctly change when I copy a project?
>>
>
> Good question! I also thought about it and have not found a solution yet.
> The project id is created when the document is first created and 
> consists of a timestamp.
> This timestamp is then used to create a temporary folder in 
> $HOME/.cache/kdenlive, and the audio/video thumbnails and preview 
> files are stored in this folder.
>
> This way, the project file can be renamed / moved without losing the 
> temporary data. However if you create a copy of the project (either to 
> try a different edit or to start a new project based on the current 
> one), the document id is not changed, so the same temporary folder is 
> used, leading to potential conflicts of preview files (but on the 
> other hand it can be nice to have the audio/video thumbs already 
> created).
>
> I cannot think of a way to automatically handle this...
>
> Maybe we could introduce a "clone" feature that would set a new 
> document id and copy temp data to that new folder ?
>
> Any idea/comment is welcome.
>
> jb
>
>> Best regards,
>> Harald
>>
>> PS: As always, doing actual projects on the bleeding edge...
>
> _______________________________________________
> kdenlive mailing list
> kdenlive at kde.org
> https://mail.kde.org/mailman/listinfo/kdenlive

_______________________________________________
kdenlive mailing list
kdenlive at kde.org
https://mail.kde.org/mailman/listinfo/kdenlive

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20160620/39c58e96/attachment.html>