[digikam] [Bug 466938] New: Duplicate Detection Reference Image
https://bugs.kde.org/show_bug.cgi?id=466938 Bug ID: 466938 Summary: Duplicate Detection Reference Image Classification: Applications Product: digikam Version: 8.0.0 Platform: Microsoft Windows OS: Other Status: REPORTED Severity: major Priority: NOR Component: general Assignee: digikam-bugs-n...@kde.org Reporter: rona...@outlook.com Target Milestone: --- SUMMARY When searching for duplicates lower resolution images are often selected as reference images. Not related to the date of the image, it can be newer or older, doesn't seem to matter. Sometimes they are in the same album, sometimes not. From the forums it seems we ALL want the highest resolution, highest quality image to be "reference". What is the point of the "remove dupes" button if it's going to delete some of the highest quality images? Useless. STEPS TO REPRODUCE 1. Detect duplicates 2. Scroll through results until you find a reference image that is lower quality than the "dupe". 3. OBSERVED RESULT There will be several cases where the lowest quality image has been selected as the reference image in error. EXPECTED RESULT It is expected that all reference images are the highest quality in each set of "dupes". SOFTWARE/OS VERSIONS Windows: 11 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION This same behavior is present on Ubuntu also. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466938] Duplicate Detection Reference Image
https://bugs.kde.org/show_bug.cgi?id=466938 --- Comment #3 from Ron --- I am running version 8. This is ->not<- fixed! Why are you lieing? Why not just admit it's not fixed? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466938] Duplicate Detection Reference Image
https://bugs.kde.org/show_bug.cgi?id=466938 Ron changed: What|Removed |Added Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 420998] Crash on Startup
https://bugs.kde.org/show_bug.cgi?id=420998 Ron changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Ever confirmed|0 |1 Status|NEEDSINFO |CONFIRMED --- Comment #6 from Ron --- (In reply to Justin Zobel from comment #5) > Thank you for reporting this crash in KDE software. As it has been a while > since this issue was reported, can we please ask you to see if you can > reproduce the crash with a recent software version? > > If you can reproduce the issue, please change the status to "CONFIRMED" when > replying. Thank you! Crashed on startup after clearing cache. Tried to retrieve a backtrace with the KDE crash handler, but it states: 'the debugger has quit unexpectedly'. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 465483] wrong import telescopius mosaic
https://bugs.kde.org/show_bug.cgi?id=465483 Ron changed: What|Removed |Added CC||kd6...@hotmail.com --- Comment #2 from Ron --- I ran into the same problem yesterday when trying to setup a mosaic for California Nebula (NGC1499) Telescopius CSV (2W x 1H tile): Pane, RA, DEC, Position Angle (East), Pane width (arcmins), Pane height (arcmins), Overlap, Row, Column Center, 04hr 01' 17", 36º 17' 44", 0.00, 100.80, 100.80, 10%, -, - Pane 1, 04hr 05' 02", 36º 17' 31", 0.56, 100.80, 100.80, 10%, 1, 1 Pane 2, 03hr 57' 31", 36º 17' 31", -0.56, 100.80, 100.80, 10%, 1, 2 Imported into Kstars Mosaic Planner (MP) after I initialized mosaic size to 1x1. First indication that something's wrong after import is MP says the size is now 1W x 2H. The generated ESL file has a fixed RA with changing DEC for each tile: CalifNebulaNGC1499_AT80.8_OeNh_mosaic-Part_1 4.02139 37.055 CalifNebulaNGC1499_AT80.8_OeNh_mosaic-Part_2 4.02139 35.5361 But the Telescopius CSV is constant (almost) DEC with varying RA. Tile sizes do match up between Telescopius & MP but of course width and height are swapped: 10 4.02139 36.2956 1 2 101.25 192.38 101.25 101.25 I ran the planned mosaic and it indeed produced a 1W x 2H image, 90 degrees off from what I planned with Telescopius. Workaround is to manually enter in the center coordinates (from Telescopius) and mosaic size. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 485356] External proxy preset, error when setting multiple profiles
https://bugs.kde.org/show_bug.cgi?id=485356 --- Comment #1 from Ron --- Hi, Just a followup to this now that the external proxy editing dialog has been enabled in 24.05.0. The bug I noted here is still present in the 24.05.0 appimage. I can see it manifest if I just open that dialog and then flick between the various preset options. If you select the GoPro or Insta option (or any with multiple profiles) then select a different profile, then flick back to the GoPro or Insta one (without closing the dialog), you'll see that each time you go back to the multiple profile preset, the options in it get shuffled around and appear in the wrong fields. Cheers, Ron -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 485356] External proxy preset, error when setting multiple profiles
https://bugs.kde.org/show_bug.cgi?id=485356 Ron changed: What|Removed |Added Version|git-master |24.05.0 Platform|Debian stable |Appimage -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 487947] New: Subtitle .srt files are not autosaved with the project file
https://bugs.kde.org/show_bug.cgi?id=487947 Bug ID: 487947 Summary: Subtitle .srt files are not autosaved with the project file Classification: Applications Product: kdenlive Version: 24.02.2 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: kdenlive-b...@contact.dot-oz.net Target Milestone: --- Hi! This might arguably be a feature request - but: On the (getting rarer! :) occasions when some action crashes kdenlive, being able to rely on it having autosaved all but the last few moments of work, and able to reliably restore them when you restart, makes those crashes *much* less frustrating than they otherwise might be. But I discovered recently that changes to the subtitles are *not* saved and do not get restored. Any changes to them since the last manual save will be lost. It would be nice if they get automatically backed up along with the project files. Thanks! Ron -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 487950] New: Title dialog "+X" and "+Y" fields max out at 5000
https://bugs.kde.org/show_bug.cgi?id=487950 Bug ID: 487950 Summary: Title dialog "+X" and "+Y" fields max out at 5000 Classification: Applications Product: kdenlive Version: 24.05.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: kdenlive-b...@contact.dot-oz.net Target Milestone: --- Hi, Occasionally I use animated titles to create scrolling credits and the like, and occasionally those lists are long. There doesn't seem to be any problem with making them arbitrarily large in any direction - but the displayed X,Y coordinate for content maxes out at 5000. You can place it beyond that by dragging and dropping, but you can't tweak or see the exact placement point using those input dialog fields, which makes precise placement harder than it needs to be. For the same reason it would be nice if the guide lines expanded to cover all the space used by title elements, not just the visible viewport area, and if the increments of the snap-to grid were configurable. Cheers, Ron -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 485356] New: External proxy preset, error when setting multiple profiles
https://bugs.kde.org/show_bug.cgi?id=485356 Bug ID: 485356 Summary: External proxy preset, error when setting multiple profiles Classification: Applications Product: kdenlive Version: git-master Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: kdenlive-b...@contact.dot-oz.net Target Milestone: --- Hi! Attempting to add an external proxy preset with multiple profiles from the UI dialog results in saving the fields in the wrong order. It interleaves the fields for each profile instead of concatenating them as a group one profile after another. So if for example I set clip prefix FOO_;BAR_ in the dialog, it will save: MyProfile=;FOO_;BAR_; instead of MyProfile=;FOO_;;BAR_ Manually editing externalproxies.rc to correct this makes the new proxy profile it work as intended. You can see this corruption also occur with: Project -> Project Settings -> Proxy Enable external proxy clips and open the edit profiles dialog with the button next to the drop down selector. Click on 'GoPro LRV' which has multiple profiles. You should see the fields look correct. Now click on another profile to view it, eg. Akaso LRV. Then if you go back to the GoPro profile, you'll see the field contents are all garbled. I'm seeing this in kdenlive built locally from: c806935cdc8870115503a1f217f0554a0f83d1fc Checking the 24.02.1 Appimage, I'm not seeing the button to pop up an edit profile dialog at all - so now I'm not sure if this is a new option, or something that is not enabled for the AppImage? Cheers, Ron -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 441923] render keeps the "waiting" message but starts rendering
https://bugs.kde.org/show_bug.cgi?id=441923 ron changed: What|Removed |Added CC||ron1ron2...@gmail.com Platform|Other |Ubuntu Packages --- Comment #1 from ron --- the rendering field shows waiting and doesn't save or render at times though. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 426500] INDI server crashes
https://bugs.kde.org/show_bug.cgi?id=426500 --- Comment #2 from Ron --- (In reply to Derek Christ from comment #1) > Correct me if I'm wrong but I don't think this is an issue of Kstars. > > It looks like someone had a very similar bug on the indi forums: > https://www.indilib.org/forum/ccds-dslrs/4860-bug-with-the-indi-atik-ccd- > driver.html > https://indilib.org/forum/general/4890-official-indi-atik-driver-crash.html > > I don't know how these things work on OSX but I would try to ask in the indi > forums for a solution. It might be an Indi issue, but I don't think it's linked to those posts since they are five months old by now and I had zero issues with the Atik driver until the last version of Kstars. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 426500] New: INDI server crashes
https://bugs.kde.org/show_bug.cgi?id=426500 Bug ID: 426500 Summary: INDI server crashes Product: kstars Version: 3.4.3 Platform: macOS (DMG) OS: Other Status: REPORTED Severity: crash Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: rene.krc...@fastmail.fr Target Milestone: --- macOS Catalina Kstars 3.4.3 STEPS TO REPRODUCE 1. set up simulators for everything, but the CCD camera 2. plug-in ATIK414EX CCD 3. start OBSERVED RESULT A pop-up says INDI server crashed and there's a 10 sec timer. At zero, it resets back to 10. Computer reboot doesn't do anything. The exact same configuration, but with the previous version, it works just fine. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405659] Plasma segfault when removing widget
https://bugs.kde.org/show_bug.cgi?id=405659 Ron changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 407092] New: Missing release tag in official valgrind git repository for version 3.15
https://bugs.kde.org/show_bug.cgi?id=407092 Bug ID: 407092 Summary: Missing release tag in official valgrind git repository for version 3.15 Product: valgrind Version: 3.15 SVN Platform: unspecified OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: ronald.w...@raritan.com Target Milestone: --- The official valgrind git repository has no release tag for the current valgrind release 3.15. Please create the tag! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405659] New: Plasma segfault when removing widget
https://bugs.kde.org/show_bug.cgi?id=405659 Bug ID: 405659 Summary: Plasma segfault when removing widget Product: plasmashell Version: 5.13.5 Platform: Ubuntu Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: k...@davidedmundson.co.uk Reporter: ron.atk...@tekfusioninc.com CC: plasma-b...@kde.org Target Milestone: 1.0 Application: plasmashell (5.13.5) Qt Version: 5.11.1 Frameworks Version: 5.50.0 Operating System: Linux 4.18.0-16-generic x86_64 Distribution: Ubuntu 18.10 -- Information about the crash: - What I was doing when the application crashed: I noticed that my weather widget was missing from the system tray. I turned it back on in the configuration settings but it didn't show. I then add the weather widget directly on the panel. It then occurred to me that what I needed to do was logout and in. After a log cycle the weather came back under the system tray so I attempted to remove the duplicate that was on the panel directly and Plasma crashed. - Unusual behavior I noticed: Missing both the weather widget and MS Teams widget. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fe1e7d47840 (LWP 62853))] Thread 7 (Thread 0x7fe13b297700 (LWP 63915)): #0 0x7fe1eb9360f1 in g_private_get () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7fe1eb918610 in g_thread_self () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fe1eb8eff5d in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe1ee79515b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fe1ee74216b in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fe1ee5910b6 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fe14024c8b7 in KCupsConnection::run() () at /usr/lib/x86_64-linux-gnu/libkcupslib.so #7 0x7fe1ee59ac87 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7fe1ee104164 in start_thread (arg=) at pthread_create.c:486 #9 0x7fe1ee27edef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 6 (Thread 0x7fe143073700 (LWP 63863)): #0 0x7fe1ee2726d9 in __GI___poll (fds=0x7fe13c004e10, nfds=1, timeout=9483) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fe1eb8efe46 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fe1eb8eff6c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe1ee79515b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fe1ee74216b in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fe1ee5910b6 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fe1ee59ac87 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fe1ee104164 in start_thread (arg=) at pthread_create.c:486 #8 0x7fe1ee27edef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 5 (Thread 0x7fe14de87700 (LWP 63189)): #0 0x7fe1ee2726d9 in __GI___poll (fds=0x7fe148005590, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fe1eb8efe46 in () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fe1eb8eff6c in g_main_context_iteration () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fe1ee79515b in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fe1ee74216b in QEventLoop::exec(QFlags) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fe1ee5910b6 in QThread::exec() () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fe1f015d396 in () at /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5 #7 0x7fe1ee59ac87 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7fe1ee104164 in start_thread (arg=) at pthread_create.c:486 #9 0x7fe1ee27edef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7fe1def91700 (LWP 63123)): #0 0x7fe1ee10a2eb in futex_wait_cancelable (private=, expected=0, futex_word=0x7fe1f0ba1fb8) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 0x7fe1ee10a2eb in __pthread_cond_wait_common (abstime=0x0, mutex=0x7fe1f0ba1f68, cond=0x7fe1f0ba1f90) at pthread_cond_wait.c:502 #2 0x7fe1ee10a2eb in __pthread_cond_wait (cond=0x7fe1f0ba1f90, mutex=0x7fe1f0ba1f68) at pthread_cond_wait.c:655 #3 0x7fe1f0aaae2a in () at /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #4 0x7fe1f0aaae49 in () at /usr/lib/x86_64-linux-gnu/libQt5Script.so.5 #5 0x7fe1ee104164 in start_thread (arg=) at pthread_create.c:486 #6 0x7fe1ee27edef in clone () at ../sysdeps
[kmymoney] [Bug 400685] New: OFX Importer not showing payee mapping option
https://bugs.kde.org/show_bug.cgi?id=400685 Bug ID: 400685 Summary: OFX Importer not showing payee mapping option Product: kmymoney Version: 5.0.0 Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: importer Assignee: kmymoney-de...@kde.org Reporter: kd6...@hotmail.com Target Milestone: --- Created attachment 116093 --> https://bugs.kde.org/attachment.cgi?id=116093&action=edit OFX sample data file SUMMARY In a manual File | Import | OFX, KMyMoney 4.7.2 OFX Importer asks for a Payee mapping tag to either , or v5.0.0 no longer has this option so the attached sample file no longer imports correctly (I used to specify ). Payee=Unit-based Fund then processed so that the brokerage account used the security names in Has this mapping been moved to another setting or method? Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 423024] New: Impossible to add an element to the toolbars
https://bugs.kde.org/show_bug.cgi?id=423024 Bug ID: 423024 Summary: Impossible to add an element to the toolbars Product: kstars Version: unspecified Platform: macOS Disk Images OS: macOS Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: rene.krc...@fastmail.fr Target Milestone: --- Created attachment 129392 --> https://bugs.kde.org/attachment.cgi?id=129392&action=edit Screen copy macOS 10.14.6 Kstars 3.4.3 Menu "Configure toolbars" Adding any element in any toolbar does nothing. The element is not added. Whether toolbars positions are locked or not. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 423024] Impossible to add an element to the toolbars
https://bugs.kde.org/show_bug.cgi?id=423024 --- Comment #2 from Ron --- Created attachment 129396 --> https://bugs.kde.org/attachment.cgi?id=129396&action=edit Kstars version screen -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 423024] Impossible to add an element to the toolbars
https://bugs.kde.org/show_bug.cgi?id=423024 --- Comment #4 from Ron --- 3.4.3 is what you get when you download the macOS version :-) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 420998] New: Crash on Startup
https://bugs.kde.org/show_bug.cgi?id=420998 Bug ID: 420998 Summary: Crash on Startup Product: kdevelop Version: 5.4.2 Platform: Ubuntu Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: ron.atk...@tekfusioninc.com Target Milestone: --- Application: kdevelop (5.4.2) Qt Version: 5.12.4 Frameworks Version: 5.62.0 Operating System: Linux 5.3.0-51-generic x86_64 Distribution: Ubuntu 19.10 -- Information about the crash: - What I was doing when the application crashed: I was debugging and changed some code and it crashed. I restarted and recovered my changes and quickly saved before it crashed again. When it came up again I cleared the cache but it crashed shortly after. I tried deleting the .kdev4 file and re-opening the project and it keeps crashing everytime I open it. The crash can be reproduced every time. -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". futex_wait_cancelable (private=, expected=0, futex_word=0x7ffe8d99b2e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 [Current thread is 1 (Thread 0x7fe7354db040 (LWP 32752))] Thread 15 (Thread 0x7fe6f5ffb700 (LWP 401)): #0 0x7fe73d1932c6 in futex_wait_cancelable (private=, expected=0, futex_word=0x55d016f95920) at ../sysdeps/unix/sysv/linux/futex-internal.h:80 #1 0x7fe73d1932c6 in __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x55d016f958d0, cond=0x55d016f958f8) at pthread_cond_wait.c:508 #2 0x7fe73d1932c6 in __pthread_cond_wait (cond=0x55d016f958f8, mutex=0x55d016f958d0) at pthread_cond_wait.c:638 #3 0x7fe740123dbf in QWaitCondition::wait(QMutex*, QDeadlineTimer) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fe740123eb1 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fe73c89cea0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #6 0x7fe73c8a0c3e in () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #7 0x7fe73c89c072 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #8 0x7fe73c89eb83 in ThreadWeaver::Thread::run() () at /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5 #9 0x7fe74011dc92 in () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7fe73d18c669 in start_thread (arg=) at pthread_create.c:479 #11 0x7fe73fda0323 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 14 (Thread 0x7fe6f67fc700 (LWP 400)): [KCrash Handler] #6 0x7fe70269b84b in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #7 0x7fe70266dfe6 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #8 0x7fe70267793e in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #9 0x7fe70266e017 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #10 0x7fe70266c9df in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #11 0x7fe70267b386 in clang_visitChildren () at /usr/lib/llvm-9/lib/libclang-9.so.1 #12 0x7fe714a4b834 in () at /usr/lib/x86_64-linux-gnu/libKDevClangPrivate.so.32 #13 0x7fe702677aae in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #14 0x7fe70266e017 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #15 0x7fe70266c9df in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #16 0x7fe70267b386 in clang_visitChildren () at /usr/lib/llvm-9/lib/libclang-9.so.1 #17 0x7fe714a4f43a in () at /usr/lib/x86_64-linux-gnu/libKDevClangPrivate.so.32 #18 0x7fe70266c232 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #19 0x7fe70266f987 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #20 0x7fe70266c995 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #21 0x7fe70267b386 in clang_visitChildren () at /usr/lib/llvm-9/lib/libclang-9.so.1 #22 0x7fe714a3cea7 in () at /usr/lib/x86_64-linux-gnu/libKDevClangPrivate.so.32 #23 0x7fe714a4c05b in () at /usr/lib/x86_64-linux-gnu/libKDevClangPrivate.so.32 #24 0x7fe70266c232 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #25 0x7fe70266e1d0 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #26 0x7fe70266e3b0 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #27 0x7fe70266cbc2 in () at /usr/lib/llvm-9/lib/libclang-9.so.1 #28 0x7fe70267b386 in clang_visitChildren () at /usr/lib/llvm-9/lib/libclang-9.so.1 #29 0x7fe714a319d4 in Builder::visit(CXTranslationUnitImpl*, void*, QHash const&, bool) () at /usr/lib/x86_64-linux-gnu/libKDevClangPrivate.so.32 #30 0x7fe714a5a16b in ClangHelpers::buildDUChain(void*, QMultiHash const&, ParseSession const&, KDevelop::TopDUContext::Features, QHash&, ClangIndex*, std::function const&) () at /usr/lib/x86_64-linux-gnu/libK
[kdevelop] [Bug 420998] Crash on Startup
https://bugs.kde.org/show_bug.cgi?id=420998 --- Comment #2 from Ron --- I didn't crash again today. I'll try the suggestions below. Thanks, Ron Atkins -Original Message- From: Milian Wolff Sent: Monday, May 4, 2020 9:48 AM To: Ron Atkins Subject: [kdevelop] [Bug 420998] Crash on Startup https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.kde.org%2Fshow_bug.cgi%3Fid%3D420998&data=02%7C01%7Cron.atkins%40tekfusioninc.com%7Cd66320a04c7e41dc221508d7f031b44a%7C522748305aef4de4ade92b1107093e0c%7C0%7C0%7C637241968593321201&sdata=MBuSbNe5RQL45m2o3MRmhPkPC0pCBCl%2Bu2qYPUO%2F%2F44%3D&reserved=0 --- Comment #1 from Milian Wolff --- it's a crash in libclang, so there's not much chance for us to fix it. can you try to use a newer libclang or kdevelop to see if that is fixed? alternatively, can you try to set the following env vars and then attach the output to this report? KDEV_CLANG_DISPLAY_ARGS=1 KDEV_CLANG_DISPLAY_DEFINES=1 that should show us hopefully a way to build a reproducible test case. But beware that this may "leak" information about what you are building, can you share that? -- You are receiving this mail because: You reported the bug. This e-mail may contain confidential or privileged information. This communication and any attached documents may also contain data subject to the International Traffic in Arms Regulations or U.S. Export Administration Regulations and cannot be disseminated, distributed or copied to foreign nationals, residing in the U.S. or abroad, without the prior approval of the U.S. Department of State or appropriate export licensing authority. If you are not the intended recipient, please notify the sender immediately by return e-mail with a copy to: i...@tekfusioninc.com and delete this e-mail and all copies and attachments. Opinions, conclusions and other information in this message that do not relate to the official business of Tek Fusion Global, Inc., shall be understood as neither given nor endorsed by it. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 419898] New: AppImage print only generates one blank page
https://bugs.kde.org/show_bug.cgi?id=419898 Bug ID: 419898 Summary: AppImage print only generates one blank page Product: kmymoney Version: 5.0.8 Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kmymoney-de...@kde.org Reporter: kd6...@hotmail.com Target Milestone: --- SUMMARY Printing with the KMM AppImage doesn't work STEPS TO REPRODUCE 1. Start current stable AppImage KMM build (KMyMoney-5.0.8-569a3ed-x86_64) 2. Select a report (for example, Net Worth Today or Assets & Liabilities screen on Home page) 3. Select Print command, select a physical printer or Print to File (PDF) in the Linux Mint printer dialog box and execute Print command OBSERVED RESULT A single blank page (either physical or PDF) EXPECTED RESULT The data that's shown in KMM SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Mint 19.3 Cinnamon (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I tried another AppImage (GVim-v8.2.0535.glibc2.15-x86_64) and printing to a physical printer works correctly (it didn't show a PDF option) I can workaround the problem by exporting the KMM report to an HTML file -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 390997] New: Unable to run Updates
https://bugs.kde.org/show_bug.cgi?id=390997 Bug ID: 390997 Summary: Unable to run Updates Product: Discover Version: unspecified Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Updater Assignee: aleix...@kde.org Reporter: r...@first-rate.info Target Milestone: --- Created attachment 110958 --> https://bugs.kde.org/attachment.cgi?id=110958&action=edit Error message displayed briefly Kubuntu 16.04 KDE Plasma Version: 5.8.8 KDE Frameworks Version: 5.36.0 Qt Version: 5.6.1 Kernel Version: 4.4.0-112-generic QS Type: 32-bit Click on Updates icon in taskbar at the bottom of the screen. Click on the Update button (16 packages to update). Updates - Discover window opens normally. Click on the Update All button. Authentication window opens normally. Type password. Discover crashes when trying to update. An error message is displayed briefly but disappears quickly, see attached photo The package failed to install message displayed. "Error while installing cannot copy extracted data ..." <<= SEE ATTACHMENT Discover Closed Unexpectedly message is displayed. Discover crashes irrespective of how many updates are selected. Select all 16 updates and Discover crashes; same error msg displayed briefly. Select just one update and Discover crashes; same error msg displayed briefly. Unselect all updates and Discover still crashes; same error msg displayed briefly. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 393261] New: child menu settings windows will appear before main Krita window
https://bugs.kde.org/show_bug.cgi?id=393261 Bug ID: 393261 Summary: child menu settings windows will appear before main Krita window Product: krita Version: git master Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: ronde...@gmail.com Target Milestone: --- Selecting a menu option will have the child window open behind Krita. For example, in main menu, select "Settings" then "Configure Krita". The "configure krita" appears then the main Krita program window moves in front of the "configure.." window. While the child window is showing in Windows tool bar, sometimes I can't get the child window to move in front of the main window by selecting it. I'm running Krita 4.0.0 on a Windows 10 Pro 64-bit system with NVDIA graphics. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 393261] child menu settings windows will appear before main Krita window
https://bugs.kde.org/show_bug.cgi?id=393261 --- Comment #2 from Ron --- Today I updated to version 4.0.1 and have not had the child window issue so far. Perhaps this latest version fixed it? -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 392150] New: Discover Constantly Crashing on NEON OS
https://bugs.kde.org/show_bug.cgi?id=392150 Bug ID: 392150 Summary: Discover Constantly Crashing on NEON OS Product: Discover Version: 5.12.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: discover Assignee: aleix...@kde.org Reporter: pinstriped...@yahoo.com Target Milestone: --- Every time I go to update after initial installation of the OS, Discover CRASHES!! Reboot and try again... Same thing. I had to update the system using Apt-Get, but the Updates icon in the panel still says there are updates and so I click on it and BAM... CRASH!! Everything else seems to be working fine on my DELL Optiplex 760 desktop and my HP 14" Pavilion laptop. -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 389676] New: syslog reporting long lists of this!
https://bugs.kde.org/show_bug.cgi?id=389676 Bug ID: 389676 Summary: syslog reporting long lists of this! Product: ktorrent Version: 5.1 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: general Assignee: joris.guis...@gmail.com Reporter: ronjin...@gmail.com Target Milestone: --- Activating service name='org.kde.kcookiejar5' Jan 31 09:38:59 ronjinpi dbus-daemon[1314]: Activated service 'org.kde.kcookiejar5' failed: Failed to execute program org.kde.kcookiejar5: No such file or directory -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 394297] New: Ambiguous Shortcuts - Gwenview
https://bugs.kde.org/show_bug.cgi?id=394297 Bug ID: 394297 Summary: Ambiguous Shortcuts - Gwenview Product: gwenview Version: unspecified Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: pinstriped...@yahoo.com Target Milestone: --- There are two actions (Cut, Delete) that want to use the same shortcut (Shift+Del). This is most probably a bug. Please report it in bugs.kde.org Every time I try to open a picture file, I get this message: -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 382284] New: Photo jpg failed to open and caused an error
https://bugs.kde.org/show_bug.cgi?id=382284 Bug ID: 382284 Summary: Photo jpg failed to open and caused an error Product: dolphin Version: unspecified Platform: Mint (Ubuntu based) OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: view-engine: icons mode Assignee: dolphin-bugs-n...@kde.org Reporter: pinstriped...@yahoo.com Target Milestone: --- I got the following message (after brand new install of Mint KDE 18.0) when clicking on a jpg file to open and view a photo. Copied and pasted: There are two actions (Cut, Delete) that want to use the same shortcut (Shift+Del). This is most probably a bug. Please report it in bugs.kde.org My pc is a Dell Opti-Plex 760 with 8 gigs mem and an 128gb SSD. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #18 from Ron --- Ok, I had a chance to poke around with this some more - I figured bisecting mlt to find the exact change that introduced this problem shouldn't be too hard - but as usual I learned more than I bargained for :) The initial results didn't make a lot of sense at first, so I've attached another test project which is the same as the first one, implementing the test Roxane described, but as a 1080p native project instead of rescaling from 4k to eliminate any effect ffmpeg rescaling might have ... And interestingly, it appears there are two problems with the newest versions. Re-running the set of tests from scratch with this new project, the first curious thing I saw was that if I created rendering scripts with 22.08.1, 22.08.2, 24.12.0 and the 25.03.70 snapshot posted here for testing, then rendered them with melt from the 22.08.1 appimage, the result was, somewhat confusingly: - Both 22.08 scripts rendered 'perfectly', with the absolute minimum of jitter seen in any test. - The 24.12 and 25.03 scripts both rendered a jittering result, even with 22.08.1 melt. The difference in the later scripts which is causing the appearance of jitter appears to be 'rescale="hyper"' in the options, even when there is no 'scale' option (and rescaling was disabled in the render dialog). If I remove that option, then the render script generated by both later versions renders perfectly with the 22.08.1 version of melt. So from that baseline, I could go back to more sanely bisecting mlt, and the result there confirmed what I originally suspected: The last commit to run this test with "no jitter" is this one: https://github.com/mltframework/mlt/commit/c2339fc146898197b11e13c44692d901ae436245 The next commit after that introduces some jitter: https://github.com/mltframework/mlt/commit/0c22797bbcb209f9667d72d4038866f28a624115 And the one after that makes it a bit worse: https://github.com/mltframework/mlt/commit/d047879e00f03b42587e68652dfe069c45c157aa The mlt version included with 25.03.70 still has a significant jitter compared to the 22.08.1 / mlt-c2339fc1 baseline. I'm still not exactly sure what problem those commits above were fixing, so I'm not terribly confident to propose another patch for mlt offhand that wouldn't re-introduce it - but I'm set up to test this now, so I can pull changes from mlt git or apply patches manually to test against this set of rendering scripts. I'm not quite sure what to suggest for the rescale="hyper" problem ... one obvious workaround at the kdenlive level would be to not include that option if there is no rescaling being done, but if that rescaler is introducing jitter, that might be a bug the ffmpeg folks would want to know about too ... or there may be a better option for render time rescaling that kdenlive/mlt could use? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #17 from Ron --- Created attachment 177145 --> https://bugs.kde.org/attachment.cgi?id=177145&action=edit 1080p native test project -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 485356] External proxy preset, error when setting multiple profiles
https://bugs.kde.org/show_bug.cgi?id=485356 --- Comment #4 from Ron --- (In reply to MartinG from comment #3) > Thank you for this - I have spent a few hours trying to find out why my > external proxy clips don't work. > Below is a workaround that solved my problem of non-working external proxy > clips. I'm actually not quite clear on what you are "working around" here, but ... > In my kdenliverc, I have this: > externalProxyProfile=./;GOPR;./;GOPR;./;GL;./;GH;./;.LRV;./;.MP4;./;.LRV;./;. > MP4;GL;.LRV;GX;.MP4;GP;.LRV;GP;.MP4 Yes, this is clearly corrupted by this bug, and this setting is just kdenlive 'remembering' the last set of values that you used in those fields of the project settings proxy tab ... > I see that I have also ~/.local/share/kdenlive/externalproxies.rc with this > in it: > GoPro > LRV=./;GOPR;./;GOPR;./;GL;./;GH;./;.LRV;./;.MP4;./;.LRV;./;.MP4;GL;.LRV;GX;.MP4;GP;.LRV;GP;.MP4 Which is where the named profiles are defined, and clearly you have corrupted the entry(/ies) in this file too by editing that profile in a version of kdenlive with this bug. If you just delete that file, kdenlive should restore it with the actually correct values from the compiled in setttings for the pre-defined profiles that it ships with. > Turns out this file isn't used before I switch from "Current settings" (where > ever they came from?) ... "Current settings" are the last values you used in those fields (taken from the setting in kdenliverc), when those don't correspond to a named profile (because you can put whatever custom thing you like in there to suit the structure of a given project. You don't have to define a named profile for something you will only use once in one project. > ... to "GoPro LRV". And when you select a named profile it uses the setttings saved in externalproxies.rc So I'm glad that finding this helped you figure it all out, but there isn't really any magic workaround ... While this bug persists, if you try to use the edit profile dialog it will create a corrupted profile in externalproxies.rc If you then try to use that, it will remember the last used settings (bogus or not) in kdenliverc (and save them to your project file). The only way to add or edit new profiles until this is fixed is to manually edit the externalproxies.rc file - and so long as you never try to edit them in the app dialog, the contents of that file is initially created correctly and will not become corrupted. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #15 from Ron --- Created attachment 176910 --> https://bugs.kde.org/attachment.cgi?id=176910&action=edit project implementing the test described in bug 476625 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #16 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #14) > Could you test our latest nightly builds that contain my MLT fixed to confirm > if the issue is better ? Sorry, sadly this doesn't seem to make a notable improvement :( I've attached a project file that implements the test from the earlier bug report which shows this more clearly. The project file is for 22.08.1, but will upgrade cleanly (with an automated fixup) to also work with 24.12.0 and the nightly build you linked to (the reverse isn't true, 22.08 will not open the upgraded project files). I've tested it with all three of those appimages, and it is much noticeably smoother with 22.08.1, and about the same with 24.12 and the nightly. It's a 4k project, but as I noted before the effect is much easier to see when it is rendered scaled to 1080p. I rendered both 4k and 1080p copies for all those versions to compare. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #12 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #4) > This bug is not so obvious. Trying with your instructions and a random > photo, it was not so noticeable. If you have a project file with an image > that makes it easy to spot the bug it would help looking for the bug. The examples that were provided in this earlier report of the problem show it much more clearly: https://bugs.kde.org/show_bug.cgi?id=476625 (see the files in the drive linked at the bottom) zooming in on a pair of plain coloured rectangles giving a thin border where they overlap makes it much more obvious than zooming in on a detailed image. I also found it was much more obvious when rendered at a lower resolution - eg. for the same test project it was quite clear when rendered at 1080p, but fairly subtle (though still noticeable compared to the earlier mlt) at 4k. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 487947] Subtitle .srt files are not autosaved with the project file
https://bugs.kde.org/show_bug.cgi?id=487947 Ron changed: What|Removed |Added Version Fixed In||24.12.0 --- Comment #2 from Ron --- Confirmed. I can see .ass files getting saved in subdirs of .backup/ and just deliberately kill -9'd a test project with unsaved subtitles and they are restored as expected. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 490459] Subtitles gone after crash and reopen project
https://bugs.kde.org/show_bug.cgi?id=490459 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net Version Fixed In||24.12.0 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #34 from Ron --- Thanks! Nothing leaps off the page at me in the diff to the previous patch - though that (consumerScale > 0.) test block caught my eye and had me scratching my head again until my idiot brain twigged that it was reading > 0 but *thinking* > 1 so that bit makes more sense now :) It is why I like to give 'magic' numbers and return values explicit names, so they don't get confused with 'normal' values. I've just updated my dev vm to pull these last changes in, and confirmed Roxane's test case still looks good. Right now I'm mostly testing changes to subtitle stuff, so this code path probably won't get a lot of exercise there just yet - but I'm deliberately poking at lots of corner cases, so ... -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 486310] Add Clip or Folder dialog window too small
https://bugs.kde.org/show_bug.cgi?id=486310 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #9 from Ron --- Bernd asked if I could take a peek at this a couple of weeks ago, and having just been messing with the file dialog for exporting subtitles, I figured I might finally know my way around at least enough to get some sense of what's going on here ... The "Add Clip of Folder" option opens a KFileWidget, which it seems we don't really have any direct control over sizing, and which doesn't appear to retain any memory of prior user resizing. It does have two identically implemented methods to report the size it would like to be, sizeHint() (https://api.kde.org/frameworks/kio/html/kfilewidget_8cpp_source.html#l00567) and dialogSizeHint (https://api.kde.org/frameworks/kio/html/kfilewidget_8cpp_source.html#l02962) ... And looking at how it behaves for me in a VM with current bleeding edge plasma and on a desktop running Sawfish in MATE, it does seem to pop up sized to half the screen size in both cases as that code would suggest. So the next interesting question now for the people this is terribly small for, is: - is your screen so small that half the screensize is too small for this dialog? - or is your window manager doing something awful and ignoring that size hint? But short of subclassing KFileWidget and reimplementing its sizeHint() method, there doesn't really appear to be a lot we can do in kdenlive to fix this, or anything we are Doing Wrong ... I'll leave this open until we answer the question(s) above though in case there is something we can document to avoid a system-related problem. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #22 from Ron ---
And working my way up the tree, here's a patch that makes mlt
0c22797bbcb209f9667d72d4038866f28a624115
scroll smoothly with both hyper and bilinear interpolation (should work with
all, but only testing those two right
now as the representative cases).
diff --git a/src/modules/qt/filter_qtblend.cpp
b/src/modules/qt/filter_qtblend.cpp
index e1d0a8fb..2c2e2759 100644
--- a/src/modules/qt/filter_qtblend.cpp
+++ b/src/modules/qt/filter_qtblend.cpp
@@ -95,9 +95,13 @@ static int filter_get_image( mlt_frame frame, uint8_t
**image, mlt_image_format
transform.translate(rect.x, rect.y);
opacity = rect.o;
hasAlpha = rect.o < 1 || rect.x != 0 || rect.y != 0 || rect.w
!= *width || rect.h != *height;
- b_width = qMin( (int)rect.w, b_width );
- b_height = qMin( (int)rect.h, b_height );
- if ( b_width < *width || b_height < *height )
+ if ( qMin( qRound(rect.w), b_width ) < *width || qMin(
qRound(rect.h), b_height ) < *height )
{
hasAlpha = true;
}
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 07d40619..7da7a5d9 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -88,8 +88,8 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
}
transform.translate(rect.x, rect.y);
opacity = rect.o;
- b_width = qMin((int)rect.w, b_width);
- b_height = qMin((int)rect.h, b_height);
+ b_width = qMin(qRound(rect.w), b_width);
+ b_height = qMin(qRound(rect.h), b_height);
}
else
{
@@ -248,7 +248,8 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
bool hqPainting = false;
if ( interps )
{
- if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
+// if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
{
hqPainting = true;
}
The main things I'm uncertain of in this one is whether *anything* else in
filter_qtblend needs the adjusted value of b_width/b_height (and I've
reintroduced the original bug this was fixing) - but it seems adjusting it
there just causes the inaccuracy and jitter we're seeing.
And I tested nearest interpolation with the hqPainting change and it too is
much smoother - so I think I'd recommend just always enabling hgPainting unless
someone has benchmarks that show it really is expensive to want "worse than
nearest neighbor results" for (maybe?) gaining a little speed.
I'll come back to this again in a bit and look at the next commits up the chain
- but figured I'd share what I know now to see if there's any useful review on
this by the time I'm back to it again (and so we're not duplicating effort
analysing it :)
--
You are receiving this mail because:
You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #21 from Ron ---
Ok, I need to get some sleep, and my source tree is a mess of debug tracing
patches right now - but I believe (after quite some number of wild goose chases
:) that I've pinned down the problem with rescale=hyper in mlt-c2339fc1, and
this little kludge appears to fix it:
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 7817f6e6..8d5900e7 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -222,7 +222,7 @@ static int get_image( mlt_frame a_frame, uint8_t **image,
mlt_image_format *form
bool hqPainting = false;
if ( interps )
{
- if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
+ //if ( strcmp( interps, "bilinear" ) == 0 || strcmp( interps,
"bicubic" ) == 0 )
{
hqPainting = true;
}
It wasn't using hqPainting when interps=hyper ...
With that patch the 22.08.1 version of mlt now seems to "always" do the right
thing with rendering
scripts from all kdenlive versions.
I'll tidy all this up, and look more into the behavior of mlt head soon, but it
does seem to have this same bug.
Is there any interpolation that it really is worth not using hqPainting for?
Should disabling this only be
conditional on the interps == nearest case (so this bug doesn't come back if
newer better interpolation
schemes are added later) or should it just always use 'hq' in every case now?
--
You are receiving this mail because:
You are watching all bug changes.
[kdenlive] [Bug 498586] [Feature Request] Decimal Precision in Transforms
https://bugs.kde.org/show_bug.cgi?id=498586 Ron changed: What|Removed |Added Version Fixed In||24.12.2 CC||kdenlive-b...@contact.dot-o ||z.net Resolution|LATER |FIXED --- Comment #2 from Ron --- https://invent.kde.org/multimedia/kdenlive/-/merge_requests/572 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Ron changed: What|Removed |Added CC||roxane.pet...@gmail.com --- Comment #28 from Ron --- *** Bug 476625 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476625] Shakiness with composite and transform (and composite) when zooming
https://bugs.kde.org/show_bug.cgi?id=476625 Ron changed: What|Removed |Added Resolution|WAITINGFORINFO |DUPLICATE CC||kdenlive-b...@contact.dot-o ||z.net Status|NEEDSINFO |RESOLVED --- Comment #4 from Ron --- Merging this with 497435 since we have a patch to fix it pending. *** This bug has been marked as a duplicate of bug 497435 *** -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #31 from Ron --- hmm, not directly related to this issue as such - but I woke from a nap wondering if there might not be a measurable rendering speed up from inlining the mlt_profile_scale_*() functions ... qtblend alone calls them 4 times each time it's entered for a frame, and it's really just a simple (if args initialised do divide) which seems ripe for the compiler to be able to do Good Things with if it wasn't hidden behind a function call into a different shared library ... -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #20 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #19) > The "rescale=hyper" option comes from the Kdenlive Render widget. Ah, thanks - I see now that's not directly an ffmpeg option, it's handled directly by mlt, though in my build it appears to be using the swscale filter not the gdk one. I'm still tracing through the code to make sense of why rescale="hyper" has an adverse effect even when not rescaling, but interestingly if I run mlt-c2339fc1 (the 'good' one) with each of the rescaler types (but rescaling disabled in the render dialog) then what I see is: - bilinear and bicubic give the same smooth result that not setting rescale= gives. - nearest has a fairly regular stairstep jitter, and hyper has a slightly more irregular jitter. But I haven't yet figured out what code path is different between those if no actual rescaling is being done. (though I'm seeing hints of the rescaler code being entered as part of qtblend ... which maybe explains why the rescale option is always set, not just when "rescaling"?) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #26 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #23) > We need to keep the nearest rescale ... in some cases users want such > scaling (when upscaling pixel art for example). Ok, that makes sense. I'm fine with "sacrificing" nearest for that use case. I'd pondered whether a 'none' option might be worth adding if there was a case for not using the QPainter smoothing - but in this light I don't think so - anyone who really cares about smooth is going to use one of the stronger interpolation methods. And with this patch, nearest isn't jittery, it's just stairsteppy, as you'd expect (and for that use case want). > I have also spent quite some time to figure out the issue there. My changes > that introduced the bug, changing b_width and b_height in filter_qtblend, > were part of an optimization. With this change, instead of always requesting > a full frame image from the source producer, we ask for an already scaled > from from the producer. But despite all my attempts, with this technique, it > doesn't seem possible to get smooth zoom, as the producer return images with > integer sizes. Yeah, I think that's the crux of it (and the classic gotya with floating point), there may be a class of transforms you could optimise that way, but in the general case and for continuous small subpixel motion, the loss of precision in the intermediate calculation can add up to much larger errors in the final result. If we're going from integer pixels to pixels, the whole transform has to be done in a single step. > The attached path seems to make it work correctly for me. Could you please > test ? I think we're looking good! Or at least I've run out of ways for now to make something look broken with this one. I'll attach my diff as applied to current mlt head (32abe16667). There's no substantive change to what you did, but has a couple of little extra things I saw along the way: - fixes the file name in the filter_qtblend.cpp header. - merges the tests for setting hasAlpha into a single statement. - drops an apparently vestigial "if (error) return error;" - because nothing changes the initialised value of error before that point. - merges setting hqPainting into a single statement, and adds a comment about why nearest is excluded, so people don't wonder if it can be 'optimised' like I did :) The janitoral stuff can be split into separate commits for pushing to mlt, but it's obvious enough that I've left it all one diff instead of making it a patch series. > And thanks for your patch, my solution is based on your results ! Thanks for the sanity checks and the clues along the way! I'd felt a little guilty about initially handwaving this away as "expected and normal" in the forum before I saw the tests that Roxane had posted and realised it was quite real - and there's only really one way to atone for that :) It's good to get to know this code better, I've been a happy user for quite a while now, and this lowers the bar for looking into some of the other glitches I've been noting on the forum which I keep promising Bernd I'll get around to filing real bug reports for :D -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 --- Comment #27 from Ron --- Created attachment 177237 --> https://bugs.kde.org/attachment.cgi?id=177237&action=edit 'final' patch tested with mlt HEAD -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435
--- Comment #30 from Ron ---
(In reply to Jean-Baptiste Mardelle from comment #29)
> ... My work is here:
> https://github.com/j-b-m/mlt/tree/work/qtblend-fixes
Looking at the diff between that tree and the one my 'final' patch came from,
I have a couple of initial comments (most easily expressed as a patch ;)
diff --git a/src/modules/qt/filter_qtblend.cpp
b/src/modules/qt/filter_qtblend.cpp
index f77ab94f..0db7b9bb 100644
--- a/src/modules/qt/filter_qtblend.cpp
+++ b/src/modules/qt/filter_qtblend.cpp
@@ -81,7 +81,7 @@ static int filter_get_image(mlt_frame frame,
double opacity = 1.0;
// If the _qtblend_scaled property is true, a filter was already applied,
and we cannot get the consumer scaling using *width / *height
-bool qtblendRescaled = mlt_properties_get_int(frame_properties,
"_qtblend_scaled") == 1;
+ int qtblendRescaled = mlt_properties_get_int(frame_properties,
"_qtblend_scaled");
if (mlt_properties_get(properties, "rect")) {
rect = mlt_properties_anim_get_rect(properties, "rect", position,
length);
if (::strchr(mlt_properties_get(properties, "rect"), '%')) {
@@ -204,7 +204,7 @@ static int filter_get_image(mlt_frame frame,
if (distort) {
transform.scale(rect.w / b_width, rect.h / b_height);
} else {
-double scale = 1;
+double scale;
double resize_dar = rect.w * consumer_ar / rect.h;
if (b_dar >= resize_dar) {
scale = rect.w / b_width;
The "int qtblendRescaled" change is a micro optimisation - it will either be 1
if we set it, or default to 0 if we didn't,
so we don't need to test it and massage it into a bool type before using it as
a true/false conditional later.
The compiler would *probably* just do that anyway, but this is a hot path, so
...
And scale doesn't need initialisation there, it's always set one way or the
other just below that.
diff --git a/src/modules/qt/transition_qtblend.cpp
b/src/modules/qt/transition_qtblend.cpp
index 4bc59050..cdebbfec 100644
--- a/src/modules/qt/transition_qtblend.cpp
+++ b/src/modules/qt/transition_qtblend.cpp
@@ -91,15 +91,15 @@ static int get_image(mlt_frame a_frame,
}
int request_width = profile->width;
-int request_height = profile->height;
+// int request_height = profile->height;
double scalex = mlt_profile_scale_width(profile, *width);
double scaley = mlt_profile_scale_height(profile, *height);
if (scalex != 1.) {
-request_width *= scalex;
+request_width = *width;
b_height *= scalex;
b_width *= scalex;
}
-request_height *= scaley;
+int request_height = *height;
// Check transform
if (mlt_properties_get(transition_properties, "rect")) {
@@ -203,6 +203,7 @@ static int get_image(mlt_frame a_frame,
"progressive,distort,colorspace,full_range,force_full_luma,"
"top_field_first,color_trc");
// Prepare output image
+ // XXX Delete this conditional now
if (false && b_frame->convert_image && (b_width != request_width
|| b_height != request_height)) {
mlt_properties_set_int(b_properties, "convert_image_width",
request_width);
mlt_properties_set_int(b_properties, "convert_image_height",
request_height);
The change to request_*, unless I'm missing something there, is just what that
really does?
mlt_profile_scale_width sets scalex = width / profile->width
So at best request_width (aka profile->width) * scalex, will always equal width
or at worst it will be slightly different due to fp rounding precision.
The compiler would *probably* optimise out the second multiply - but if I'm
not missing something, we can just beat it to it.
The XXX comment is just about the if (false ...) change there. If that change
is no longer
WIP, that block can be deleted in the final patch.
I'm also not really clear on what this following code is really doing - I get
what you are aiming
for in principle here, and I think that's the right thing - and this probably
just shows off how
grainy my understanding of mlt's internal machinations still is, but ...
when we get here, b_width is either set to profile->width or meta.media.width,
and I don't see
where either of those might get changed by qtblend previously rescaling, so
it's not clear to
me why it would need to be multiplied by consumerScale, or why that would only
be done
if we are scaling up ...
I have no reason to doubt you had a good reason for doing this - it's just the
one bit I can't
execute in my head and go "yep, that looks like the right thing to me" :)
In filter_qtblend.cpp:
+
[kdenlive] [Bug 492729] Normalize (2 pass) causes Kdenlive to freeze-up
https://bugs.kde.org/show_bug.cgi?id=492729 Ron changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WORKSFORME CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #7 from Ron --- (In reply to turtle.engr from comment #3) > Kdenlive will not work on Ubuntu 18.x. ... Ubuntu 18.04 went EOL mid 2023 ... is there some compelling reason you can't upgrade that? I do recall Normalize (2 pass) was flaky in the very early years of me using Kdenlive, but I've been using it in nearly every project for many years now without any trouble from the appimage releases. I'm not sure offhand what code that effect is using - but when kill -9 is the only way out it's usually something system level ... -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 486310] Add Clip or Folder dialog window too small
https://bugs.kde.org/show_bug.cgi?id=486310 --- Comment #12 from Ron --- It's sounding a lot like your window manager is not playing nice with Qt - there used to be some gtk shims that could help with that, but I can't say offhand if they're still needed or still help. I do recall it being a bit of a black art to find the right environment variables to set to get Qt to play nice on my high dpi screens outside of a KDE desktop. Oh, and it's possible wayland vs X makes some difference here? But essentially the problem is that all Qt can do is say "Please sir, I would like a window of this size, in this position", and it's entirely up to your window manager as to whether it respects that wholly, partly, or just says screw you, 640x480 should be enough pixels for anyone. If you're running the current appimage it should be using the code I indicated, so if it's not half your screen size, I'd be looking at how your WM is configured. I know with the plasma VM I could actually set explicit sizes and positions of my own for various applications and their dialogs. The MATE + sawfish system mostly just always Does Something Reasonable, so I've never messed with that more. Hopefully you can find something to share to help the other people this is afflicting. It clearly sucks, but if the code is already asking for half the screen and not getting it, us poking the code to make it ask for more isn't likely to help a lot. We need to find why the WM isn't giving it that. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 502725] Glitches when rendering Arabic language subtitles
https://bugs.kde.org/show_bug.cgi?id=502725 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #8 from Ron --- (In reply to ellat from comment #6) > (In reply to balooii from comment #5) > > Oh and did you check which font was used in the version you reported as last > > working? > > Well, Arial works in version 22.12.03. If you're on Linux, there generally is no Arial font unless you've gone well out of your way to install it manually. It's not a freely licenced font, so distros generally can't ship it by default. It will get mapped to some other "similar" font that you do have installed on your system. (and even 'genuine Arial' may not provide the glyphs you need for this either). The "empty square box" is the normal fallback behaviour of most font rendering code when some font does not have a glyph defined for a codepoint. So the key point here is you need to find a font that contains all the glyphs you need and configure your system to use it when you need those glyphs. That means you may want to select some font other than Arial, if you are supplying subtitle files and not burning them in at render time, and you'll need to find a font that is available and provides the needed glyphs on all the platforms you want to play this on. There really is nothing that kdenlive (or any higher level library or tool) can do to 'fix' this if you're using a font with missing glyphs. The best we could do is share a user-created list of fonts that people have tested to work portably for certain locales. What would have changed to 'break' this for you is the default font that either your system libraries provided, or that was suggested by something embedded in whichever packaged version of kdenlive you used. It won't have been a change in kdenlive itself that caused this. So, I'd be inclined to close this bug as something "we can't fix", and perhaps open a thread on the discuss forum for making font suggestions for various locales. Sorry this bubbled away for so long without any clarification. I'm currently working on improving the subtitle handling, and only just now saw this report for the first time. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 442881] Subtitle tool: carriage return lost on project reopen
https://bugs.kde.org/show_bug.cgi?id=442881 Ron changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Ron --- Hi, this should no longer be a problem in the current releases. Newlines can be a little troublesome with subtitles, in some formats a blank line is the terminator between two separate subtitles, in others all newlines must be escaped. Since this report was made kdenlive has switched from SRT to ASS subtitles and is escaping literal carriage returns entered in the editor. There are still a few glitchy corner cases as of the 25.04 release, but they should all be fixed in the next iteration of subtitle improvements that should land with the next major release. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 442881] Subtitle tool: carriage return lost on project reopen
https://bugs.kde.org/show_bug.cgi?id=442881 Ron changed: What|Removed |Added Version Fixed In||24.12.0 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497435] Shakiness in Transform
https://bugs.kde.org/show_bug.cgi?id=497435 Ron changed: What|Removed |Added Version Fixed In||25.04.0 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 484909] Combine next or previous subtitle with selected subtitle.
https://bugs.kde.org/show_bug.cgi?id=484909 Ron changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #1 from Ron --- (In reply to Mubri from comment #0) > Created attachment 168046 [details] > Attachment showed what I want. > > *** > If there is a subtitle line having more and more words in timeline, we can > split/divide that line in subtitle editing section, with the help of > scissor/eraser tool but, > Is there a way to merge/combine two or more short subtitle words/line with > next or previous lines? Other than "undoing" a prior split, there isn't really any way to 'merge' clips in kdenlive and I'm not even really sure what a UI for that might look like (how do you tell it how you want the text merged? there are lots of ways you might want to combine them). You can already copy text between subtitles in the 'normal way' (selecting the bits you want in the editor window for the clip you want to copy from, pasting it wherever you want it in the clip you're copying to). And deleting a clip you've superseded is trivial. Does that not do what you want to do about as easily/flexibly/powerfully/intuitively as manipulating text should be? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461202] Subtitles : "Opaque background" option's problem
https://bugs.kde.org/show_bug.cgi?id=461202 Ron changed: What|Removed |Added Resolution|--- |UPSTREAM Status|REPORTED|RESOLVED --- Comment #1 from Ron --- (In reply to jimnong from comment #0) > STEPS TO REPRODUCE > 1. Add Subtitles. And click "Show style options" button. > 2. Check "Opaque background" and "Custom Outline Color". > 3. Change Outline Color. And set "Alpha channel" to 155. This has all changed a bit since the version you reported this for, and is about to change a bit more, but the essence of this issue remains the same. > The superimposed background color of the subtitles looks darker than the > non-overlapping ones. That's kind of fundamental to how alpha works. If you overlap translucent layers they will become more opaque, so this part is "expected". > The background of the subtitles should not overlap. Which means this is the core of the problem with what you tried to do. > It seems necessary to add options such as up/down/left/right margin or > padding. You can try to fiddle this with vertical scale and the like, but that won't work very reliably, because "overlapping" subtitles appear to have slightly different vertical spacing to "multi-line" subtitles with an embedded line break - so if you do this you can 'fix' one at the cost of breaking the other. And chances are it changes depending on the metrics of the font used too. So for embedded subtitles this is probably all going to depend on the player used and its environment, and will be quite fragile too. Part of the problem here is that you are using border style '3', which is defined as "Opaque box around text" (in the 25.04 style editor shown as "Box as outline"). This seems to work ok if instead of embedding a newline in a subtitle you use separate subtitles for each line of text. That seems to get the vertical spacing between lines correct. But I'd probably instead suggest you use border style '4' for this sort of use. It is defined as "Alpha shaded box around text" (shown as "Box as shadow" in 25.04). That will give you a clean translucent box bounded around the entire subtitle instead of the 'stacked' boxes style 3 uses, which is less troublesome (and I personally think looks cleaner and easier to read). And that's the real crux of the matter here - kdenlive doesn't actually control how this will be rendered. The best we can do is provide a sane default style and suggestions for other use cases. We could argue there's a bug in the line spacing for border style 3 in the case you encountered, but we can't fix it in kdenlive, and even if we passed it on to MLT (which in turn punts that through ffmpeg, which I think in turn passes it to libass to handle), there's still other alternative renderers which may treat this differently in different players, and you'd need to fix them all to be able to rely on doing it the way you currently are. So I'm closing this as a bug in the kdenlive software, since we can't fix it there. But it might be worth opening a discussion on the forum about it, where people can share hints about what is known to work 'portably', which might turn into something worth including in a section of the main documentation. It is a 'real problem' for some use cases, we just can't fix it in our code, or easily and reliably in every other piece of code that would need tweaking. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497493] bug that causes the last subtitle to be on the center of the screen
https://bugs.kde.org/show_bug.cgi?id=497493 Ron changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|RESOLVED --- Comment #1 from Ron --- This was discussed here: https://discuss.kde.org/t/a-specific-subtitle-is-centered/26926/17 and appears to now be unreproducible, so I'm closing this bug - but if you can ever reproduce it with a current appimage, please reopen this with details and a minimal example project that shows the issue. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497209] Subtitle Editor: improvements to semi-transparent outline boxes/preview
https://bugs.kde.org/show_bug.cgi?id=497209 Ron changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Ron --- Please see the comments in https://bugs.kde.org/show_bug.cgi?id=461202 about the overlapping border issue and what can/can't be done about that. Re the separate preview issue also reported here. In the new code that should be landing soon there is no longer any "show preview" needed for the style editor - changes to any style immediately propagate to clips using it in the timeline, so you can 'preview' any clip you like just by moving the timeline cursor to it while editing a style. So I won't split this report and keep it open just for that since it's already 'fixed' in my dev tree and should land in an official release Soon. *** This bug has been marked as a duplicate of bug 461202 *** -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 461202] Subtitles : "Opaque background" option's problem
https://bugs.kde.org/show_bug.cgi?id=461202 Ron changed: What|Removed |Added CC||bibidib...@gmail.com --- Comment #2 from Ron --- *** Bug 497209 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 498870] Importing subtitles file (*.ass) - Kdenlive should check if subtitles have the same start timestamp and warn the user
https://bugs.kde.org/show_bug.cgi?id=498870 --- Comment #7 from Ron --- The inability to have two subtitles with the same start time isn't something fundamental to subtitle files or their renderers. You can craft such a file outside of kdenlive and it will work just fine in most if not all players. In theory kdenlive can even render it correctly. Disallowing that, and using 'layers' as a workaround for it, is an artificial limitation that was created to 'solve' the problem of how to handle perfectly overlapping clips in the timeline UI, and the problem of them being internally indexed by start time which didn't permit having them together in the kdenlive internal structures for manipulating clips. Using (ASS) layers isn't a good workaround for that, because most/all renderers will display two subtitles on different layers differently to how it displays overlapping subtitles that are on the same layer. If they are on different layers, then they will overwrite each other (without explicit re-positioning) rather than being cleanly shown together. (It does make some sense to show them that way on the UI timeline when subtitles overlap, in a similar way to showing any other overlapping clips on different tracks, just not to link that function to 'ass layers' which do something different, and almost completely opposite). All these problems have been addressed in my current dev branch, and importing or otherwise adding overlapping subtitles works correctly in the editor the same as it does in the renderer. So this bug is in the set that will be closed when that work is completed and lands in a release. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 502725] Glitches when rendering Arabic language subtitles
https://bugs.kde.org/show_bug.cgi?id=502725 Ron changed: What|Removed |Added Assignee|j...@kdenlive.org |kdenlive-b...@contact.dot-o ||z.net -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 500067] IDEOGRAPHIC SPACE (U+3000) in subtitles is converted to regular SPACE (U+0020) on loading
https://bugs.kde.org/show_bug.cgi?id=500067 Ron changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Ron --- Confirming I can reproduce this with the 25.04.01 appimage, but not with the code in my subtitle handling dev branch, which does already contain fixes for better preserving and round-tripping whitespace in subtitle files. So this should be fixed when those changes land in a release. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 502725] Glitches when rendering Arabic language subtitles
https://bugs.kde.org/show_bug.cgi?id=502725 Ron changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DOWNSTREAM -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 475947] Spellcheck for subtitles places corrections at the end
https://bugs.kde.org/show_bug.cgi?id=475947 Ron changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #3 from Ron --- Ah, thanks for the clarification. I can confirm that. Though it also doesn't always do it ... at least not in the code in my dev branch which does already have other changes to the subtitle editor, including a few regarding cursor position. Sometimes it replaces the word as expected, and sometimes it places the correction at the end. Will look into it, thanks for catching and reporting this. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 475947] Spellcheck for subtitles places corrections at the end
https://bugs.kde.org/show_bug.cgi?id=475947 Ron changed: What|Removed |Added Assignee|j...@kdenlive.org |kdenlive-b...@contact.dot-o ||z.net -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476630] Clip titolatrice - Title Clip
https://bugs.kde.org/show_bug.cgi?id=476630 Ron changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||kdenlive-b...@contact.dot-o ||z.net Resolution|--- |WAITINGFORINFO --- Comment #1 from Ron --- Does this still happen in the 25.04.1 release? If so can you please attach a minimal project file (preferably with just a title clip in it if that is sufficient to reproduce this) which demonstrates this problem. I've not seen this before, and can't reproduce it now, so something odd is happening if you still can. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 472607] title clip : we would like the ability to change colour for each word
https://bugs.kde.org/show_bug.cgi?id=472607 Ron changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||kdenlive-b...@contact.dot-o ||z.net Resolution|--- |WAITINGFORINFO --- Comment #1 from Ron --- This is already possible with whatever granularity you please. You just need to make each piece of text that you want to style individually a separate item in the title clip. Do you have some idea in mind for a simpler way to do that? At some point you need to divide up the things you want different attributes for, and this seems about as simple as that gets to me - but better suggestions are welcome. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 493271] Render crash when title clips with the typewriter effect are turned on.
https://bugs.kde.org/show_bug.cgi?id=493271 Ron changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||kdenlive-b...@contact.dot-o ||z.net Status|REPORTED|NEEDSINFO --- Comment #1 from Ron --- Can you still reproduce this problem with 25.04.1? And did you really not get a working video at the end of the render, or did you just see this warning (which does sometimes trigger spuriously)? If you didn't get a correctly rendered video, could you please attach a minimal project file and precise steps to induce the crash. Ideally a project file that doesn't need any external resources (eg. uses colour clips instead of an external video file) if it's possible to reproduce it that way. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 471257] Request for line spacing setting in Subtitle tool
https://bugs.kde.org/show_bug.cgi?id=471257 Ron changed: What|Removed |Added Resolution|--- |INTENTIONAL Status|REPORTED|RESOLVED CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #2 from Ron --- I'm afraid this isn't actually possible. We're now using ASS format subtitles by default, which are the most featureful for custom styling, but they still have no direct option to configure line spacing (and we don't control that to add them). If you really need that for some project, and need it using subtitles rather than a title clip, then you'll need to use one of the various tricks people have come up with to simulate it, and check that it works for all the players you need to support. Depending on exactly what you're doing, I'd either be looking at using explicit positioning tags inline in the text, or possibly creating a separate style for each line position that you want text on and using margins and/or layers to position it exactly as you want. Searching for "ASS subtitle line spacing" should turn up some other options for that, all with various pros and cons. But I'd still be cautious about relying on this, because it could all fall apart on a player using a font with different metrics to what you used for your explicit positioning or with a differently scaled screen size. You should probably think of subtitles a bit like old-school HTML. Any styling or positioning you might do really is just a hint for the player rendering them. It is totally free to ignore all of that and display it any way it (or the user configuring it) chooses. If you want "graphic artist" levels of control over exactly what is displayed, then you probably want to be using the title tool, not subtitles. Subtitles are mostly more focussed on putting control for if/how they are displayed into the hands of the viewer, not the creator. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 471257] Request for line spacing setting in Subtitle tool
https://bugs.kde.org/show_bug.cgi?id=471257 Ron changed: What|Removed |Added Assignee|j...@kdenlive.org |kdenlive-b...@contact.dot-o ||z.net -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 471257] Request for line spacing setting in Subtitle tool
https://bugs.kde.org/show_bug.cgi?id=471257 --- Comment #4 from Ron --- > Yeah it's fine, I simply use 2 tracks and manually off-setting their y > position now. That's probably close to the best you can do for most cases. > My bigger complain now is I can't find a way to save the style as a default, > which is unrelated to this topic. Right now, there isn't support for this in 25.04. You can set a style as the default for a layer, but even the "global" style is really still just local to the project. That should change soon, I'm actively working on improving subtitle support, so once that lands you'll be able to set system global and project default styles, and save styles into style libraries that are available for reuse in other projects. You'll find some of my original grumbles here: https://discuss.kde.org/t/24-12-0-subtitle-editing/27471 Which is probably a good place to follow up if you have other wishlist things to add in the near term. > Still hope there'd be a more straight forward way to handle this at some > point though, most editors probably don't know BBCode. If anything like that gets added, it's more likely to be Markdown, to be consistent with the 'rich text' support in other Qt widgets - but even that mostly seems like overkill. There's buttons above the edit box for one-click adding the most portable and commonly used style options. For anything else, you really do need to understand a bit about ASS tags and their limitations and that what you do with them may not work on all players - so hiding that behind other markup seems like a "promise we can't keep" trap, where using it may or may not work like it appears to while you are editing. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 443767] [Request] Add new functionality to make the (sub)title spread vertically
https://bugs.kde.org/show_bug.cgi?id=443767 --- Comment #5 from Ron --- > The proper visual apprearence of the vertical text layout are already > documented by Unicode Consortium and W3C, as well as other official > standards. Which is nice, but if no player implements support for that in subtitles, it's not of much practical use to us. Can you point to a non-browser player that supports WebVTT vertical cues? (or even a browser based one?). Of the ones I'm seeing that support any WebVTT cue properties at all, none implement the vertical property. Right now, ASS subtitles are basically the sweet spot in the venn diagram for feature richness and player support. They aren't a perfect solution for every use case, but they let you control more things, more portably in more players on more platforms *today*. It doesn't matter what we support if nothing that people try to play it in will make it look like it did when they edited it. We can't lead the players in this or force them to implement it, we need to make things that they *can* play. > If Qt have no support for vertical text, or there's something difficult to > make use of, > you have to write something new or find out a library that could help. We don't *have* to do anything. But kdenlive uses Qt for its UI, so that's one more thing we're constrained by. Another is that few fonts have metrics for vertical text, so even if you did try to lay them out in that direction, the result will still be indistinguishable from sticking a newline between each character. And no matter what we do there, it still doesn't make players support this for subtitles. > Anyway, this is not only "graphic art", but also "text support". Even if > Adobe software can do this for titles. > If you got this text support, you'll pave the way do so for graphic art. You're missing my point, adobe isn't doing this for *subtitles* either. And they are also individually placing individual characters in their more 'advanced' modes of text handling, not laying out text 'as text' according to the metrics of the font designer. Which totally falls in a heap in the case of subtitles, where the player and/or its user can totally override your choice of font and font size and colour and position, and just about everything else. This puts what adobe is doing in the realm is graphic art, and is something in a long list of things that it would be nice for a future *title* tool to be more powerful at enabling simply. It's just never going to be possible with *subtitles*, sanely or at all, until there's actually a widely supported and implemented mechanism for that. And I'm not seeing that on any visible horizon right now. "Titles" and subtitles are two quite different things. With different uses and and strengths and weaknesses. They aren't interchangeable for every use case just because they both can include 'text'. So if you want to talk about things that it might be nice for a future *title* tool to do, that's probably a good discussion to have in the open on the user forum https://discuss.kde.org/tag/kdenlive/l/latest to refine a sense of exactly what people might really want from it and have a real use for, to guide its design. That's fertile ground to grow feature requests in. But if you want to insist we do this with *subtitles*, then for the currently foreseeable future it's probably a "can't fix" problem. Because it's not about whether kdenlive "supports it", it's about whether any player can play it. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 475947] Spellcheck for subtitles places corrections at the end
https://bugs.kde.org/show_bug.cgi?id=475947 --- Comment #5 from Ron --- It did for me at first too, until I started poking at correcting words in the middle of a sentence and moving where the text cursor was when the correction was made - and I didn't see an immediately obvious pattern as to when this bug did or didn't trigger. There's some fancy footwork that goes on in the background which moves the cursor around internally for various reasons, so my first blind guess is it's something to do with it being in the wrong place when this fires. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 476630] Clip titolatrice - Title Clip
https://bugs.kde.org/show_bug.cgi?id=476630 Ron changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 504129] Subject: Incorrect Text Rendering for Hindi/Devanagari Subtitles in Kdenlive (Character Reordering Issue)
https://bugs.kde.org/show_bug.cgi?id=504129 --- Comment #2 from Ron --- And this is not specific to windows, I'm seeing it in both the 25.04.1 appimage, and my bleeding edge dev tree. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478905] [Feature Request] missing edit function for subtitles
https://bugs.kde.org/show_bug.cgi?id=478905 Ron changed: What|Removed |Added Assignee|j...@kdenlive.org |kdenlive-b...@contact.dot-o ||z.net -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478905] [Feature Request] missing edit function for subtitles
https://bugs.kde.org/show_bug.cgi?id=478905 Ron changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||kdenlive-b...@contact.dot-o ||z.net Status|REPORTED|NEEDSINFO --- Comment #1 from Ron --- I'm not really clear on exactly what you're wanting to do here? It's already possible to group subtitle clips the same as any other clip. Do you need something more than that? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 475947] Spellcheck for subtitles places corrections at the end
https://bugs.kde.org/show_bug.cgi?id=475947 Ron changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||kdenlive-b...@contact.dot-o ||z.net Resolution|--- |WAITINGFORINFO --- Comment #1 from Ron --- I can't reproduce this with current plasma. Right clicking on "check spelling" gives me a dialog with a 'replace' option, which if clicked correctly replaces the word that was checked. Do you still see this with current releases? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 488217] Allow importing of embedded subtitles
https://bugs.kde.org/show_bug.cgi?id=488217 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net Assignee|j...@kdenlive.org |kdenlive-b...@contact.dot-o ||z.net -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 443767] [Request] Add new functionality to make the (sub)title spread vertically
https://bugs.kde.org/show_bug.cgi?id=443767 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #2 from Ron --- This isn't really something you're going to be able to do with subtitles. For those we're constrained by what the subtitle formats themselves support, and there is no option for vertical direction text that I'm aware of. With ASS you can rotate the text, but that's not the same since it also rotates the glyphs as well as the text direction. Probably all you can do if you really, really, want this, is to put an explicit newline after each character you want stacked vertically. Even with title clips, where we have a bit more control, I'm not sure Qt has direct support for vertical text. Is there an input method and text widget which supports that for the languages which can be written this way? Or is what you want more in the realm of "graphic art" than it is "text support"? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 450964] double subtitle showing in render
https://bugs.kde.org/show_bug.cgi?id=450964 Ron changed: What|Removed |Added Resolution|--- |NOT A BUG Status|CONFIRMED |RESOLVED CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #5 from Ron --- I'm going to close this report, because it's not actually a bug in kdenlive. The problem is you've both burned in the subtitles at render time and are rendering them in the player by virtue of having the external subtitle file present and enabled. And I'm not sure there's much we can do to catch that for you, because both options are desirable for different user groups. We might be able to document it, but really it's just one of those lessons you need to learn about how all this works if you're working with subtitles. Re "it would be good if the subs could have a transparent selectable background color" that's possible now with ASS format subtitles in recent releases. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 488217] Allow importing of embedded subtitles
https://bugs.kde.org/show_bug.cgi?id=488217 --- Comment #2 from Ron --- It's possible to do this manually, if you extract the subtitle stream kdenlive will let you import it, but I agree it would be nice to have the ability/option to somehow do that automatically. It's a little bit tricky because subtitle files aren't bin objects like clips are - they exist as tracks on the timeline. So where to place them on the timeline when importing is going to depend on where you place the clip they were embedded in and/or which parts of it you actually use in the timeline. But I'll give this some though about what we might sanely do. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 490595] Automatic subtitle is not working, giving invalid SRT error
https://bugs.kde.org/show_bug.cgi?id=490595 Ron changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||kdenlive-b...@contact.dot-o ||z.net Status|REPORTED|NEEDSINFO --- Comment #1 from Ron --- Is this still a problem with the latest releases? It doesn't appear to be a problem with kdenlive as such, but does seem to indicate the speech recognition isn't working correctly for you. There's been quite some work to improve on that in the last few releases. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 504129] Subject: Incorrect Text Rendering for Hindi/Devanagari Subtitles in Kdenlive (Character Reordering Issue)
https://bugs.kde.org/show_bug.cgi?id=504129 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #1 from Ron --- Ok, this is an interesting one. It would be nice to have a minimal subtitle file with *only* some examples of text that is rendered wrongly, for those of us who don't read Devanagari and can't immediately see what is wrong. The first text I could spot that looked off was this one: 00:00:02,850 --> 00:00:03,150 किरणें We we convert, apparently correctly, to: Dialogue: 0,00:00:02.84,00:00:03.14,Default,,0,0,0,,किरणें before passing it to MLT for rendering. It looks ok in the subtitle editor widget text box, and looks ok rendered in vlc, but for some reason, somewhere in the pipeline after we pass it to MLT, the 'f' ि (for want of better knowledge how to type that glyph part), which seems to be a 'combining character', gets combined one character to the right, which seems to be what's shown in the OP examples. It seems vim struggles a little with this too, moving the combining part around when the cursor is on that character. So this would seem to not be an issue with anything we're doing in kdenlive, but is an issue in the rendering pipeline on the other side of what we pass to MLT. And I guess the next interesting question is whether it is somehow specific to the particular codepoints in use here, or if it happens with other combining characters too. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 504129] Subject: Incorrect Text Rendering for Hindi/Devanagari Subtitles in Kdenlive (Character Reordering Issue)
https://bugs.kde.org/show_bug.cgi?id=504129 Ron changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 505785] New: Corrupt App
https://bugs.kde.org/show_bug.cgi?id=505785 Bug ID: 505785 Summary: Corrupt App Classification: Applications Product: kmymoney Version First 5.1.0 Reported In: Platform: macOS (DMG) OS: macOS Status: REPORTED Severity: normal Priority: NOR Component: packaging Assignee: kmymoney-de...@kde.org Reporter: taffeta.12budg...@icloud.com Target Milestone: --- SUMMARY Attempt to open app results in corrupt popup and request to move to trash STEPS TO REPRODUCE 1. Downloaded kmymoney-5.1-3138-macos-clang-arm64.dmg file from https://cdn.kde.org/ci-builds/office/kmymoney/5.1/macos-arm64/ 2. Opened DMG and moved app to Application folder 3. Open app resulted in corrupt popup OBSERVED RESULT Corrupt app message popup EXPECTED RESULT App to work SOFTWARE/OS VERSIONS macOS: 15.5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497008] Title Clip: unexpected behavior when resizing ellipse
https://bugs.kde.org/show_bug.cgi?id=497008 Ron changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|WORKSFORME |--- Ever confirmed|0 |1 --- Comment #4 from Ron --- (In reply to vp.accounts from comment #3) > you are correct, there is another crucial step to reproduce, which I didn't > notice initially, you have to set the ellipse border to anything higher than > zero. The higher the border value the more visible is the effect, try for > instance with 14 or something, with 1-2 it is very light. With this extra > step I can reproduce on all platforms with 25.04.2 Ok, I can see that. Something weird is tangled in the math. Any movement of the mouse (in any direction) while a bounding box border is grabbed causes the orthogonal dimension to grow. It's probably a mix of recomputing the bound size without the border width then adding the border to that. Should be reasonably easy to find and fix the next time someone is in that code. Workaround in the meantime is to size your ellipse without a border, then configure the desired border width as the final step. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497008] Title Clip: unexpected behavior when resizing ellipse with border width > 0
https://bugs.kde.org/show_bug.cgi?id=497008 --- Comment #7 from Ron --- (In reply to vp.accounts from comment #6) > If you can tell me where to find the relevant code I can try to have a look. > I suppose I can get it to build on linux without too much effort Start here: https://invent.kde.org/multimedia/kdenlive https://community.kde.org/Kdenlive/Development https://invent.kde.org/multimedia/kdenlive/-/blob/master/dev-docs/build.md You'll need a reasonably up to date distro to provide the needed versions of Qt/KDE dependencies. [Debian Trixie (in freeze to be the next stable release) is fine, but Bookworm (current stable release) doesn't have backports of them]. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 503634] Titler, typewriter, rendering videos results in crash
https://bugs.kde.org/show_bug.cgi?id=503634 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #9 from Ron --- (In reply to NavyEOD_24 from comment #6) > I just figured out the error and it's annoying, but it took me this long to > find it XD > In a title clip editor, there's the typewriter effect. This effect, even on > the newer 25.04.02, will crash the entire render regardless of any other > changes. Once you disable this effect, the render will complete and your > video is finished. I can't reproduce this with the 25.04.2 appimage and a minimal test project with only a title clip generating text with the typewriter effect. It renders and plays with no error at all. I am running this on a system with a UTF-8 locale (as all modern linux systems should be using these days). Mine with LANG=en_AU.UTF-8 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 492309] Titler, typewriter, unuseable - Fails to render.
https://bugs.kde.org/show_bug.cgi?id=492309 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #4 from Ron --- (In reply to emohr from comment #2) > That means we have 2 bugs here: > > 1.Title typewriter is not correctly set to UTF-8 > 2.Rendering: If "overlay" is let on default, then UTF-8 is not set > correct. > > Is my understanding correct? I think its the user's *systems* that are not configured to use (or able to use?) a UTF-8 locale. The typewriter shouldn't be messing with that at all, but there appears to be some conflict with Qt and the system using a non- UTF-8 locale. Which if that is a hard dependency for current Qt probably isn't something we can fix (or anything we are doing wrong). Users having this problem will need to ensure they have a UTF-8 locale available or (probably preferably in the modern multi-lingual world) set as the default on their system. The "Timestamps" warnings are just warnings and cause no problem, they are a red herring here. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 503634] Titler, typewriter, rendering videos results in crash
https://bugs.kde.org/show_bug.cgi?id=503634 --- Comment #13 from Ron --- (In reply to NavyEOD_24 from comment #11) > Can confirm that, even from a small 30 second clip, the typewriter effect on > text will crash the render in 25.04.2 on Windows 11. Is the final video actually corrupted? Or is it fine despite the message saying it might be? I remember seeing a problem a while back where failure was "sometimes" being reported after a successful render, but never dug deeper because it wasn't actually causing any harm aside from the message. And is your typewriter title right at the end of the timeline? It seems hard to imagine that it is actually causing a crash "right at the end" if it is rendered somewhere in the beginning or middle (though it is possibly enabling something which separately creates an issue on windows - like some Qt operation trying to switch locales). -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 506414] How to disable auto creating of subtitle track when dragging?
https://bugs.kde.org/show_bug.cgi?id=506414 --- Comment #6 from Ron --- (In reply to Jean-Baptiste Mardelle from comment #4) If you're keen to have a fix in for 25.08, maybe the MR I just pushed will be a bit safer than trying to remove this completely? It's cherry picked from my WIP branch and implements the safety catch I noted earlier. With this, dragging a subtitle clip down won't create a new layer unless you hold while dragging. Which should stop it happening by accident, but still leaves it possible to do if someone really has come to like and use it (with the benefit that it might shake them out to report "it's broken" before they learn the real change, and we can find out why they are using layers in the first place). I do think making 'layers' such a normal part of adding subtitles was a misfeature for quite a few reasons, (they behave somewhat the opposite to how they are displayed in the timeline might suggest), but the current implementation made it the only way to have separate subtitles with the same start time, so it's a bit of a necessary evil for some until we get the larger structural changes in to remove that limitation. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 506414] How to disable auto creating of subtitle track when dragging?
https://bugs.kde.org/show_bug.cgi?id=506414 --- Comment #3 from Ron --- (In reply to louis from comment #0) > When dragging subtitles around I keep accidentally causing kdenlive to create > an extra subtitles track > that I then have to delete. Driving me nuts. (Dragging video tracks > thankfully doesn't do this) Yeah, that's adding an extra layer, which in the current implementation is a workaround for it not otherwise being able to have two subtitles with the same start time. Accidentally doing that so easily really annoyed me too :) I'd initially added a safety catch to it (so that you needed to hold down shift to create a new layer), but the way the new implementation that I've been working on is looking, it shouldn't actually be needed anymore at all (since it allows subtitles to overlap just fine), so it will likely just go away entirely. My list of initial grumbles, which got me working on this in the first place, is here: https://discuss.kde.org/t/24-12-0-subtitle-editing/27471 so if there is anything else on your wishlist for improvements with this, please feel free to add or discuss them there. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 497008] Title Clip: unexpected behavior when resizing ellipse
https://bugs.kde.org/show_bug.cgi?id=497008 Ron changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||kdenlive-b...@contact.dot-o ||z.net Resolution|--- |WORKSFORME --- Comment #1 from Ron --- I cannot reproduce this in the 25.04.2 appimage. In both cases dragging a side of the bounding box moves just that side of the bounding box and the shape then fills the resulting box. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 486310] Add Clip or Folder dialog window too small
https://bugs.kde.org/show_bug.cgi?id=486310 --- Comment #18 from Ron --- (In reply to chocolateimage from comment #17) > I noticed after testing the AppImage (direct builds seem to get the > previously saved settings), that the dialog now opens in the correct size, > but only after resizing it after the first time, which still is small: Doesn't that go back to my earlier comments (https://bugs.kde.org/show_bug.cgi?id=486310#c9) The first time it's opened it's sized according to the default size hint logic, but with your fix any user change is now correctly persistent? The difference between AppImage and other builds is that the AppImages use a separate config instead of stomping on the 'system' one. (cf. kdenlive-appimagerc vs kdenliverc in ~/.config). -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 486310] Add Clip or Folder dialog window too small
https://bugs.kde.org/show_bug.cgi?id=486310 --- Comment #19 from Ron --- Ok, looks like this patch wfm. I'd been able to reproduce what Bernd was seeing (it worked ok in my primary monitor but not with the kdenlive window in my secondary), but with this patch it seems to work as expected in both. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 507630] [Perf] Viewport animation on Title Clip with large amounts of text extremely slow to play and render
https://bugs.kde.org/show_bug.cgi?id=507630 Ron changed: What|Removed |Added CC||kdenlive-b...@contact.dot-o ||z.net --- Comment #1 from Ron --- You're going to need to provide an actual project file with your actual settings, preferably with just a colour clip instead of an image if that also shows the problem (since then the project can be self-contained with no external resources, and if that doesn't show the problem that's good information too). I tried to create one with your recipe and the time to render with the animated title is only about 5% slower than just rendering the image track alone (and rendering just the title without the image is considerably faster than for the image), which fits well within what I would consider reasonably expected. So we need the actual test you're running before we can say for sure whether it's something different about what you're doing, or something different about your system. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 507630] [Perf] Viewport animation on Title Clip with large amounts of text extremely slow to play and render
https://bugs.kde.org/show_bug.cgi?id=507630 --- Comment #3 from Ron --- (In reply to rich from comment #2) > If you are experiencing significant slowdown I'm not, and I haven't yet found anything that does. And nobody else has reported a similar issue. So if you can't or won't produce an example that you claim demonstrates this, which others can test, then I'm not going to waste any more time on this until someone can show how to actually reproduce it. -- You are receiving this mail because: You are watching all bug changes.
