#193 handling file names ending in a space


As described at http://www.kdenlive.org/mantis/view.php?id=3017 when kdenlive executes a render when one of the input files has a name ending with a space then melt creates a file with "invalid clip" as the output. JBM thinks this is due to melt
He mentions
producer_xml.c line 546:

char *resource = trim( mlt_properties_get( properties, "resource" ) );

So I am guessing that melt trims of the spaces from the file name and then can not find the file resouces later on. Mlt should not bomb out on file names ending in space.


  • Dan Dennedy

    Dan Dennedy - 2013-04-02

    Hmm, this was added to fix a bug. The commit message is:
    [PATCH] add trimming whitespace to some xml values (debian-651604)

    Upon investigating that old Debian bug, some people (OpenShot in this case) generate or author XML with superficial whitespace between open and closing tags, and that was the reason for the trimming. It might be time to revert that change and require people to do XML correctly, but I should if something as popular as OpenShot still does this before making a change that will cause a whole lot of grief.

  • Dan Dennedy

    Dan Dennedy - 2013-04-03

    Fixed in git commit 6d651e6. I removed the trim call for all resource and src properties. I also tested a 2011 version of OpenShot, and it no longer appears to produce the problem, which resulted in the commit introducing the code.

  • Dan Dennedy

    Dan Dennedy - 2013-04-03
    • status: open --> pending
  • ttguy

    ttguy - 2013-04-03

    Thanks Dan. I will eventually test this when this change makes it to sunabs ppa.

  • ttguy

    ttguy - 2013-04-12

    Tested this in daily build kdenlive-ubuntu11.10-x86-20130411.tar.bz2 and confirm that this issue is fixed. Thanks

  • Dan Dennedy

    Dan Dennedy - 2013-06-20
    • status: pending --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks