Maybe this is common knowledge, or is mentioned in the documentation. I have not checked.
In July 2014 I created a small video. I lost the resulting mp4 file. No problem I thought, I have the projectfile archived as a tar.gz.

After unpacking it OUTSIDE kdenlive, using Xarchive ,everything seems and sounds fine. No missing files, runs inside the projectfile.
Also renders new mp4, BUT that file does not play. Says "Invalid" no matter what player is used. What the f---??

But unpacking it INSIDE kdenlive, well, there I have again my mp4 that also plays.

Conclusion: Unpacking should be done by kdenlive

Best regards

Unpacking outside Kdenlive does work; I've moved and reorganized several projects. I even internally reorganized the file structures of several complex Kdenlive projects outside Kdenlive, without any problems.

The key to understand here is when loading the Kdenlive project for the first time after unpacking, moving, or reorganization is to pay attention to the dialog shown when Kdenlive cannot find project files. Simply pressing "Okay" here will take you to your project, but all missing/inaccessible clips will be replaced with "INVALID". From what you wrote, this is what you seemed to have done.

Instead, when the Kdenlive dialog comes up, click on "Search recursively". Then locate the a suitable near folder, such as the new folder where you unpacked your Kdenlive archive. All clips referenced in your project that could now be found will have their status icon turn from alert to check. Sometimes you'll see a speech bubble instead, you can count this as checked/found. You can repeat the search recursively process as many times you like until you've resolved all missing clips. Only then click Okay and you'll have access to all your clips in your project. Save the project in case you intend to work with it in the future.

TheDiveO wrote:Unpacking outside Kdenlive does work; I've moved and reorganized several projects. I even internally reorganized the file structures of several complex Kdenlive projects outside Kdenlive, without any problems.

The key to understand here is when loading the Kdenlive project for the first time after unpacking, moving, or reorganization is to pay attention to the dialog shown when Kdenlive cannot find project files. Simply pressing "Okay" here will take you to your project, but all missing/inaccessible clips will be replaced with "INVALID". From what you wrote, this is what you seemed to have done.

Instead, when the Kdenlive dialog comes up, click on "Search recursively". Then locate the a suitable near folder, such as the new folder where you unpacked your Kdenlive archive. All clips referenced in your project that could now be found will have their status icon turn from alert to check. Sometimes you'll see a speech bubble instead, you can count this as checked/found. You can repeat the search recursively process as many times you like until you've resolved all missing clips. Only then click Okay and you'll have access to all your clips in your project. Save the project in case you intend to work with it in the future.

Thanks for your answer. But this was not what I wrote. The "Invalid" did not come during the upstart of the kdenlive project. Inside there, everything was normal. Nor was any error reported during the rendering. This ugly INVALID sign was not seen until later, when trying to play the resulting mp4 (or an mkv) in four different players.
Players used was mplayer, Gnome mplayer, VLC and gthumb.

The start up messages you are referring to, I am familiar with. Also how to solve them which has happened earlier, when I have reorganized structures etc, on my drives, But this was not the case here.

To be sure I did not miss anything, I have repeated the process several times. Same problem. Unpacked outside gives an error when playing the rendered movie(not before!) , unpacked inside kdenlive everything works fine!

To summarize, I have got my short video back again and I have no problem any longer with unpacking the archive from inside kdenlive.
But from Xarchiver I had problems.

Do you get the same INVALID sign in the final output as you would otherwise see when using a reorganized/moved Kdenlive project? Or is this rather an "invalid" message that looks differently with each playback device?

If it is the first one, that is, the rendered video consists of valid video frames, but they show INVALID, then this indicates that the rendering process (that is MLT) cannot access the files correctly. This looks as if the MLT environment is different from Kdenlive's. I have to admit that so far I never saw such a situation.

Is there anything "special" about your file system or directory structure?
Do you run rendering from a script (possibly still inside Kdenlive) or do you render directly from within Kdenlive (without intermediate script)?
In case you rendered from script (albeit possibly still inside Kdenlive), did you recreate the rendering script after unpacking and before rendering?

There is actually an important difference between Kdenlive 0.9.x and the new 15.x series:

• formerly, a Kdenlive 0.9.x project file unfortunately did contain some pieces of information twice; on the Kdenlive level and again on the MLT level, as Kdenlive project files are basically MLT XML files with Kdenlive data tacked on. The inherent danger in this design is that having the same information twice in different places can cause them to become out-of-sync over time. And this may be the root cause while your project when played in Kdenlive may give a different result compared to rendering. So, yes, in Kdenlive 0.9.x unpacking from within Kdenlive may avoid such out-of-sync situations.
• An important change in Kdenlive 15.x is that this dangerous duplication of information has been wiped out. Kdenlive now stores a certain piece of information only once in its project files. This makes moving and reorganizing projects much more robust. And this is what I had in mind, as I'm working with Kdenlive 15.x for almost a year now. This redesign of the Kdenlive project file information model has proved for me to be the best thing done: no more strange effects when the Kdenlive timeline gets out of sync with MLT's rendering model. You should be able to safely unpack your Kdenlive 15.x projects from outside Kdenlive. That's what I'm doing all the time. I even messed around with the project file XML on purpose to trigger a request for a recursive search when I reorganized existing projects to use some shared media resources. Kdenlive 15.x proved to work correctly even under such adverse conditions; a real workhorse.

Thank for engaging in this matter!

TheDiveO wrote:Do you get the same INVALID sign in the final output as you would otherwise see when using a reorganized/moved Kdenlive project? Or is this rather an "invalid" message that looks differently with each playback device?

Code: Select all

To me this "Invalid" sign looks the same as the one, somtimes seen in Kdenlive, i.e when clips are missing and is also the same in the different players,

If it is the first one, that is, the rendered video consists of valid video frames, but they show INVALID, then this indicates that the rendering process (that is MLT) cannot access the files correctly. This looks as if the MLT environment is different from Kdenlive's. I have to admit that so far I never saw such a situation.

Code: Select all

But the rendering does not produce any errors! Should not an errormessage has been produced during rendering, or the rendering had crashed then?

Is there anything "special" about your file system or directory structure?

Code: Select all

Well, yes, I suppose it is.
I have a pc built according to my spec that has 3 internal drives. All mechanical. My motherboard is UEFI based and on all drives I use the GPT partition model.
So Linux talking I have sda, sdb and sdc.

On the "main", sda (or C:), I dual boot, using rEFInd, Win7 and Arch Linux which works well.
Sda is partioned as:
sda1 /boot/efi Fat32
sda2  "Microsoft reserved partition" unknown fs,
sda3  "Basic Data partition", ntfs
sda4  /  ext3
sda5 /boot ext3
sda6 /var ext4
sda7 /home ext4


Code: Select all

sdb and sdc, are used for editing and storage of pictures and videos. As they both are 2TB they are partioned into halfs. The material for Kdenlive editing  and the project files exists on [b]sdb1[/b]. The archives, and the output on [b]sdc1.[/b]  I do not use any kind of RAID. This archive we now are discussing, is on [b]sdc1[/b], When I reproduced my tests Kdenlive managed to produce the video even when I forced it to do it on the same disk, [b]sdc1[/b] as where the archived file was. It also produced the video when I let kdenlive do it under my [b]/home[/b].  But here is another issue, when doing the unpacking, even if the wanted map exists or not, or if i tell Kdenlive to create a new map, it says the map could not be created. Anyway, after closing this error message, the projekt is found where I wanted it, although those errors.

Do you run rendering from a script (possibly still inside Kdenlive) or do you render directly from within Kdenlive (without intermediate script)?

No, I do not use scripts here, neither inside Kdenlive or outside. I render directly from Kdenlive.
Once again, thanks for taking your time,

TheDiveO wrote:There is actually an important difference between Kdenlive 0.9.x and the new 15.x series:

• formerly, a Kdenlive 0.9.x project file unfortunately did contain some pieces of information twice; on the Kdenlive level and again on the MLT level, as Kdenlive project files are basically MLT XML files with Kdenlive data tacked on. The inherent danger in this design is that having the same information twice in different places can cause them to become out-of-sync over time. And this may be the root cause while your project when played in Kdenlive may give a different result compared to rendering. So, yes, in Kdenlive 0.9.x unpacking from within Kdenlive may avoid such out-of-sync situations.
• An important change in Kdenlive 15.x is that this dangerous duplication of information has been wiped out. Kdenlive now stores a certain piece of information only once in its project files. This makes moving and reorganizing projects much more robust. And this is what I had in mind, as I'm working with Kdenlive 15.x for almost a year now. This redesign of the Kdenlive project file information model has proved for me to be the best thing done: no more strange effects when the Kdenlive timeline gets out of sync with MLT's rendering model. You should be able to safely unpack your Kdenlive 15.x projects from outside Kdenlive. That's what I'm doing all the time. I even messed around with the project file XML on purpose to trigger a request for a recursive search when I reorganized existing projects to use some shared media resources. Kdenlive 15.x proved to work correctly even under such adverse conditions; a real workhorse.

The version I use "today" is 15.12.2. and I use Arch Linux. What version of Kdenlive that was used in 2014 when I archived that project, I do not recall. Not diving into details, but I think, that Kdenlive has bvecome more mature.

Very early on I used it in the xfce4 environment because I liked the simplicity of that compared with Kde as a full installation. But I had to start using Kde 5 and Plasma as this never version did not allow to set background colors on etc, on the clipinfos in the timeline. All was white(?) or at least - undreadable and such settings were said to be done in Kde. Which I by that time did not use.

In 2014 this was most probably 0.9.x. The transition of Kdenlive to KDE Frameworks hasn't barely started then.

Did you mean that you are upgrading 0.9.x projects to 15.x projects? So this may trigger previously unseen upgrade bugs when the project isn't yet correctly in place...