I actually laughed when I read that. I really don’t think anyone’s going to look at a menu moving by itself as a cool feature. I certainly didn’t. I thought something was wrong with my mouse. In fact, when you first said that you couldn’t reproduce it I once again thought that maybe something was wrong with my mouse. If it can be fixed it really should be because that’s not something that anyone’s ever expecting with any program.
13) I just tested today’s build and there is some major regression going on. It’s not letting me start a project by dragging directly to the timeline. When I try to do that it opens it in the player with nothing in the timeline instead. Then when I try to then drag from the player to the timeline it crashes. If I drag to the playlist then it freezes. Playback is really bad because the audio is crackling the entire time. Finally, it’s automatically creating mlt files where the source video is from for some reason. Basically it’s unusable.
Can’t export from beta version. Reopening does nothing. If I copy the file to C:/Users/user/AppData/Local/Temp/ the issue is resolved and the rendering starts.
[Debug ] MltXmlChecker::check begin
[Info ] MltXmlChecker::check decimal point ‘.’
[Error ] MltXmlChecker::checkUnlinkedFile file not found: “C:/Users/user/AppData/Local/Temp/videofile-name.mp4”
[Debug ] MltXmlChecker::check end
This isn’t a Shotcut problem. You probably dragged a video or image directly from a web browser to Shotcut. When the web browser cleaned itself up by clearing the temp folder, the Shotcut project broke. This is to be expected. Web media should be downloaded or copied to a real project folder rather than being used directly out of a web cache or temp folder. Those folders can be cleaned up at any moment and break a project.
Possible regression… When I work on a 4K project for a bit, it takes 9 GB of RAM for the frame cache. (This system has 16 GB.) If I start an export, Shotcut retains all 9 GB rather than releasing cache, and now my export is throwing a “system running low on memory” error that it didn’t used to throw. melt.exe only has 5 GB to work with now.
I am not able to reproduce this unless I intentionally remove a file in the project. I would need more information like from where did you move it? And was this an unsaved project or saved project? If saved, where was it saved? Are you exporting from timeline?
14) Maybe this one’s for @brian, but on the latest build, when you hit the F key after selecting a clip then type the name of the filter you want the highlight that normally appeared on the first item on the list doesn’t automatically appear now. You have to now press down in order to activate the highlight otherwise no filter will be selected if you just press Enter.
15) With Size, Position & Rotate, let’s say you pick Left on Horizontal Fit and Top on Vertical Fit and zoom out it will be placed on the top left. But if you leave it there zoomed out then change it to let’s say Right on Horizontal Fit and Bottom on Vertical Fit it doesn’t change position. Is that on purpose? Because with Text: Simple when you make changes to the Horizontal Fit and Vertical Fit parameters the text placement changes right away
16) With the Crop: Source filter it goes back to full picture when you take the pixel count towards the end of any one of the parameters:
Also it’s clashes with Preview Scaling when you do the same:
Fair enough, thanks for checking. If I close Shotcut, restart it, open the project, and immediately export, then Shotcut takes up only 1.5 GB of RAM. The rest is available to melt.exe. So I assumed the difference from 1.5 GB to 9 GB would be frame cache from editing. If it makes a difference, there are a lot of speed change effects in this project.
14) Maybe this one’s for @brian, but on the latest build, when you hit the F key after selecting a clip then type the name of the filter you want the highlight that normally appeared on the first item on the list doesn’t automatically appear now.
This is a side effect of the fix to prevent automatically scrolling the filter list. There are no plans to address this.
15) With Size, Position & Rotate, let’s say you pick Left on Horizontal Fit and Top on Vertical Fit and zoom out it will be placed on the top left. But if you leave it there zoomed out then change it to let’s say Right on Horizontal Fit and Bottom on Vertical Fit it doesn’t change position. Is that on purpose?
This is intentional and will not be changed. Since the rewrite introducing Rotate, the fit options also serve as the anchor points for Zoom and Rotate. Text: Simple is different because it does not have Zoom or Rotate. Here, it is the classic options that determine how to fit a rectangle inside another rectangle - the same as SPR when Size mode = Fit.
I checked multiple .mlt projects for the issue and the error only occurs with files that has:
timewarp
also if I change the speed property in Shotcut to smth else I can export again until I close the program, and if I try to reopen the project after (saving) and export it again the issue occurs.
Confirmed. There is an issue here. I started a project with the nightly build from two days ago and in that project I took one small clip and slowed it down in Properties to 0.25 and I reused that slowed down clip 3 times. I was able to export the project in that same session but when I closed it and opened that mlt file with the nightly build from 2 days ago I got the exact message that @dailylolrecap posted up when I pressed the Export button. It wasn’t until I deleted all 3 instances of that clip that I slowed down to 0.25 that I was able to export. The only way I was able to export the mlt file with the slowed down clip after closing it was opening it with v20.11.28.
So there is some big problem happening here but I don’t know what the exact trigger for it is because when I tried to reproduce it by starting a new project, making sure to slow down a clip and opening the project after saving it I could export it. So something along with slowing down the clip in Properties is causing the error message in export.
Wow. You are thorough. Nothing gets past you. Dan is right that this is a side-effect of the change. But I chose not to restore that behavior because I prefer this new behavior. I have inadvertently selected the wrong filter too many time by accidentally hitting “Enter” by habit just like I would when searching in Google.
Your issue is not related to the MLT upgrade. Actually, every build we provide includes the latest unreleased MLT because we make MLT as well. When that appears in the release notes, it is more-or-less a passing note about a new MLT release and a hint to Linux distributions that make their own build. Your issue is a regression in the following Shotcut bug fix, which will be reverted before release if we do not reproduce and fix it confidently in a low risk manner:
I really don’t think anyone’s going to look at a menu moving by itself as a cool feature. I certainly didn’t. I thought something was wrong with my mouse. In fact, when you first said that you couldn’t reproduce it I once again thought that maybe something was wrong with my mouse. If it can be fixed it really should be because that’s not something that anyone’s ever expecting with any program.
