Bug Report v19.10.20

19) I tried applying the Crop: Source filter with an image that has a resolution of 975x808 and Shotcut crashed. Here’s an image with that same resolution to test out.

20) There is an issue with certain kinds of images when working with the Fit mode in Size and Position and using Preview Scaling. The size keeps changing in all Preview Scaling modes. Here is a demo.
And here is the image I was using in that demo to test out:

21) Creating transition clips by stretching one clip onto another will eat away at the footage of the second clip when the transition clip is undone by pulling back the transition. In this demo I have the second clip I am going to make the transition clip start after the 30 second mark. I keep creating and undoing the transition clip and by the end the second clip ends up before the 30 second mark. I did the demo with the main clip being on the right and the second clip on the left but the issue still exists if the clips are vice versa.

22) In the Fill mode in Size and Position, manually changing one of the values in Size will not automatically modify the image. The rectangle control will but the image will not follow unless you touch the rectangle control. Demo.

23) gifs are not being accepted in Shotcut. If you try to bring in a gif Shotcut will crash.

I prefer that you not keep adding to a list like this. It is no longer tracking version correctly but makes tracking and following difficult. I prefer a separate post for every item except in a beta thread.

I just found this as well when looking into Bug with Crop: Source. I will track it there.

23 ) gifs are not being accepted in Shotcut. If you try to bring in a gif Shotcut will crash.

This is a new bug in version 20.04 on Windows with animated GIF. You can workaround this today by removing Shotcut\lib\mlt\libmltgdk.dll from your installation. It is high priority, and as a last resort I can simply remove that unnecessary module in the Windows build.

I was only adding to this list because some items here weren’t addressed yet and this topic has a time limit on when it will close after the last reply. I don’t know if removing that time limit on all bug report threads is fine for you but it would make sense for tracking purposes.

I have no problem making separate threads for each bug but if I find several in a short amount of time like more than 5 is it fine with you that I post those several issues in the first post with the version number as the title of that thread like I’ve done before? This to avoid cluttering the message board.

This is fixed for the next release.

this topic has a time limit on when it will close after the last reply

Do not worry about this. I or Brian can always reply even after closed or reopen if we want. All posts in this category are not tracked like a full-on bug tracker. If that is what you want use GitHub. For here, I bookmark topics that I want to come back to. There is no guarantee that I or any group of people can track every post in an active forum to ensure things are categorized correctly, followed up, marked solved, closed, etc.

Bug reports from many users often require further qualification because of either user error or missing steps to reproduce. This forum is a good place to qualify those reports. @DRM your bug reports are usually high quality and reproducible. The github bug tracker might be better suited for your bug reports. It would also provide place for easy follow up if an issue has not seen attention for a while.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.