OpenShot / openshot-qt

OpenShot Video Editor is an award-winning free and open-source video editor for Linux, Mac, and Windows, and is dedicated to delivering high quality video editing and animation solutions to the world.
http://www.openshot.org
Other
4.24k stars 528 forks source link

OpenShot-2.4.4 ,2 min start hang #3041

Closed brcisna closed 4 years ago

brcisna commented 4 years ago

Describe the bug OpenShot-2.4.4 2 min start hang

Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior A clear and concise description of what you expected to happen.

System Details

Log Files

Exception / Stacktrace No stacktrace found in log files

Screenshots (Optional) If applicable, add screenshots to help explain your problem. You can include screenshots by copy/pasting them on GitHub or dragging-and-dropping into the GitHub page. All images are public, so please don't post screenshots containing personal information.

ferdnyc commented 4 years ago

Hi @brcisna , would you mind downloading the AppImage build from my Google Drive folder and letting us know if you have the same issue with that build?

(It's basically the same as the one you tried, just a couple of weeks older and with a different set of libraries bundled into the package. I'm trying to track down instances where issues like the one you're seeing may be caused by certain shared library files being present in the AppImage when they shouldn't be there. Thanks!)

brcisna commented 4 years ago

Hello Frank,

Thank You for helping out on this. This build of OS opens immediately as expected. The things is this version along with the 'dailybuild' that i downloaded a few days ago,, when reading in an already built project everything looks correct other than the titles that are added are not read,,unless i do an edit,,and change the default font. I do almost all old historical videos comprised of many photos,,so i have tons of titles added to each video i build for example. Not sure why the build of OS doesnt read in the titles they are just blank until i do an edit,,and change the fonts on each. If i close this version and open the 'downloadable' 2.4.4 build everything is recognized,,,but,,i do get the two minute hang on startup,,I can try and do a screen capture when i try and open the hanging version,,of OS<,,but in the terminal it says many lines of fonts,,,fonts,,, fonts,,then finally opens just for a bit of info?

Thank again, Barry Cisna

On Tue, Oct 15, 2019 at 6:09 PM Frank Dana notifications@github.com wrote:

Hi @brcisna https://github.com/brcisna , would you mind downloading the AppImage build from my Google Drive folder https://drive.google.com/open?id=1bqSudb-MITqqNJoJrKZub1WHuN-eoicN and letting us know if you have the same issue with that build?

(It's basically the same as the one you tried, just a couple of weeks older and with a different set of libraries bundled into the package. I'm trying to track down instances where issues like the one you're seeing may be caused by certain shared library files being present in the AppImage when they shouldn't be there. Thanks!)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/3041?email_source=notifications&email_token=ALJUC6TYW5ZEW2SD7PVOHKTQOZETLA5CNFSM4JAD5IK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBKQDAY#issuecomment-542441859, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJUC6S2MPNQP7XCNQAPPFTQOZETLANCNFSM4JAD5IKQ .

brcisna commented 4 years ago

Hi Frank,

Just wanted to provide a little more info. (This is a second email response,,as i sent one about an hour ago) What appears to be happening is with the build you sent me,, The default font seems to be 'Ubuntu'? Even if a i create new title with this font it appears blank,in preview,,and export,,of course, If i change to any other font the fonts are recognized.

This is on a Debian Buster build machine FYI. I'm not sure how to change the default font of OS? Never had to before I guess,,I think if i would change the default to something else (Other than the Ubuntu font) all would be good, The other work around is to change each title i create to any other font.

Hope this makes sense.

Thanks again, Barry Cisna

On Wed, Oct 16, 2019 at 6:13 PM Barry Cisna brcisna@gmail.com wrote:

Hello Frank,

Thank You for helping out on this. This build of OS opens immediately as expected. The things is this version along with the 'dailybuild' that i downloaded a few days ago,, when reading in an already built project everything looks correct other than the titles that are added are not read,,unless i do an edit,,and change the default font. I do almost all old historical videos comprised of many photos,,so i have tons of titles added to each video i build for example. Not sure why the build of OS doesnt read in the titles they are just blank until i do an edit,,and change the fonts on each. If i close this version and open the 'downloadable' 2.4.4 build everything is recognized,,,but,,i do get the two minute hang on startup,,I can try and do a screen capture when i try and open the hanging version,,of OS<,,but in the terminal it says many lines of fonts,,,fonts,,, fonts,,then finally opens just for a bit of info?

Thank again, Barry Cisna

On Tue, Oct 15, 2019 at 6:09 PM Frank Dana notifications@github.com wrote:

Hi @brcisna https://github.com/brcisna , would you mind downloading the AppImage build from my Google Drive folder https://drive.google.com/open?id=1bqSudb-MITqqNJoJrKZub1WHuN-eoicN and letting us know if you have the same issue with that build?

(It's basically the same as the one you tried, just a couple of weeks older and with a different set of libraries bundled into the package. I'm trying to track down instances where issues like the one you're seeing may be caused by certain shared library files being present in the AppImage when they shouldn't be there. Thanks!)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/3041?email_source=notifications&email_token=ALJUC6TYW5ZEW2SD7PVOHKTQOZETLA5CNFSM4JAD5IK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBKQDAY#issuecomment-542441859, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJUC6S2MPNQP7XCNQAPPFTQOZETLANCNFSM4JAD5IKQ .

ferdnyc commented 4 years ago

Thank You for helping out on this. This build of OS opens immediately as expected.

That's good news, thanks! I'll add it to the list of successes there.

I can try and do a screen capture when i try and open the hanging version,,of OS<,,but in the terminal it says many lines of fonts,,,fonts,,, fonts,,then finally opens just for a bit of info?

I suspect the font lines aren't related to the hangs, TBH. They're a well-known issue with the AppImages when they're run on any system with a modern fontconfig install, due to config-file changes that aren't supported by the very old version included in the OpenShot AppImage builds (but excluded in my version). However, they've long since proved to be a harmless annoyance. I suspect the hangs are related to some other libraries that I also excluded from the packaging (I really cleaned house), while the lack of fontconfig logspew is coincidental.

What appears to be happening is with the build you sent me,, The default font seems to be 'Ubuntu'?

*nod* Things are actually... somewhat tricky there. (And looking over this after having written it, I can't believe how long this got. Apologies for what's about to happen.)

Here's the situation regarding title fonts:

  1. The Ubuntu font (there actually is a font called "Ubuntu") is configured as the default interface font in OpenShot, because a copy of that font is actually included in the OpenShot distribution. So, it's the only font OpenShot can safely assume will always be available. (That statement will become more complicated later.)
  2. The font specified in the OpenShot title templates, though, is actually either Bitstream Vera Sans or the generic Sans Serif. Unless the user changes it, of course.
  3. Because the Qt application font is set to Ubuntu, in the absence of any other information the font selector will open to that font by default.
  4. The Title Editor actually has what I consider a bug, in all versions including 2.4.4 and the more recent builds. (My PR to fix it is still unmerged.) Until #2948 is merged, the behavior of the font chooser is that it will always open to the default (Ubuntu) font. Every time, regardless of any previous selections. Even if the user has changed a title file's text to some other font, clicking the Change Font button again will always bring up Ubuntu, regardless. This has been shown to be a source of understandable confusion for users, and gives the impression that the font selector is non-functional. It also makes no sense because, as I mentioned, none of the templates actually use Ubuntu as the title font. (Not initially, anyway. It will be set that way if the user opens the font dialog and confirms it as their font selection.)

As a result of all that, it's hard to say exactly what the current font situation is with your title files. Especially in light of two additional wrinkles to this whole process (hey, I said it was tricky):

Wrinkle 1

The Title Editor doesn't actually read the contents or current state of the title files, it only knows how to apply changes. So, it has no way of knowing what font is actually in use in a given title — that's why it doesn't actually show the font name in the interface, there's just a button labeled "Change Font". As with the color picker (which works the same way), the first time it's used it's effectively "going in blind", just bringing up a default value.

After a selection is made, it can retain that selection in order to redisplay the previous value on subsequent accesses — the color picker already does that, and with #2948 the font picker will work the same way, along with defaulting to Bitstream Vera Sans instead of Ubuntu the first time — but the initial selection is always just some default value.

So, point is, you can't determine the font used in a title file by bringing up the font selector in the Title Editor. Its initial state has no meaning unless you've previously opened it during that session, in which case it shows your previous selection. (In fact, you can't determine a title file's font selection at all, using the OpenShot interface, for the reasons I mentioned. You can by examining the source code of the title files, though, as they're just plain-text SVG.)

Wrinkle 2 (and, I suspect, a critical one)

I mentioned that Ubuntu was bundled with OpenShot — that's true by default, and applies to the source distribution and the AppImage builds. However, in accordance with their policies some packagers (including Debian) remove the bundled Ubuntu font when packaging OpenShot in their official package collections.

That, I suspect, is why there's a difference between 2.4.4 and the later AppImage builds. I don't believe you mentioned it (or perhaps I just missed it), but if the 2.4.4 you were running was from an official package, rather than from an AppImage, then the Ubuntu font wouldn't have been present in the distro packaging. So, that could explain why it's only showing up now.

It doesn't explain why the title text would fail to show up until you change the font, though. I don't really have an immediate answer for that, since it's not something I've seen reported before.

What I'd suggest is: check what fonts are actually in use in your saved titles.

The easiest way is to get the path on disk (if you choose 'File Properties...' in the context menu on a title's Project Files entry, the dialog that comes up will show a "File Path" entry), then open a terminal window and run grep font-family (title-file-path). Turning on color-highlighting helps since SVG source often uses very long lines. e.g.: Screenshot from 2019-10-16 22-00-41

...To be honest, I really don't have any suggestions for a next step after that. I'm hoping that maybe the information on what font it's looking for might be somehow enlightening, I guess? If it sounds like I'm grasping at straws, I definitely am.

ferdnyc commented 4 years ago

If i close this version and open the 'downloadable' 2.4.4 build everything is recognized

Damn, I just re-read and you did say that the 2.4.4 in question was also an AppImage.

Well, that's a new concern, then. If recent builds aren't properly loading titles created with the 2.4.4 release build, then something must've changed in the development code since the release of 2.4.4.

I'll try to reproduce that myself. But if you could let me know the results of that grep font-family command on one or two of the title file(s) that don't display properly when loaded in the recent builds, that may prove... if not enlightening, then at least helpful information for tracking down what changed and why. Thanks.

brcisna commented 4 years ago

Frank,

Just wanted to also mention the AppImage build you sent me exports much much faster on same machine than the 'downloadable' AppImage from Openshot-2.4.4 mainpage,,(,the Appimage that hangs at startup). It exports the same project same resolution,, about 3 times faster! . My history videos are never more than 12 mins long so this isnt a big concern but faster is always nicer,,providing the video,,quality doesnt get too degraded.

Thanks, Barry

On Wed, Oct 16, 2019 at 9:17 PM Frank Dana notifications@github.com wrote:

If i close this version and open the 'downloadable' 2.4.4 build everything is recognized

Damn, I just re-read and you did say that the 2.4.4 in question was also an AppImage.

Well, that's a new concern, then. If recent builds aren't properly loading titles created with the 2.4.4 release build, then something must've changed in the development code since the release of 2.4.4.

I'll try to reproduce that myself. But if you could let me know the results of that grep font-family command on one or two of the title file(s) that don't display properly when loaded in the recent builds, that may prove... if not enlightening, then at least helpful information for tracking down what changed and why. Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/3041?email_source=notifications&email_token=ALJUC6WMM73SBBHSJGP3B63QO7DK7A5CNFSM4JAD5IK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOQF7Y#issuecomment-542966527, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJUC6Q3DUWPUSIDCMY7GX3QO7DK7ANCNFSM4JAD5IKQ .

brcisna commented 4 years ago

Hi Frank,

Just thought I would mention. On the AppImage version you sent me,,I tried for the first time creating an animated title. It will not find Blender even though blender is installed. I went into preferences and set the path,,but still 'unable to find blender' dialouge box pops up. I might add I run a debian thin client (10/Buster) which runs through a squash image from an actual Debian server. I am guessing this is the path problem. This has never done this in other versions of blender though?

Thanks again

On Thu, Oct 17, 2019 at 2:00 PM Barry Cisna brcisna@gmail.com wrote:

Frank,

Just wanted to also mention the AppImage build you sent me exports much much faster on same machine than the 'downloadable' AppImage from Openshot-2.4.4 mainpage,,(,the Appimage that hangs at startup). It exports the same project same resolution,, about 3 times faster! . My history videos are never more than 12 mins long so this isnt a big concern but faster is always nicer,,providing the video,,quality doesnt get too degraded.

Thanks, Barry

On Wed, Oct 16, 2019 at 9:17 PM Frank Dana notifications@github.com wrote:

If i close this version and open the 'downloadable' 2.4.4 build everything is recognized

Damn, I just re-read and you did say that the 2.4.4 in question was also an AppImage.

Well, that's a new concern, then. If recent builds aren't properly loading titles created with the 2.4.4 release build, then something must've changed in the development code since the release of 2.4.4.

I'll try to reproduce that myself. But if you could let me know the results of that grep font-family command on one or two of the title file(s) that don't display properly when loaded in the recent builds, that may prove... if not enlightening, then at least helpful information for tracking down what changed and why. Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/3041?email_source=notifications&email_token=ALJUC6WMM73SBBHSJGP3B63QO7DK7A5CNFSM4JAD5IK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOQF7Y#issuecomment-542966527, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJUC6Q3DUWPUSIDCMY7GX3QO7DK7ANCNFSM4JAD5IKQ .

brcisna commented 4 years ago

Hi Frank,

My assumption was wrong. I remoted into the Debian server itself,,and launching OpenShot on server it still cannot find Blender even when i manually set the path. Sorry for being a pest.

Thanks, Barry

On Sat, Oct 19, 2019 at 8:29 AM Barry Cisna brcisna@gmail.com wrote:

Hi Frank,

Just thought I would mention. On the AppImage version you sent me,,I tried for the first time creating an animated title. It will not find Blender even though blender is installed. I went into preferences and set the path,,but still 'unable to find blender' dialouge box pops up. I might add I run a debian thin client (10/Buster) which runs through a squash image from an actual Debian server. I am guessing this is the path problem. This has never done this in other versions of blender though?

Thanks again

On Thu, Oct 17, 2019 at 2:00 PM Barry Cisna brcisna@gmail.com wrote:

Frank,

Just wanted to also mention the AppImage build you sent me exports much much faster on same machine than the 'downloadable' AppImage from Openshot-2.4.4 mainpage,,(,the Appimage that hangs at startup). It exports the same project same resolution,, about 3 times faster! . My history videos are never more than 12 mins long so this isnt a big concern but faster is always nicer,,providing the video,,quality doesnt get too degraded.

Thanks, Barry

On Wed, Oct 16, 2019 at 9:17 PM Frank Dana notifications@github.com wrote:

If i close this version and open the 'downloadable' 2.4.4 build everything is recognized

Damn, I just re-read and you did say that the 2.4.4 in question was also an AppImage.

Well, that's a new concern, then. If recent builds aren't properly loading titles created with the 2.4.4 release build, then something must've changed in the development code since the release of 2.4.4.

I'll try to reproduce that myself. But if you could let me know the results of that grep font-family command on one or two of the title file(s) that don't display properly when loaded in the recent builds, that may prove... if not enlightening, then at least helpful information for tracking down what changed and why. Thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenShot/openshot-qt/issues/3041?email_source=notifications&email_token=ALJUC6WMM73SBBHSJGP3B63QO7DK7A5CNFSM4JAD5IK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOQF7Y#issuecomment-542966527, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALJUC6Q3DUWPUSIDCMY7GX3QO7DK7ANCNFSM4JAD5IKQ .

ferdnyc commented 4 years ago

@brcisna

Well, that's good news, at least! I can't say for certain, but I'm hopeful that the difference is down to the changes that have been made to OpenShot since the 2.4.4 release — in other words, I don't think there's anything special about the build you downloaded, other than the fact that it's a 2.4.4-dev2 build, and contains all of the latest development code.

(The changes I made in that particular build shouldn't have had much impact on performance, since that wasn't really the goal. The purpose of that build was to tighten up how OpenShot interfaces with the local system libraries, to hopefully make it more stable and more compatible with the various distros and releases.)

But since 2.4.4, a fairly severe issue with memory not being properly freed during export has been cleared up, the code that allocates resources has been tuned to make better use of the system's available memory and CPU cores, and preliminary support for hardware-accelerated encoding has been added in (though it's still not very automatic and probably isn't in use during your exports).

The really good news is, none of that is expected to have any effect on export quality — the speedups all come from making better and more efficient use of the system's available processing power, not by sacrificing quality at all. So, to the extent that performance is improved, the improvements should come largely "for free".

Now, if only we could manage to do the same for the terrible Preview performance...