Animatd Titles not working with Blender 2.90.1 Win10

[rexdk]

As requested by @ferdnyc in #3740, I'm reporting my experience with
OpenShot-v2.5.1-dev2-1602471705-414a2cda-12ddb3df-x86_64
the last daily build on 11Oct20. Win10, Blender 2.90.1

I'm afraid it didn't work - I got the same rotating blue 'wait' cursor, which persisted even when I esaped from the Animated Titles dialog. The same as before.

I found this daily build very unstable - it kept failing to update properties and was very slow/hung with some clips. As I am mid-project I re-installed a daily build from July which is fine. But it means I can't currently do any more tests - sorry

[sc0nway]

@rexdk Have you tried the updates in the latest Daily Build? @ferdnyc updated the animated titles and I've been testing on Windows 10 and macOS Catalina with Blender 2.90.1.
https://github.com/OpenShot/openshot-qt/releases/download/daily/OpenShot-v2.5.1-dev2-1602834910-414a2cda-12ddb3df-x86_64.exe

[rexdk]

Thanks - I tried it on the 13Oct20, because it was reportedly fixed on 11Oct20. If there have been further changes since then this is not avalid issue, and I'll close it

[ferdnyc]

@rexdk Yeah, On 2020-10-11 I merged a fairly substantial rewrite of the Blender support, which turned out to have some issues with handling of path strings (particularly on Windows); that prompted a second PR merged 2020-10-14, and then a followup to fix one outstanding issue that was merged a day later.

I'm hoping that as of the 2020-10-15 changes, things are back to a good state for the Animated Titles support — but I'm definitely eager to hear more feedback to confirm (or dispute) that. Any testing, particularly on Win/Mac platforms, is greatly appreciated.

That being said, if you're in the middle of an active project — particularly a time-sensitive one — I'd encourage you to stick with the version that's working for you rather than taking the risk of destabilizing your own workflow. The time for testing is when those sort of pressures aren't looming; other people can kick the tires on the new build(s) for now.

[sc0nway]

@ferdnyc I have been testing the updates that you merged on Windows and macOS since the 15th and can confirm that the merged fixes restored functionality to animated titles.

[ferdnyc]

@USATechDude That's great to hear! Thanks again for all of the valuable feedback throughout. Now I can move on to breaking other parts of OpenShot. 😉

(Actually, there's already a contender for that: PR #3630, which I just merged yesterday, added something requested by @CPUhead in #3492 — the ability to drag a folder into Project Files and import its entire contents. That's a feature that could definitely use more testing. See #3492 (comment) for much more information.)

[sc0nway]

@ferdnyc I tested #3492 on Windows 10, macOS Catalina 10.15.7, and Debian Linux 10.6. My comments and observation begin at this point.

[rexdk]

@ferdnyc I've finished my project (more than 40 tracks and 28 clips with simultaneous synchronised screen movement!) So now I've tested the latest 24Oct20 build, and it does recognise Blender 2.90.1, and all works - thank you.

There is one issue - which is that if Blender is not found, the thing just hangs. Because the stated goal is 'easy to use' there needs to be a message telling the user what the problem is ("install Blender and set the directory, dude!") I don't think that was part of what you were trying to solve, so do I need to raise that as a separate issue for later?

I noticed that the sequences are rendered at 25fps, even though my profile is 30fps. I guess that is intentional and OK?

Thanks

[rexdk]

@ferdnyc That's Win 10 of course.

( @USATechDude for info )
There's another point: it looks to me as if the animated titles are rendered and then always stored in the /blender folder. Do they get stored with the project when the project is saved? I suspect not. Many people will keep a project together in a folder, in which case the sensible management would be to move the blender rendered pngs there. It's a bit of a faff, but could save grief if no-one has pointed it out. Something for the detailed manual probably - will write it up it in due course

[ferdnyc]

@rexdk

There is one issue - which is that if Blender is not found, the thing just hangs.

Yeah, whoops. #3790 will fix that, thanks. Certain types of error were preventing the error message dialog from being shown.

There's another point: it looks to me as if the animated titles are rendered and then always stored in the /blender folder. Do they get stored with the project when the project is saved? I suspect not.

That's been a tricky subject in general, but basically they should end up with the project file.

The way things work now is:

1. Initially, $HOME/.openshot_qt/ is used as a scratch space for project assets. In part that's because, if you have an unsaved project, that's the only place they can possibly be kept. (We don't require that a project be saved before generating assets.) But I believe even if you've already saved the project, they may end up there during the first session.

2. When the project is saved as ProjectFileName.osp, a directory ProjectFileName_assets gets created next to it, and all of those working files from the home directory (blender/, titles/, and thumbnails/) are transferred there.

3. When you load that project file into OpenShot during subsequent sessions, those _asset folder paths get set as the working directory, so then new files should be generated directly into those paths.

I believe that's the current logic, at least. It's been changing a lot recently.

[ferdnyc]

There's also the open question of whether all of the assets properly get transferred if you load a project file with existing assets in one location, but then save the project in a completely different location.

I believe that all works correctly now. In fact, because of the previous issues, IIRC the code errs on the side of overkill. The assets can't be transferred per se — it would invalidate the old project file (which still exists), to remove them from the previous location — so everything just gets copied to the new _assets folder.

We also never delete assets even if they're no longer used in the project. Which is safer, sure, but after doing some drag-and-drop import testing with one project only to discover that it now has an assets directory containing 3500 thumbnail files that will be there forever, I've realized we may need to do some housekeeping on at least the thumbnail directory. (Thumbnails can always be regenerated, after all...)

[rexdk]

Ah yes, it does seem to do good housekeeping when the project gets saved. The .openshot_qt/blender folder gets cleared out, and the png sequences saved with the project. In fact it also saves any titles that have been rendered and then removed from the project - definitely safe, as you say ;)

[ferdnyc]

Ah yes, it does seem to do good housekeeping when the project gets saved. The .openshot_qt/blender folder gets cleared out,

Yeah, the home-dir working spaces we clear out, because the files will have been copied to the project _assets dir when it was saved. (And if it wasn't saved, then there's no reason to keep them.)

But once files have been copied out "into the world", there's always the possibility (however remote) that some project file somewhere — perhaps not the one currently loaded — still references those files.

and the png sequences saved with the project. In fact it also saves any titles that have been rendered and then removed from the project - definitely safe, as you say ;)

*nod* Those are even trickier, because OpenShot doesn't make any distinction between imported files that it created on the user's behalf, and files that were imported from elsewhere.

Meaning, the Title Editor and Advanced Titles tools know how to create files and import them into the project. They put those files in a special place where they'll be managed when saving the project file. But as imported files, when they're just sitting in the Project Files list, there's nothing to differentiate OpenShot-generated files from any other imported content.

(In fact even things that seem like they are aware of the files' origins really aren't. You can right-click ANY imported SVG file and choose "Edit Title" — it usually won't work very well, if it's not a file created from a title template, but you can do it. The only check the "Edit Title" action makes is that the filename ends in .svg.)

Obviously, in general it wouldn't be OK if deleting a file from the Project Files list deleted the actual FILE, so... it doesn't. Even when OpenShot created the file.

And actually, I just remembered the even bigger reason we have to leave old files in place, and it's also a reason that any sort of housekeeping is pretty much off the table.

OpenShot stores undo history in the project file, even between sessions. (Something I am firmly against, because IMHO it complicates so many things for incredibly little value. Case in point:) This means that even if a file isn't currently used in the project data, it may still be referred to in a HISTORY entry. If we were to delete it, and the user subsequently chose to Undo the deletion action, the file reference would be restored to the project.

At which point, OpenShot would promptly crash, because once it's accessed a particular file it makes lots of fragile assumptions about that file always being available, unfortunately. (You can also crash it by importing a file directly off a thumb drive, then disconnecting the drive while OpenShot still has it open. Try it, it's fun!)

[rexdk]

Ah - that probably explains #3435 then. It does seem a daft decision to store undo history in the project file. No-one else does.