[kdenlive] [Bug 377075] transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 lukefromdc <directact...@hushmail.com> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from lukefromdc <directact...@hushmail.com> --- FIXED Fixed by https://cgit.kde.org/kdenlive.git/commit/?id=cbb224784f1effd7d2b37afd7513de4f1dd634aa checkboxes now display properly, I can finally update the version I use from 16.12 all the way back to current GIT master as I normally prefer to work with. Yes, I always keep older versions around to deal with new bugs -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 377075] transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 --- Comment #5 from lukefromdc <directact...@hushmail.com> --- 9bb0e6100d1c5eae737cf4e39aa6cebfb05e4ad1 cannot be automatically reverted due to conflicts, this might be beyond my ability to fix myself -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 377075] transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 --- Comment #4 from lukefromdc <directact...@hushmail.com> --- I managed to bisect this, 9bb0e6100d1c5eae737cf4e39aa6cebfb05e4ad1 "Add base class to boolParam" came up as the first bad commit. Transitions worked normally on a build from previous commit 10abf7711ea600bd6be418b576c1044bbf0cc96d -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 366571] Kdenlive git master w/ movit: video playback corruption after end of CPU transition
https://bugs.kde.org/show_bug.cgi?id=366571 --- Comment #2 from lukefromdc <directact...@hushmail.com> --- Original behavior of the bug seems to be back with a git master build from 3-12-2017. Not sure what happened on 3.7, maybe something got corrupted and I just needed to reboot? I've seen that happen before with Kdenlive. Movit noise once again appearing only after a CPU transition (non-GLSL) between clips containing at least one CPU effect. If all the effects ever got ported to Movit this would be no longer an issue due to the CPU effect requrement to invoke it -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 377075] transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 --- Comment #3 from lukefromdc <directact...@hushmail.com> --- Further testing with git master from 3-12-2017 showed the bottom checkbox on a "wipe" transition not having its checked state saved in the GUI, but being correctly applied at playback or render so long as it has been checked and unchecked (or unchecked and rechecked) at least once each. Top checkbox works as expected, bottom checkbox actually seems to save its state to the project but not be properly re-read by the GUI when the transition is selected a second time as or 3-12.2017. This is touchy but actually usable with a bit of fiddling, though one error with a transition will cause me to re-render the project if it gets that far -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 366571] Kdenlive git master w/ movit: video playback corruption after end of CPU transition
https://bugs.kde.org/show_bug.cgi?id=366571 --- Comment #1 from lukefromdc <directact...@hushmail.com> --- As of 3-7-2017, movit noise now appears instead of the expected playback at all times (not just after transitions) unless the project is created using the June 2016 or earlier project file format. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 377075] transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 --- Comment #2 from lukefromdc <directact...@hushmail.com> --- On 3-7, some commit, probably this one: https://cgit.kde.org/kdenlive.git/commit/?id=35af0b4af89a6b92c33217f191dc55fa4d5cbb4d Partially fixed this. On the "dissolve" transition with its single checkbox for "reverse," the checkbox selection is now correctly saved and correctly applied. On the "wipe" transition with two checkboxes however, the top checkbox for "invert" now works, but the bottom one for "revert" still returns to the default settiog. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 377075] transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 --- Comment #1 from lukefromdc <directact...@hushmail.com> --- All these tests are with movit enabled if that makes any difference. MLT from current git master caused kdenlive to crash on adding transitions or resizing clips, presuming this a problem in MLT. Thus no retest with current MLT master possible right now. This was true with new build around MLT from 3-1-2017 pull, with either Nov 22 or current Movit. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 377075] New: transition checkboxes do not save checked state
https://bugs.kde.org/show_bug.cgi?id=377075 Bug ID: 377075 Summary: transition checkboxes do not save checked state Product: kdenlive Version: git-master Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: directact...@hushmail.com Target Milestone: --- checkboxes for "reverse" and "invert" in transitions do not work in current GIT master (anything recent, just confirmed with a 3-1-2017 pull). The default settings on first setting up a transition are "sane defaults" that work, but the checkboxes "remember" these defaults rather than applying and saving any changes. In other words, if the "reverse transition" box is checked by default for a transition to a lower track, one would expect that unchecking it would make the transition run back to the upper (previous)track and that this state would be saved. Instead, the change is not applied, and if the transition is deselected and selected again on the timeline, the checkbox will be back in its original default state: checked if it was checked by default, unchecked if it was not checked by default. Any user changes will be gone. Thus, it is not possible to do things like a "reverse clock" transition or use anything but the default settings until this is fixed. To duplicate this, build and install kdenlive from git master (now 17.03.70) and open kdenlive. Add two clips to the project and put them both on the timeline with an overlap. Create a transition. Now select that transition and try to edit the direction. The "wipe" transition will show two checkboxes, "dissolve" will show one. The settings are a sane default and usually OK. Check an unchecked checkbox or uncheck a checked on. Select anything else on the timeline, then select the same transition again. You will see that your change has not been saved. Using kdenlive from GIT master over MLT 6.5.0 build from Nov 22, 2016. That's a bit old so will try a current build and report that result -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371965] git master: path to kdenlive file appended to original clip path on reloading clip
https://bugs.kde.org/show_bug.cgi?id=371965 --- Comment #6 from lukefromdc <directact...@hushmail.com> --- Created attachment 102022 --> https://bugs.kde.org/attachment.cgi?id=102022=edit Kdenlive file after first fix, clip reloaded This file was saved after reloading a clip, part of the path to that clip has been stripped and the clip must be found again to load the file. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371965] git master: path to kdenlive file appended to original clip path on reloading clip
https://bugs.kde.org/show_bug.cgi?id=371965 --- Comment #5 from lukefromdc <directact...@hushmail.com> --- Created attachment 102021 --> https://bugs.kde.org/attachment.cgi?id=102021=edit Kdenlive file after first fix, clip not reloaded This is a valid file on my desktop and my system and opens fine because no clips have been reloaded -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371965] git master: path to kdenlive file appended to original clip path on reloading clip
https://bugs.kde.org/show_bug.cgi?id=371965 --- Comment #4 from lukefromdc <directact...@hushmail.com> --- I made sure that "custom project folder" was unchecked, still got problems if any clip had been reloaded (and ONLY if a clip had been reloaded). If no clips are reloaded the projects open fine. Attaching two kdenlive project files: one before and one after reloading a clip. In the first file (clip not reloaded) the clip path is /home/luke/VIDEO/ZZ_Scratch/TEST/FILE0008.MOV In the second file (clip reloaded prior to save) the path comes up as VIDEO/ZZ_Scratch/TEST/FILE0008.MOV Meaning we now have a different problem. Instead of appending the path to the project file to the path (as before) it is now stripping part of the path to the clip. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371965] git master: path to kdenlive file appended to original clip path on reloading clip
https://bugs.kde.org/show_bug.cgi?id=371965 --- Comment #2 from lukefromdc <directact...@hushmail.com> --- https://quickgit.kde.org/?p=kdenlive.git=commit=1d1595e7d14ef6b0560dc93940f9c23ed96a4ce7 did not fix this in my tests. Files used were in different directories than the .kdenlive file, did not test same directory but that made no difference before. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371965] New: git master: path to kdenlive file appended to original clip path on reloading clip
https://bugs.kde.org/show_bug.cgi?id=371965 Bug ID: 371965 Summary: git master: path to kdenlive file appended to original clip path on reloading clip Product: kdenlive Version: git-master Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: directact...@hushmail.com Target Milestone: --- Using Kdenlive from current GIT master, when a bin clip is reloaded, the path to the kdenlive file is being appended to original clip path as will be shown in the locate clips dialog upon reopening the saved project. Upon reopening the saved project, the saved files are not found due to the extra appended path from the kdenlive file, and the locate clips dialog comes up. This is GIT master only, does not occur on 16.08.2. Todays test was kdenlive from master as of 11-1-2016 though yesterdays tests with git master from 10-31-2016 also did this. MLT from GIT master as of 10-31-2016, Movit is enabled (Movit is current as of yesterday). OS is Debian Unstable current as of 10-21-2016. To duplicate, build and install kdenlive from current (as of 11-1-2016) git master. Start kdenlive and drop some video clips into the bin. Optionally put one on the timeline so it will be easier to make a tiny change and save the project. It does not matter whether you save it to the same directory containing the clips or not. Close and reopen the project, it should open OK. Now reload one clip, as is necessary right now with movit to get the thumbnail to appear in the bin.Change anything on the timeline and save the project. Close the project and try to reopen it. The reloaded clip is not found, and the dialog for finding the clip shows the path to the saved kdenlive file appended to the path of the clip, even if they are in the same directory. The find clips dialog does work and the project can then be opened, but would be impractical on a project containing archived clips from dozens of different directories. If no clips are reloaded, projects open fine. Would expect this when reopening a project in which clips had been reloaded as well. Probably from the "First steps towards "portable" projects (using relative paths)" portion of https://quickgit.kde.org/?p=kdenlive.git=commit=8996c30e56b5ff6126adf828fdd7681320a5f7af and appears both before and after https://quickgit.kde.org/?p=kdenlive.git=commit=d56831ea499f82c4e604d2b39aa855781c66b9ee "Use relative path in .mlt files created by clip jobs" -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371926] No monitor image when idling if Movit in use
https://bugs.kde.org/show_bug.cgi?id=371926 --- Comment #6 from lukefromdc <directact...@hushmail.com> --- I just tested your fix and can confirm it works. Sometimes movit noise(image corruption) will show for about a second on first opening the timeline monitor but it clears very quickly and the image then shows. Rarely it will appear for a second on moving the playhead but not very often. Always when this occurs it clears and the image comes up. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371926] No monitor image when idling if Movit in use
https://bugs.kde.org/show_bug.cgi?id=371926 lukefromdc <directact...@hushmail.com> changed: What|Removed |Added CC||directact...@hushmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371926] No monitor image when idling if Movit in use
https://bugs.kde.org/show_bug.cgi?id=371926 --- Comment #3 from lukefromdc <directact...@hushmail.com> --- Bisecting master between the good and bad build quickly found that 68e89f48be0ec2fe1767a6ea050fa87fb9b441c5 was indeed the problem. When I initially reverted it manually I did not notice it changed two files, seeing only the glwidget.cpp changes and reverting those (and cherrypicking them for 16.08) with no effect. Had to revert all of the changes to renderer.cpp or I got an unresponsive playhead in a quick test. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371926] No monitor image when idling if Movit in use
https://bugs.kde.org/show_bug.cgi?id=371926 --- Comment #2 from lukefromdc <directact...@hushmail.com> --- Created attachment 101940 --> https://bugs.kde.org/attachment.cgi?id=101940=edit patch for renderer.cpp Partially reverts https://quickgit.kde.org/?p=kdenlive.git=commit=68e89f48be0ec2fe1767a6ea050fa87fb9b441c5 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371926] No monitor image when idling if Movit in use
https://bugs.kde.org/show_bug.cgi?id=371926 --- Comment #1 from lukefromdc <directact...@hushmail.com> --- On further testing, applying ALL of the git master commits between my last good and my first bad build of master to 16.08.2 did not cause a grey screen issue, so some interaction with the commits unique to master by one of these seems to be necessary -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 371926] New: No monitor image when idling if Movit in use
https://bugs.kde.org/show_bug.cgi?id=371926 Bug ID: 371926 Summary: No monitor image when idling if Movit in use Product: kdenlive Version: git-master Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: directact...@hushmail.com Target Milestone: --- Using Kdenlive build from GIT master (post Oct 10 2016),with Movit enabled, when Kdenlive opens a project and anytime the timeline indicator (playhead) is set to a new location, the monitor shows no image, just the default grey background. Same in clip and project monitor. If Movit is not enabled, the monitor shows the image at the point the playhead is positioned when at idle, and on opening a project shows a clip. Enable Movit, get the grey monitor at idle. This problem does not exist in Kdenlive 16.08.2, only git master with the refactoring work. To duplicate, build kdenlive from master and install it, then start it and enable Movit. Put a video clip on the timeline and let it thumbnail. No image Move the playhead and the monitor returns to blank grey. Put the clip on the timeline and set the monitor to "project." No image appears in monitor. Play the clip, this works normally. Move the playhead, the image blanks and the monitor returns to grey. Again-this is only with movit enabled and does not occur without it. An Oct 10 Kdenlive build with c71731d4919def0ebbffe31cf79d965eaa8cf320 (attempt to fix QOffscreenSurface thread crash) as the last commit did not have this issue. My next build had 9fcbba8bf03c918efce49ae3160ce23f8a085a18 (Improve some effect names, capitalize first letter, patch by alcinos) as the last commit and has the monitor grey screen idle problem, as do all since then. Reverting 68e89f48be0ec2fe1767a6ea050fa87fb9b441c5 (Fix CPU usage when idle) did not fix this, and cherrypicking it and applying it to 16.08.2 did not cause this or any other problems. It was a suspect but can't do this by itself it seems. If I applied both that one and commit 55f3848ceba2d80a43694bb2ca7522e315d2fb01 (Add proper UI for lut3d effect (avfilter), patch by alcinos) to 16.08 I did get the grey monitor. Seemed OK with either one of these but not both but that was not heavily tested. Changing effect names (the last commit on the first bad build) does not seem a likely cause. This problems occurs with MLT from git master as of Oct 31,2016 and with older version. Using current Movit from GIT master downloaded August 23, no new commits to Movit since then. All of this on Debian Unstable current as of Oct 21. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 366571] New: Kdenlive git master w/ movit: video playback corruption after end of CPU transition
https://bugs.kde.org/show_bug.cgi?id=366571 Bug ID: 366571 Summary: Kdenlive git master w/ movit: video playback corruption after end of CPU transition Product: kdenlive Version: unspecified Platform: Debian unstable OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: directact...@hushmail.com When Movit is enabled, at least one CPU effect is on a track, and it is transitioned into from a track above it using a CPU transition (e.g. wipe with an image or dissolve), playback becomes severely corrupted as soon as the transition ends and the track has nothing left to composit with. Sometimes this also causes kdenlive to crash, but not always. Tracks with no effects OK, tracks with only Movit (GPU) effects OK, tracks transitioned into from below with any effects OK, Tracks with GLSL transition between them OK. If only "dissolve" transitions are used GLSL wipe works well though must be inverted for transition down. Playback after transitions normal if Movit is disabled. Reproducible: Always Steps to Reproduce: 1.Put a clip on a track, and another clip on a lower track later in the timeline with an overlap 2. Put any CPU effect on the second track 3.Put any CPU transition between the tracks, it must transition DOWN to the second clip Actual Results: Severe video playback corruption as soon as the transition ends. This can be suppressed by putting a totally transparent image clip above the track in question. This indicates that once compositing to the track begins it must continue or playback is corrupted Expected Results: Track should play normally after end of transition. Kdenlive from GIT master, any version the last couple weeks. MLT is 6.3.0 from GIT master as well, both July 5 2016 and August 8 2016 pulls same results. Projects first made with versions of Kdenlive from June 2016 or earlier are not affected-and starting from an empty project made with a June 10 build of 16.07.70 I saved is gives the expected results (normal playback) even when using current 16.11.70 git master. Thus something in how composited tracks are written to the project file is to blame. Adding a track to such a project immedialty brings back the corrupted playback, no recovery possible exept from backup project file-or by replacing every transition with a GPU transition. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 366570] New: Kdenlive git master: crash on invoking render widget with MLT 6.3.0(git master)
https://bugs.kde.org/show_bug.cgi?id=366570
Bug ID: 366570
Summary: Kdenlive git master: crash on invoking render widget
with MLT 6.3.0(git master)
Product: kdenlive
Version: unspecified
Platform: Debian unstable
OS: Linux
Status: UNCONFIRMED
Severity: crash
Priority: NOR
Component: User Interface
Assignee: j...@kdenlive.org
Reporter: directact...@hushmail.com
Immediate crash and segfault on Kdenlive master with MLT master whenever the
render widget is invoked.
Since commit
http://quickgit.kde.org/?p=kdenlive.git=commit=9a9346e21eed58d6d58ee9e10ecb3e88f0c39bc3
(Fix crashes when using MLT 6.2.0) and the later 8a4ebe4 requires to build it,
clicking the "render" button on the toolbar or selecting "render" from the menu
instantly crashes kdenlive with a segfault. This is with Movit enabled and
using MLT 6.3.0 from git master, MLT builds from July 5 2016 and August 8 2016
pulls exact same behavior. QT and KF5 are what is in Debian Unstable as of
August 10 2016 and same with what was in Debian Unstable in late July.
I was able to trace the exact offending line in commit 9a9346e to the line
below in mainwindow.cpp :
m_renderWidget->errorMessage(m_compositeAction->currentAction()->data().toInt()
== 1 ? i18n("Rendering using low quality track compositing") : QString());
Reverting that line to the previous
m_renderWidget->errorMessage(m_compositeAction->currentItem() == 1 ?
i18n("Rendering using low quality track compositing") : QString());
will permit kdenlive to build and run without crashing when the renderwidget is
invoked as of today. Last commit was
http://quickgit.kde.org/?p=kdenlive.git=commit=f8580603474e1765289d29d00e17ca1b3289f215
Reproducible: Always
Steps to Reproduce:
1. Build MLT from git master, build kdenlive from git master and install on
Debian Unstable
2. Start kdenlive
3. click the "render" button in the toolbar or invoke "render" from the project
menu
Actual Results:
Immediate crash and segfault
Expected Results:
Render widget appearing, displaying the options for rendering out the finished
video.
--
You are receiving this mail because:
You are watching all bug changes.
