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 <evors...@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/
