Try 'which melt' instead of 'whereis mlt'. The actual melt binary might be in a separate package.

And yes, you need the 'melt' binary whenever you want to render/export a video.

Created attachment 118865 [details]
attachment-29565-0.html

Thank you that might be the problem. I tried 'which melt' and received

/usr/bin/which: no melt in
(/home/foveann/.local/bin:/home/foveann/bin:/home/foveann/.local/bin:/home/foveann/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin)

So I tried 'dnf install mlt' as root and received

Package mlt-6.12.0-5.fc29.x86_64 is already installed.
Package mlt-6.12.0-7.fc29.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

So mlt is clearly installed but is there a special path to the 'melt'
binary that I am not aware of? Sorry I'm new to this and require a bit more
hand holding.

Thanks for all your time and help!



On Sun, Mar 17, 2019 at 10:52 AM Christoph Feck <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=405564
>
> Christoph Feck <cfeck@kde.org> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |rdieter@gmail.com
>
> --- Comment #2 from Christoph Feck <cfeck@kde.org> ---
> And yes, you need the 'melt' binary whenever you want to render/export a
> video.
>
> --
> You are receiving this mail because:
> You reported the bug.

Did you try to install 'melt' in addition to 'mlt'? As I said, the binary could be in a separate package.

Created attachment 118878 [details]
attachment-22670-0.html

Yeah I was thinking of that. I tried 'dnf install melt' and received:

No match for argument: melt
Error: Unable to find a match

So I tried 'dnf update' and 'dnf upgrade' and tried it again and again
received the same 'no match argument' error.




On Sun, Mar 17, 2019 at 10:02 PM Christoph Feck <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=405564
>
> --- Comment #4 from Christoph Feck <cfeck@kde.org> ---
> Did you try to install 'melt' in addition to 'mlt'? As I said, the binary
> could
> be in a separate package.
>
> --
> You are receiving this mail because:
> You reported the bug.

It's provided as /use/bin/mlt-melt on fedora to avoid conflicts with another application of the same name, fyi

Created attachment 118886 [details]
attachment-27916-0.html

I selected that path (/usr/bin/mlt-melt) and it seemed to have accepted it.
But upon closing and opening the program again, the box prompt returned.
Same problem.

On Mon, Mar 18, 2019 at 8:55 AM Rex Dieter <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=405564
>
> --- Comment #6 from Rex Dieter <rdieter@gmail.com> ---
> It's provided as /use/bin/mlt-melt on fedora to avoid conflicts with
> another
> application of the same name, fyi
>
> --
> You are receiving this mail because:
> You reported the bug.

What's the contents of your ~/.config/kdenliverc [env] group?  Mine is:

[env]
defaultimageapp=/usr/bin/gimp
defaultprojectfolder[$e]=$HOME/Documents
ffmpegpath[$e]=/usr/bin/ffmpeg
ffplaypath[$e]=/usr/bin/ffplay
ffprobepath[$e]=/usr/bin/ffprobe
mltpath[$e]=/usr/share/mlt/profiles/
rendererpath[$e]=/usr/bin/mlt-melt

The important part is the value of rendererpath in this context.

OK, that was testing with kdenlive 18.04, after upgrading to 18.12.2, I can reproduce the failure here.  No matter what value is in kdenliverc for rendererpath, the next launch complains it cannot be found.

Upon examining the code, it does appear to assume that binary is called "melt".  Once upon a time, fedora patched the code to look for mlt-melt too, but that got dropped along the way (not sure why), but it appears that part may still be needed.

I'll work restoring that, and hope it's something that is upstreamable.

Created attachment 118906 [details]
attachment-18965-0.html

Thank you!

On Mon, Mar 18, 2019 at 11:28 PM Rex Dieter <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=405564
>
> --- Comment #10 from Rex Dieter <rdieter@gmail.com> ---
> Upon examining the code, it does appear to assume that binary is called
> "melt".
>  Once upon a time, fedora patched the code to look for mlt-melt too, but
> that
> got dropped along the way (not sure why), but it appears that part may
> still be
> needed.
>
> I'll work restoring that, and hope it's something that is upstreamable.
>
> --
> You are receiving this mail because:
> You reported the bug.

*** Bug 405622 has been marked as a duplicate of this bug. ***

*** Bug 386991 has been marked as a duplicate of this bug. ***

*** Bug 405953 has been marked as a duplicate of this bug. ***

FYI, the code in question is in mltconnection.cpp where it hard-codes looking for "mlt" only:

    QString meltPath;
    if (qEnvironmentVariableIsSet("MLT_PREFIX"))
        meltPath = qgetenv("MLT_PREFIX") + QStringLiteral("/bin/melt") + exeSuffix;
    if (!QFile::exists(meltPath)) {
        meltPath = QDir::cleanPath(profilePath + QStringLiteral("/../../../bin/melt")) + exeSuffix;
    }
    if (!QFile::exists(meltPath)) {
        meltPath = QStandardPaths::findExecutable("melt");
    }
    KdenliveSettings::setRendererpath(meltPath);

Should be fixed by commit,
https://cgit.kde.org/kdenlive.git/commit/?id=40ed4ba30ecc34a96a38a7fe768c0dc4e54e8500

I'm verifying now

If there is indeed another binary with the name 'melt', and OSS community thinks this name isn't related to the MLT framework, then maybe the code could check 'mlt-melt' first, then 'melt'. Otherwise, it could still call the wrong binary if both are installed.

Good point, indeed mlt-melt should be searched first to avoid that scenario

Is this bug related to the same issue: https://bugs.kde.org/show_bug.cgi?id=379828

Similar issue, yes

*** Bug 379828 has been marked as a duplicate of this bug. ***

Note I said similar, but not the same, not sure if it's best to treat it as a duplicate.

Background on fedora, the both binaries freeze and melt come from a package called "freeze", code from
http://www.ibiblio.org/pub/Linux/utils/compress/freeze-2.5.0.tar.gz
which predates mlt and kdenlive.  This is why mlt's binary is renamed and name-spaced on fedora to be mlt-melt to not conflict.

I'm not sure what kdenlive expects when it tries run a binary named 'freeze', but for sure, 'freeze -p' is not supported by this one.

Upgraded from Fedora 26 to 27. Still had a problem. Went back to this page and saw the comment about changing the Melt Path setting to /usr/bin/mlt-melt... and IT WORKS!

I successfully Rendered and viewed a video I made last year to .mp4.

I wish I had known what to do 2 yrs. ago. Geez.

Anyways, thanks to the developers here who helped fix this problem.

Hi folks, closing this as it seems to be a distro packaging issue. Also these days I'd recommend using Flatpaks or Appimages. Cheers.