--- quote ---
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.
--- unquote ---
I like this idea as I see many rendering issues coming from FFMPEG
incompatible clips or the user enables "Parallel Processing" in the
render settings for which some effects are not capable.
Eugen
Am 17.07.2022 um 15:08 schrieb 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 <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/
