Kdenlive corruption and rendering crashes

[Vincent Pinon]

Hello Eric,

First, many thanks for your involvement and efforts to make Kdenlive 
always more robust!

Regarding render crash, I had ideas for a long time that I never put in 
place...

We are supposed to hold the log from melt process and show it up upon 
any problem,
but I'm not sure it is true all the time, and I wanted to better advise 
bug reporters to share this log.
I also thinked of increasing melt verbosity level to get more 
information from this log.

Also, I wanted to extract the timecode at which melt crashes, to give 
this feedback to the user,
and maybe offer the users to scroll the timeline to that position so 
that they can check
if there are weird clip/effect/transition to tweak here.

Moreover, we can get crash stacktrace on Linux for kdenlive thanks to 
KCrash/DrKonqi,
on Windows we had DrMingw that we had to disable for years
(Craft was held on buggy mingw-gcc-9, now gcc is upgraded we can enable 
it back).
But melt doesn't have any crash handler linked,
we could submit a PR to MLT to add an option to link to KCrash/DrMingw,
or any better options (embed a simple signal handler dumping stacktrace?).

But most users don't run programs with debug symbols,
so we must understand how to make the trace informative later on ?
I have seen fedora's ABRT system automatically getting debug symbols to 
generate bug report,
I don't know if this can be generalized through KCrash or any other,
or if it's a task not too difficult on the developers side?

I'm sorry I never found time to learn how to do this and apply these ideas,
maybe you are ready to dig into this direction?

That's all for now, hope this helps!

BR,

Vincent

Le 17/07/2022 à 07:16, Eric Jiang a écrit :
> On Sat, Jul 16, 2022 at 7:25 PM Evert Vorster <evorster at gmail.com> wrote:
>> Honestly, it's been a long time since I have seen either error.
>> Is it still affecting you today? The thing about the internet is that sometimes old posts show problems that have long been resolved.
> For rendering crashes, bug #456689 is the latest and was reported on
> 22.04.2.[0] There are other bugs with a similar symptom, and seems to
> be mainly a Windows problem.[1]
>
> More generally, this feels like part of a bigger category of issues
> where we have buggy dependencies without end-to-end testing to catch
> them (e.g. otio, KF5 Purposes, ffmpeg). Ideally users should feel
> confident in upgrading to a new Kdenlive version.
>
> For timeline corruption, the most recent report I found was on Reddit,
> regarding 22.04.3.[2] I personally am still using 21.12.3, but don't
> remember if I experienced corruption with 21.12.x or 21.08.x. It may
> only happen to a small % of saves, but it's a very destructive bug.
>
> Personally, I think Kdenlive has a good set of features already, but
> there are opportunities to greatly increase its stability. Open to
> ideas and opinions!
>
> Eric
>
> [0] https://bugs.kde.org/show_bug.cgi?id=456689
> [1] https://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=NEEDSINFO&bug_status=VERIFIED&columnlist=component%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cbug_severity%2Creporter%2Cop_sys%2Crep_platform&list_id=2115425&longdesc=mp4%20timestamp&longdesc_type=allwordssubstr&product=kdenlive&query_format=advanced
> [2] https://www.reddit.com/r/kdenlive/comments/vwsk82/error_when_opening_kdenlive_and_gone_project/