[kdenlive] [Bug 460688] New: Crash: when going back in history/undo ctrl+z (after Time Remapping)
https://bugs.kde.org/show_bug.cgi?id=460688 Bug ID: 460688 Summary: Crash: when going back in history/undo ctrl+z (after Time Remapping) Classification: Applications Product: kdenlive Version: 22.08.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Crashes when trying to revert changes after "Time Remapping" alias Speed Ramp. STEPS TO REPRODUCE [0. Load existing profile.] 1. Apply speed ramp to clip 2. Make some time changes 3. De-select clip and undo changes via CTRL+Z OBSERVED RESULT Problem signature: Problem Event Name: APPCRASH Application Name: kdenlive.exe Application Version: 0.0.0.0 Application Timestamp: Fault Module Name:libmlt++-7.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Code: c005 Exception Offset: 939b OS Version: 6.1.7601.2.1.0.256.48 Locale ID:1031 Additional Information 1: d99f Additional Information 2: d99fe4f86dd04d2d5b3aec01d3dc19f1 Additional Information 3: ea16 Additional Information 4: ea16c338e91f971974e5362c820ef98e EXPECTERED RESULT When the very first recorded history/state of the project is reached do nothing even if I though I continue to press CTRL+Z. SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION Have the impression that kdenlive tried to go "before" the very first state like "state -1" since I think I already saw the very first state reemerging in the timeline right before the crash while hitting multiple times CTRL+Z. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 460690] New: Time Remapping: general thoughts/critic UI/UX
https://bugs.kde.org/show_bug.cgi?id=460690 Bug ID: 460690 Summary: Time Remapping: general thoughts/critic UI/UX Classification: Applications Product: kdenlive Version: 22.08.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY I'll try to keep it short (and skip also the natural appreciation part for all your work, which I do but...): I find the UI of the "Time Remapping" alias Speed Ramp ***EXTREMLY*** not only un-intuitive (bad UX) but even limiting in (possible) functionality . STEPS TO REPRODUCE Try to figure out "Time Remap" without a tutorial -- without being the dev/creator of the UI/UX (Off-Topic but doesn't enhance the situation: while at the same time it's constantly crashing on you, see #437113). Really, I mean it. Put your uninformed uncle/cousin/whoever in front of this, tell him: here is this new feature in kdenlive, please make me this: https://youtu.be/W1SbGOl9YEc?t=308) OBSERVED RESULT A) Under specific circumstances extends the clip (probably it's a feature but regarding UX completely unexpected and unintended) B) With a lot of "ramps" granularity/accuracy gets lost due to weird scaling of the "Time-Ramp"-UI B2) Under certain circumstances cannot click handles in the """graph""" due to overlapping/aids of the UI C) Not even sure if this is intended but you can even reverse time. -- Not anytime soon I would have realised that! (Though the feature at all integrated here really sounds great.) [2] EXPECTED RESULT A graph where I could even have control over the kind/speed/slope of the ramp/function (not only "please magically cramp 2 minutes into 1 minute for me") ADDITIONAL INFORMATION Maybe I'm just ignored but can the master mind behind the UI please explain the benefits of the current "fancy" UI over a regular graph/function which "everybody", I would claim, with a descent educational background would expect and could grasp in an instant. AGAIN: I really appreciate your work and *even* a new/different approach over the "classic" one but only if it brings benefits. The documentation for this feature is a one-liner which literally just and only states: "The new Time Remap feature allows to keyframe the speed of a clip."[1] (Since then a whole *major* release has passed.) [1] https://docs.kdenlive.org/de/effects_and_compositions/effects.html#time-remapping-speed-ramps [2] https://youtu.be/weY57YFPD-g?t=222 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 444597] New: Ccrash: select (second?) template in title clip
https://bugs.kde.org/show_bug.cgi?id=444597 Bug ID: 444597 Summary: Ccrash: select (second?) template in title clip Product: kdenlive Version: 21.08.2 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Crashes when selecting template "simple.kdenlivetitle" after "simple-width-date.kdenlivetitle" (a.k.a. changed my mind) in the Title Clip dialog. STEPS TO REPRODUCE 1. Magic step before -- see additional info. 2. Click add title clip 3. Select Template "simple-width-date.kdenlivetitle" 4. Change your mind and select "simple.kdenlivetitle" OBSERVED RESULT Problem signature: Problem Event Name: APPCRASH Application Name: kdenlive.exe Application Version: 0.0.0.0 Application Timestamp: Fault Module Name:kdenlive.exe Fault Module Version: 0.0.0.0 Fault Module Timestamp: Exception Code: c005 Exception Offset: 003c5c2f SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION Cannot reproduced reliable. (Though I only tried once.) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 444406] Kdenlive crashes when clicking Download new title templates
https://bugs.kde.org/show_bug.cgi?id=06 Veps changed: What|Removed |Added Keywords||reproducible CC||v...@gmx.de --- Comment #1 from Veps --- I can confirm that for Windows 7 too. SOFTWARE/OS VERSIONS Windows: 7 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 444597] Crash: select/change template in title clip
https://bugs.kde.org/show_bug.cgi?id=444597 Veps changed: What|Removed |Added Summary|Ccrash: select (second?)|Crash: select/change |template in title clip |template in title clip -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 435206] Title clips become green and enlarged, see attachment.
https://bugs.kde.org/show_bug.cgi?id=435206 Veps changed: What|Removed |Added CC||v...@gmx.de --- Comment #2 from Veps --- General speaking: I can confirm this issue! SOFTWARE KDEnlive: 21.08.2 OS: Windows 7 Renderer: h265/mp4 (hevc) ADDITIONAL INFORMATION Though I have the exact same issue in my project however I cannot reproduce it with this project file of the reporter *Phuoc*. (Not with h264 nor with h265 which I use for my project.) However I think the problem is the temporal overlap of at least two titles on two tracks maybe related to a partial fade in/out on the overlapping portion of the titles. Apparently there is more to the story otherwise I would be able to reproduce it BUT the overlap is clealy the primary cause since removing the overlap works around the problem. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #9 from Veps --- Not sure where I could upload the example file more permanently. Most (free) services delete after 30 days. Guess the easiest solution would be if some maintainer/dev grabs it and just fixes the issue. *hint* ;-) Re-upload 2021-11-06: https://1fichier.com/?aygs1zmchwsmkfv4uc8k https://ufile.io/imsjjbbm https://anonfiles.com/p85cbcT7ub/change-speed-issue-first-minute_7z -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] New: "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 Bug ID: 437112 Summary: "Change speed" cripples clip in/out boundaries. Product: kdenlive Version: 21.04.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Bug also already existed in 21.03.x. STEPS TO REPRODUCE 1. Open mkv file (source OBS) a) File has multiple audio tracks -- shouldn't matter but I have the strong impression that there are multiple other bugs related to that fact. So just FYI. 2. Shorten the clip at the end. 3. "Change speed" -- no difference due to execution: opt 1.) Hold Control-key and drag the clip border to slow the clip down. opt 2.) Right click the clip and select `Change Speed`. OBSERVED RESULT 1. Not sure about the correct wording but I would call it the video(-crop) is heavily "moved" inside the clip boundaries. Meaning: the unchangeable beginning of the clip which should be at the same time also 0:00 of the inherent video is suddenly 4:00 of the video without the possibility to extend the clip boundary (to the left) to the 0:00 mark of the video again. The clip is "convinced" that it is already at the very possible beginning of the video inside the clip even though it is *not*. 2. Clip previews stay the same. (There is/was a similar bug which claims to fixed that -- it's not.) 3. The time areas of the clip which "lost" video footage due to the heavy move of the video (to the "left") are rendered white. Example for clarification: * Video-1 = length 7:00 (m:s) * Clip-1 = cropped to 6:00 (with portion 0:00-6:00 of Video-1 inside) * After `Change Speed` applied to Clip-1 of now lets say 6:20 of length (because its slowed down = longer) starts the video suddenly at 5:00 and after 2.xx minutes runs out of footage since the original Video-1 only held 7 minutes of footage. So Clip-1 renders at mark 2:xx only white. 4. Movement of the video footage inside a clip appears random to me so far. EXPECTED RESULT obvious SOFTWARE/OS VERSIONS Windows: 7 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION * Sound does *not* seem to be effected. * Appears to me the same issue as this 5 years old bug: https://bugs.kde.org/show_bug.cgi?id=348148 * ..and this 6 years old "retired" bug: https://bugs.kde.org/show_bug.cgi?id=355003 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437113] New: Status bar text (right side) has wrong spacing (horizontally cut off)
https://bugs.kde.org/show_bug.cgi?id=437113 Bug ID: 437113 Summary: Status bar text (right side) has wrong spacing (horizontally cut off) Product: kdenlive Version: 21.04.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: v...@gmx.de Target Milestone: --- Created attachment 138429 --> https://bugs.kde.org/attachment.cgi?id=138429&action=edit Status bar text cuts off horizontally. STEPS TO REPRODUCE 1. Install 21.04.0 2. Hover mouse in the timeline over a clip. OBSERVED RESULT See attached picture. EXPECTED RESULT Readable text. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437113] Status bar text (right side) has wrong spacing (horizontally cut off)
https://bugs.kde.org/show_bug.cgi?id=437113 Veps changed: What|Removed |Added Flags||low_hanging+ -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 421718] Uninstallation Problem
https://bugs.kde.org/show_bug.cgi?id=421718 --- Comment #7 from Veps --- And also... * KDEnlive: v20.12.3 * OS: Windows 7 Pro x64 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 460876] New: Too many [sic!] history entries (for CTRL+Z) when moving via mouse
https://bugs.kde.org/show_bug.cgi?id=460876 Bug ID: 460876 Summary: Too many [sic!] history entries (for CTRL+Z) when moving via mouse Classification: Applications Product: kdenlive Version: 22.08.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Using for example the effect "Motion Tracker" and moving the red box for the position via mouse in the Project Monitor, almost every mouse position -- without letting the mouse button go and actually placing the box -- will create a history entry to go back to though the new location was never accepted by letting the mouse button go. STEPS TO REPRODUCE 1. Add Motion Tracker effect (didn't try but I assume and almost hope (buzzword OOP) every effect with a box for positioning) 2. Add a time keyframe for keyframing the effect 3. Click and hold the box and move it arround 4. Let mouse go to finally "accept" the new postion 5. Now go back in history via CTRL+Z OBSERVED RESULT "Millions" of history entries for the position of the box/keyframe. EXPECTED RESULT One entry. SOFTWARE/OS VERSIONS Windows: 7 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 460876] Too many [sic!] history entries (for CTRL+Z) when changing box-location via mouse
https://bugs.kde.org/show_bug.cgi?id=460876 Veps changed: What|Removed |Added Summary|Too many [sic!] history |Too many [sic!] history |entries (for CTRL+Z) when |entries (for CTRL+Z) when |moving via mouse|changing box-location via ||mouse -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 459554] Audio Spectrum Filter doesn't keyframe any parameter
https://bugs.kde.org/show_bug.cgi?id=459554 Veps changed: What|Removed |Added CC||v...@gmx.de --- Comment #2 from Veps --- I just quickly checked on the comment on your git merge request: > jlskuz commented 26 days ago > this affects audiolevelgraph, audiosprectrum and audiowaveform Will this effect the possibility for opacity as well? I was about to open a bug report but just realized from the supplied screenshot here that the "Audio Spectrum Filter" doesn't show "opacity" while the "Audio Level Visualization Filter" (that's what meant by audiolevelgraph?) actually does -- seems crooked to me! However I would very much appreciate if this would also support opacity-levels though... :) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461215] New: At least multiple "Transform" effects and "Position and Zoom" (but I guess more) overwrite each other
https://bugs.kde.org/show_bug.cgi?id=461215 Bug ID: 461215 Summary: At least multiple "Transform" effects and "Position and Zoom" (but I guess more) overwrite each other Classification: Applications Product: kdenlive Version: 22.08.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Same properties of multiple effects and even compositions overwrite each other. STEPS TO REPRODUCE 1. Add "Transform" effect to a clip (maybe add keyframes) and change change X-position value 2. Add another "Transform" or "Position and Zoom" (maybe add keyframes) and change X -position here too Example: Lets say effect/compostion A alters X value to 1 and effect/composition B alters """same"""* X value to 2 [* so apparently it is literally the "same" value although it shouldn't be just the same type of value.] OBSERVED RESULT Final X value of the clip will be 2 (=last value). It renders the ability of stacking the same effect on the same clip useless -- and even cross-effects other effects like: "Position and Zoom" "Transform" "Compose and Transform" ***BUT*** weirdly not "Zoom Pan" for example. EXPECTED RESULT Final X value of clip *should* be 3 (additive value) -- or explained in a more graphical/figurative way: effect B should change the location of the resulting clip after effect A got applied. SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION >From a user perspective it is even effecting properties you didn't touch (though I'm aware it doesn't make a difference programmatically). However if you change in the "first" effect also the "Size" value but not in the second effect, it will be re-set as well. However changing X and leaving Y (= setting it to 0 indirectly) in the second effect has *no* impact confusingly. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461215] At least multiple "Transform" and "Position and Zoom" effects (but assumingly more effects) overwrite each other
https://bugs.kde.org/show_bug.cgi?id=461215 Veps changed: What|Removed |Added Summary|At least multiple |At least multiple |"Transform" effects and |"Transform" and "Position |"Position and Zoom" (but I |and Zoom" effects (but |guess more) overwrite each |assumingly more effects) |other |overwrite each other -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461219] New: The pattern/lines overlay of the project monitor can be misaligned if clip changes while zoomed in
https://bugs.kde.org/show_bug.cgi?id=461219 Bug ID: 461219 Summary: The pattern/lines overlay of the project monitor can be misaligned if clip changes while zoomed in Classification: Applications Product: kdenlive Version: 22.08.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Topic -- which here is weirdly labeled "summary" too -- says it all. STEPS TO REPRODUCE 1. Add two clips to the time line 2. Scrub into one 3. Turn some Overlay in the Project Monitor on 4. Zoom in 5. Move viewport into some direction (so that the center of the clip is not displayed in the center of the viewport anymore) 4. Switch to the second clip (Maybe it's already enough to click out of the clip and click inside the same again.) OBSERVED RESULT Overlay gets aligned to the viewport of the window, means for example that a center crosshair is in the center of the window/viewport. EXPECTED RESULT Overlay should be aligned with the frame of the clip, meaning if the the viewport of the Project Monitor is moved aside so should be the overlay. (Center of Frame != center of viewport.) SOFTWARE/OS VERSIONS Windows: 7 PERSONAL COMMENT Makes alignment a horror and leads to HEAVY confusion. With the level/stage of "complexity" kdenlive reached I would go so far and call it a basic function. Meaning: I would like to bump severity to at least "major" though programmatical its not critical obviously. However, guess it should be an easy fix ... right? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 451844] The Edge Crop effect does not work as a master or on the entire track.
https://bugs.kde.org/show_bug.cgi?id=451844 Veps changed: What|Removed |Added CC||v...@gmx.de --- Comment #1 from Veps --- > Adding (...) - does not work. I guess this is just an unfortunate phrasing , so you mean the effect has no effect? At least *adding* to master or track works for me. Nevertheless the effect produced no effect in those cases also for me ADDITION Edge Crop also doesn't produce any effect on mlt-clips. OPERATING SYSTEM Windows 7 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 451844] The Edge Crop effect doesn't work on the master, the entire track or MLT-clips
https://bugs.kde.org/show_bug.cgi?id=451844 Veps changed: What|Removed |Added Summary|The Edge Crop effect does |The Edge Crop effect |not work as a master or on |doesn't work on the master, |the entire track. |the entire track or ||MLT-clips -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 451844] The Edge Crop effect doesn't work on the master, the entire track or MLT-clips
https://bugs.kde.org/show_bug.cgi?id=451844 Veps changed: What|Removed |Added Version|21.12.3 |22.08.1 --- Comment #2 from Veps --- PS: Changed title of bug report accordingly. Shall I also bump Version? I'm on v 22.08.1 already. Same problem plus my addition. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461372] New: Average Blur X/Y size -- X broken (easy-fix)
https://bugs.kde.org/show_bug.cgi?id=461372 Bug ID: 461372 Summary: Average Blur X/Y size -- X broken (easy-fix) Classification: Applications Product: kdenlive Version: unspecified Platform: Other OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: v...@gmx.de Target Milestone: --- STEPS TO REPRODUCE 1. Add effect 2. Set X Size value OBSERVED RESULT Blurs X and Y axis. EXPECTED RESULT Blur only X axis (as lke as "Y Size" does). SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION Decide if you wanna capitalise property names or not: "X Size" vs "Y size" (see different cap. in "size") -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461372] Average Blur X/Y size -- X broken (easy-fix)
https://bugs.kde.org/show_bug.cgi?id=461372 Veps changed: What|Removed |Added Version|unspecified |22.08.1 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461388] New: Alpha Shape effects don't stack (overwrite each other)
https://bugs.kde.org/show_bug.cgi?id=461388 Bug ID: 461388 Summary: Alpha Shape effects don't stack (overwrite each other) Classification: Applications Product: kdenlive Version: 22.08.1 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: v...@gmx.de Target Milestone: --- SUMMARY Adding two (or more) "Alpha Shape" effects to a clip will overwrite each other so just the last effect effects the clip. STEPS TO REPRODUCE 1. Stack two videos on the timeline 2. Blur top clip for example 3. Add two "Alpha Shape" effects to the top one OBSERVED RESULT Only last one gets applied. EXPECTED RESULT Both should be effect the video, otherwise there is not reason for an effects stack (adding multple/same effects). SOFTWARE/OS VERSIONS Windows: 7 ADDITIONAL INFORMATION This seems pretty obviously related to https://bugs.kde.org/show_bug.cgi?id=461215 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461215] At least multiple "Transform" and "Position and Zoom" effects (but assumingly more effects) overwrite each other
https://bugs.kde.org/show_bug.cgi?id=461215 --- Comment #1 from Veps --- Seems related/"same" bug as in https://bugs.kde.org/show_bug.cgi?id=461388 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #2 from Veps --- (In reply to emohr from comment #1) > I see "a lot of bugs" with OBS clips. Would it be possible to upload a test > clip so I could test? Okay, I found a file that is reasonable small and I could reproduce it pretty easily with that file. I stretched the file to about 96% speed et voilà: https://anonfiles.com/96ybQcw5u4/2021-05-16_040444.mkv_zip -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #4 from Veps --- (In reply to emohr from comment #3) > Can you check with the nightly build if you have the same behavior? I've tested with Nightly 21.07.70 (kdenlive-master-769-windows-mingw_64-gcc) and the answer is: yes and no. Yes, for the particular file I've uploaded this seems to fix the issue but for the file I'm actually working with I would call it a clear regression. Not only it does not fix the issue (for my real file) but also just loading the file onto the timeline brings exactly the same issue I've described initially: the clip starts at about 30 s into the Video -- with out further do! Before that I could observe that the little loading bar below the file after you drag the file into the project window loads multiple times to 100% -- which I didn't observe on 20.04.xx. I would say it only should load one time to 100% as it did in the old version. But to be fair I'm not even sure if this is the version which is supposed to fix the issue. kde/kdenlive is all over the place: issue system here on bugs.kde.org, then a gitlab isntance on invent.kde.org with another issue tracker and finally even (a clone?) on github.com. Than I can/could find "Daily builds" somewhere (miss the link atm) as well as "Nightly builds" from a Jenkins instance. Please point me to the correct file and preferable please link the corresponding chnage/diff on github/gitlab if possible. I will try to reproduce the the same error in a smaller file. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #6 from Veps --- That's the first minute of the file that produces the shift in the video of an clip after speed change: 1. Drag file onto project window. 2. Accept project setting change. 2.1. Already noticed that ending thumbnail is white. 3. Drag file onto timeline. 4. Change speed of the file to 98% via Ctrl+pulledge (right edge). Though the impact seems to be smaller -- probably due to the shorter video/clip but it is still noticeable due to the de-sync in audio or actually in the video since the audio stays correct. (You can here the 5 peeps before the game starts and the "woosh" of the menues that fly out of screen even though the frames are "cut out".) File about 60 mb: https://anonfiles.com/J3BcL9xbud/change-speed-issue-first-minute_7z -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 437112] "Change speed" cripples clip in/out boundaries.
https://bugs.kde.org/show_bug.cgi?id=437112 --- Comment #7 from Veps --- @emohr: Why did you mark this backport? What am I supposed to understand under backport here anyway? You can only port this back (or be back ported) if you would maintain multiple versions which I guess kdenlive does not. I've test release 21.04.1 with my supplied (last) test file[1] and in contrast to the nightly/daily build instead of the video the audio graph is off-sync without further do. (Don't confuse with the audio itself which *is* in sync.) This is probably related to the fact that it seems there are about 5 seconds missing in the timeline of the 60 s of video. Okay I just for clarification: * The video is registered as exactly 60 s long in the project folder. (That's also how I cut it for the upload with ffmpeg. * If I drop it onto the timeline the clip is about 58 s long. * When I play/preview it the last frame get stuck at about 54.xx seconds then there is only "empty clip" with the stuck frame left. (This is without speed change.) Still you can simply break the video/clip further on the timeline by cutting of the clip at the end and change the speed by ctrl+drag to for example 98%. So the clip starts about 30 seconds into the expected video. The rest of the clip which misses video footage is rendered white as "usual". If you wanna flag it for somehting, flag it "timeline_curruption" because that's what it is clearly, isn't it? -- a clip with broken footage on the timeline. [1] https://anonfiles.com/J3BcL9xbud/change-speed-issue-first-minute_7z -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 421718] Uninstallation Problem
https://bugs.kde.org/show_bug.cgi?id=421718 Veps changed: What|Removed |Added CC||v...@gmx.de --- Comment #5 from Veps --- (In reply to emohr from comment #1) > In Windows we have still the problem that the "dbus-deamon.exe" gets not > killed after closing Kdenlive. > > 2 possibilities: > - restart the PC and the de-installer should work or > - goto task manager (CTRL+Shift+esc) and kill "dbus-deamon.exe" and the > de-installer should work. First of all, I can confirm this bug for: KDEnlive v20.12.2 on Windows 7 Pro x64 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 421718] Uninstallation Problem
https://bugs.kde.org/show_bug.cgi?id=421718
--- Comment #6 from Veps ---
(In reply to emohr from comment #1)
> In Windows we have still the problem that the "dbus-deamon.exe" gets not
> killed after closing Kdenlive.
>
> 2 possibilities:
> - restart the PC and the de-installer should work or
> - goto task manager (CTRL+Shift+esc) and kill "dbus-deamon.exe" and the
> de-installer should work.
First of all, I can still confirm this bug for:
* KDEnlive: v20.12.2
* OS: Windows 7 Pro x64
FURTHERMORE
* The problem is not solved by restarting! (Was my first thought too but well
-- no.)
* Run "./kdenlive/uninstall.exe" as Administrator does not solve the problem
too -- what is what you would expect considering the error message. (Just FYI.)
* "dbus-deamon.exe" is, as far as I can tell, not running ("Task manager ->
Show process from all users"). Maybe there is another process blocking? Though
I'm not sure about the internals of MS Windows but I would expect the binary to
get loaded into memory hence I would expect the binary to be deletable from the
hard disk though it is currently running/executed.
Memory or not, I can easily (with Admin rights) rename the
"kdenlive/bin/dbus-deamon.exe" to somehting else, nevertheless still no
un-installation is performed.
MORE FUNNY
However I wonder why "README.md" and "LICENSE.txt" are mared as "read-only"
files!?
It gets even more funny when you remove the attribute from the two files, run
`dir /ar /s` in console/cmd.exe in the local folder and get no results BUT the
Windows Explorer still shows under properties for the folder "./kdenlive" a
check for "Read-only (Only applies to files in the folder)". Also at this point
un-install.exe still does not work.
HERE IT GETS CREEPY
Un-checking "Read-only" in the Windows Explorer properties dialog, say okay to
"Apply changes to this folder, subfolders and files", Windows runs through all
the files assumingly and then you get out of the property window and back in
and read-only is again/still checked.
--
You are receiving this mail because:
You are watching all bug changes.
[systemsettings] [Bug 372555] Input Device - Mouse - Reverse scroll direction Not Working
https://bugs.kde.org/show_bug.cgi?id=372555 Veps changed: What|Removed |Added CC||v...@gmx.de --- Comment #14 from Veps --- Plasma: 5.8.6 Framework: 5.28.0 Qt: 5.7.1 Bug still present. Checkbox in System Settings->Hardware->Input Devices->Mouse has no effect: checked or unchecked, no difference. -- You are receiving this mail because: You are watching all bug changes.
