"Loading UI" splash screen takes a long time, and material manager too, if connected to network drives

[cruzer619]

Application Version

4.9.1

Platform

Windows 10

Printer

Ender 3 Pro

Reproduction steps

open app
stuck at "loading UI" for about 5-10 min sometimes longer.
app finally opens and can work like normal.

open up preferences, click on any of them are fine except "Materials".
stuck loading for about 5-10 min and then finally opens.
on some making any changes takes about 5-10 mins.

Actual results

eventually after waiting about 5-10 mins (sometimes longer) you will be able to perform the things you want. Opening of files or making configuration changes.

Expected results

not having to wait 5 -10 mins to open the app or make changes.

Checklist of files to include

• Log file
• Project file

Additional information & file uploads

cura-error-logs.zip

Also the only plugin I have installed is Octoprint and it is up to date. If I roll back to 4.8 I have no issues what so ever.

[fieldOfView]

Does the same pause while "loading ui" happen when you disable the OctoPrint Connection plugin?

[cruzer619]

yes does the same thing without the plugin loaded.. and takes 5 - 10 min to load Marketplace.

[fieldOfView]

Thanks for testing without the OctoPrint Connection plugin.

Does (temporarily) disconnecting your computer from the network change the startup time? Obviously it will break the Marketplace altogether.

[cruzer619]

doing so.. crashed cura. Here is the crash text from the crash windows.
cura-crashlog.txt

[fvrmr]

Could you try to remove the 4.9 folder here: C:\Users\<your username>\AppData\Roaming\cura
That will reset your preferences.

Can you let me know if that works for you.

[cruzer619]

after removing the folder. comes up quick after doing the initial setup. But as soon as you close it. And I waited like 5min and reopened Cura. Does the same thing, 5 -10 min sitting at Loading UI.. and same issue in Preferences when selecting "Materials" takes 5 - 10 min to load.

[cruzer619]

ok after looking around at some other errors users have about slowness and your fix in 4.9.1 about none connected drives. Seems there is still issues with it. I normally don't use Cura while i'm working, So I don't connect to my work file servers via our VPN. This time I did and slowness is gone. Everything is running as expected. As soon as I disconnect from VPN and all my networked mapped drives have RED X's on them. Behavior comes back takes forever. So to workaround this I manually disconnect all my mapped drives. And I'm able to open up Cura again. Down side its extra step for me now to get my work done.. So I'm forced to go back to 4.8 as my paycheck takes precedence over my hobby.. haha..

[fieldOfView]

Something to try is to NOT log in to your Ultimaker account in Cura. Being logged in to your Ultimaker account in Cura while not being connected to the network caused the crash you saw after disconnecting from the network.

[cruzer619]

ok verified. Cura doesn't crash when opening app offline (not connected to the internet) and not logged in.

[cruzer619]

were you able to reproduce my mapped network drive behavior?

[Ghostkeeper]

Not yet. None of our developers on Windows have seen such a slow start-up time, while we also work on VPNs.

This is the relevant part of the log file, where it seems to be slowing down:

2021-05-17 16:44:48,823 - DEBUG - [MainThread] PostProcessingPlugin.PostProcessingPlugin._createView [342]: Creating post processing plugin view.
2021-05-17 16:44:49,120 - DEBUG - [MainThread] PostProcessingPlugin.PostProcessingPlugin._createView [352]: Post processing view created.
2021-05-17 16:48:18,373 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [411]: file:///C:/Program Files/Ultimaker Cura 4.9.1/resources/qml/PrintSetupSelector/Custom/MenuButton.qml:42:18: QML Label: Cannot anchor to an item that isn't a parent or sibling.
2021-05-17 16:48:18,772 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [411]: file:///C:/Program Files/Ultimaker Cura 4.9.1/resources/qml/Account/UserOperations.qml:17:5: QML QQuickItem: Binding loop detected for property "height"

The QML warnings indicate that some interface elements may be positioned wrong. It's got nothing to do with any slowdown.

The PostProcessingPlugin messages are triggered when the main window is created, asynchronously. So the Cura code being executed there is still fairly fast. However 4 minutes later it's giving messages about that it finds mistakes in the QML elements of the main window (PrintSetupSelector, where you can change the material/nozzles of the active printer). So all that time it must've been processing QML entries for the main window in Qt's QML parser.

I have no idea how the QML parsing could ever be so slow when you have a mapped network drive.

Or did you install Cura on a network drive? What is the installation folder, as you selected on Cura's installer?

[cruzer619]

nope Cura is installed locally on my computer.. as long as I have drives that look like this below (internet photo). Takes a long time to load. As soon as I removed them all. Cura works perfectly. I did a little more testing. If I only have one/two disconnected red x drive. It is reasonable to load but after 3 drives then it takes a long time to load. Also, I went back to version 4.8 and I don't have this issue no matter how many drives discconnected.

[Hawkert26]

I have the same issue. As long as network drives are connected, it works fine otherwise it is a tedious wait.

[liqdfire]

@fvrmr I was experiencing an application hang when starting at "Loading UI" in version 4.9.0
I tracked it down to the dialog_save_path key in the cura.cfg file. I was pointing to I:\ which is the drive letter assigned to my sd card reader, and the card reader was not attached to my system, thus I:\ did not exist.

I changed it to C:\ and Cura started without issue, I changed it back to I:\ and it hung on startup. I re-attached the card reader, and left the config value at I:\ and it started without issue.

[cruzer619]

In my case that isn't the issue. Everything in my cura.cfg file is pointing to "C:" Drive.

[fieldOfView]

Everything in my cura.cfg file is pointing to "C:" Drive.

Have you also checked the recent_files under [cura]?

[cruzer619]

Everything in my cura.cfg file is pointing to "C:" Drive.

Have you also checked the recent_files under [cura]?

Yes, everything is pointing to the "C:" drive.

[cruzer619]

Since I wanted to go back to 4.9.1 and whipped out some old batch script knowledge.. This is my workaround using a batch script to open cura. Pretty much it disconnects all my network attached drives before opening opening cura. Its simple batch file and works. For me I had 7 network drive letters to remove. And then I made a manual batch script to bring back the drives when I vpn back in to work.

batch script

@echo off
net use * /d /y
timeout 1

start "" "C:\Program Files\Ultimaker Cura 4.9.1\Cura.exe"

end batch script

Here is the modified shortcut.

UPDATE:

Simply set Cura.exe to "run as admin" will work.

[Ghostkeeper]

@fvrmr I was experiencing an application hang when starting at "Loading UI" in version 4.9.0
I tracked it down to the dialog_save_path key in the cura.cfg file. I was pointing to I:\ which is the drive letter assigned to my sd card reader, and the card reader was not attached to my system, thus I:\ did not exist.

I changed it to C:\ and Cura started without issue, I changed it back to I:\ and it hung on startup. I re-attached the card reader, and left the config value at I:\ and it started without issue.

The only place where this preference is being used is here:

https://github.com/Ultimaker/Uranium/blob/4f088d99c135518f3dde1dafad9c78e9e30a211f/plugins/LocalFileOutputDevice/LocalFileOutputDevice.py#L112

This is code that should only execute once you clicked the "Save to Disk" button or the "Export" option from the file menu. Not at start-up! I also put a hook on the Preferences.getValue function which indeed finds no calls to get that preference during start-up.

[nallath]

In my case that isn't the issue. Everything in my cura.cfg file is pointing to "C:" Drive.

Could you try disabling the "Removable Drive Plugin" and see if the problem persists (we're just trying to pin down what part of the code is causing it, it's not intended as a permanent work around).

[cruzer619]

In my case that isn't the issue. Everything in my cura.cfg file is pointing to "C:" Drive.

Could you try disabling the "Removable Drive Plugin" and see if the problem persists (we're just trying to pin down what part of the code is causing it, it's not intended as a permanent work around).

unfortunately problem still persists when disabling removable drive plugin... is there a way to run cura with all plugins disabled.. then I can go one by one, enable and see what is causing it.. if it is a bundled plugin.

[nallath]

unfortunately problem still persists when disabling removable drive plugin... is there a way to run cura with all plugins disabled.. then I can go one by one, enable and see what is causing it.. if it is a bundled plugin.

Ugh. I was really hoping it would be that :(

Other than doing it one by one via the installed tab, i don't think there is a way to do it.

[cruzer619]

ok disabled all bundled plugins and problem still presists.. so its not a plugin. :(

[Ghostkeeper]

:( Confusing. Probably would be good to re-enable those again then.

Since you indicate that the "materials" screen also takes very long to load, perhaps something is up with your material profiles. These are also loaded in the "loading UI" stage because that's when it creates a list of the available materials for your configuration. I've tried adding a few of them but it keeps loading fine for me.

There is one more thing we can try to reproduce this. A bit of a strong measure. Could you:

• Navigate to %APPDATA%\roaming\cura (the resource folder of Cura).
• Compress the entire 4.9 folder in a .zip archive.
• Post that here?

Since 4.9, Cura no longer stores log-in tokens in the cura.cfg file so it should be safe to share that, unless other plug-ins still store sensitive information in there (like Octoprint, but that would require access to your network anyway I suppose).

Using your entire resource folder we should be able to restore your exact state of all profiles and settings. Maybe this will shed some light on what it's doing.

[nallath]

A final possibility I can think of: Cura creates two file dialogues at start-up, one for saving files and one for loading. They just aren't visible yet until you try saving/loading a file. These file dialogues show your network drives, so they cause Windows to look for which drives exist. Perhaps that could be slowing the application down.

But if that is the case, we might be able to solve that by creating those in a loader.

[jrwaters2]

A final possibility I can think of: Cura creates two file dialogues at start-up, one for saving files and one for loading. They just aren't visible yet until you try saving/loading a file. These file dialogues show your network drives, so they cause Windows to look for which drives exist. Perhaps that could be slowing the application down.

But if that is the case, we might be able to solve that by creating those in a loader.

The file open and save operations don't cause any performance degradation . . .its only startup and accessing preferences (material manager or profiles). But I love the brainstorming. Put it all in-head and theories come out . . . maybe :-)

[Ghostkeeper]

The file open and save operations don't cause any performance degradation . . .its only startup and accessing preferences (material manager or profiles). But I love the brainstorming. Put it all in-head and theories come out . . . maybe :-)

What I meant is that the action of "showing the file open dialog" really just turns the visibility on, but the whole dialogue is created during start-up: They just aren't visible yet until you try saving/loading a file. So if the slowness happens during the creation of those file dialogues, it could cause the start-up to be slower.
As Nallath says, we could solve that by putting them in a loader to load them in lazily. That would mean that the slowness happens when the file dialogues are first needed (so when you first try to open a file).

[jrwaters2]

I'm not qualified to speak to any other benefits of that approach. However, when I was having the issue, my delay was 16 minutes (in other words, not acceptable at any point in the process, whether initialization or otherwise)..

Also, the fact that it would happen just accessing materials manager - i.e. it wasn't just associated with showing the file open dialog, made me think it wouldn't help. In fact, I didn't experience any delay when accessing the file dialog box though perhaps another user did.

Never looked at Cura source code so of course I could be missing some obvious point . . .if so, my apologies.

Best
Jack

[Ghostkeeper]

Indeed, 16 minutes (or 8 if that 16 is from loading 2 file dialogues) is not acceptable at any point. If the user wants to open a file, they are not going to wait for 8 minutes for the file dialogue to open.

It's logical that the material management page also triggers this problem. It contains two file dialogues as well, for the import and export (and a third one in 4.11 for an export-all function):

Cura/resources/qml/Preferences/Materials/MaterialsPage.qml

Line 327 in d24b28c

FileDialog

These are individual file dialogues though. We don't specialise them a whole lot, except for what happens when you press "save", the filters and the folder it starts on.
We might be hitting a bug in Qt here: https://bugreports.qt.io/browse/QTBUG-6039 . However, that issue was recently fixed and backported to Qt 5.15.1. We are using 5.15.1 since Cura 4.9, so you'd expect it to no longer be an issue then.

[jrwaters2]

Wow. Symptoms for QTBUG-6039 seem the same.

I think this is related to SMB1 for what that is worth. The workaround I'm using now is to add ProviderFlags in my registry for that drive. According to https://think.unblog.ch/en/no-network-drives-after-windows-update/, ProviderFlags will:

The Registry Key ProviderFlags controls the recovery of network shares they use Server Message Block (SMB) version 1 when they are stored in the registry.

That might explain why more people don't see the issue. If you do want to make a test build of 4.10.x with different initialization, I'll be happy to characterize it. By characterize it, I mean:

1. Remove my ProviderFlags workaround
2. Load the new Cura and look at a) startup time, b) time to load materials manager, c) time to display file dialogs, etc
3. Add ProviderFlags workaround back
4. Do step 2 again

Just let me know. With ProviderFlags, life is good, no delays of any kind. So, I think that workaround is acceptable but if you are looking to go deeper . . . .

Best
Jack

[Ghostkeeper]

I don't think it's acceptable for Cura to adjust the Windows registry to change that ProviderFlags entry. Cura should not be adjusting registry keys outside of its own domain. It could mess with other applications. That registry entry could be there for a good reason.

[jrwaters2]

I agree with you completely. Maybe I can explain further.

Windows shared drive support is fraught with bugs. I run an engineering team and we had some smart folks spend weeks figuring out issues and inconsistencies associated with disconnected network drives in particular.

I believe this is a similar situation. Its not directly caused by Cura. If I try to access the disconnected drive, for example, without Cura involved, it does the same thing.

So, I would not suggest Cura to change the registry . . . I consider this to be a Windows bug. Manually changing the registry is my workaround until Microsoft fixes the issue.

Ideally Cura would not even trigger this but fundamentally I think it is a Microsoft issue and Cura def. should not change the registry IMHO.

[cruzer619]

@Ghostkeeper since we think the issue is with Qt version. Would it make sense to rollback to whatever the version was on 4.8 and see if that fixes the issue? that is of course if that version can run on 4.9/4.10. As with 4.8 latest version I didn't have that issue whatsoever.

[Florin-Popescu]

Hi! Would like to report that the same or a very similar issue is happening to me on Ubuntu 21.04 with an AppImage of Cura 4.9.1. Been stuck on Loading UI for the past 10 minutes. Left it yeseterday for over 30min and still wouldn't launch. First time I launched the AppImage after downloading it worked just fine. Launching it with sudo today worked almost instantly.

Also when launching it with sudo I am greeted by the User Agreement screen and such first time stuff.

Sounds to me like it could be the same issue as here. Some kind of settings being cached after first run which can't be loaded properly afterwards?

Here is the terminal output from launching it with sudo, if it helps:

:259: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Attribute Qt::AA_UseDesktopOpenGL must be set before QCoreApplication is created.
Cyclic dependency detected between "file:///tmp/.mount_UltimaLIhnVC/usr/bin/resources/qml/Actions.qml" and "file:///tmp/.mount_UltimaLIhnVC/usr/bin/resources/qml/Actions.qml"
WARNING: Cannot find style "default" - fallback: `"/tmp/.mount_UltimaLIhnVC/usr/bin/qt/qml/QtQuick/Controls/Styles/Desktop"

Later edit: same with 4.10.0

[Ghostkeeper]

@Ghostkeeper since we think the issue is with Qt version. Would it make sense to rollback to whatever the version was on 4.8 and see if that fixes the issue? that is of course if that version can run on 4.9/4.10. As with 4.8 latest version I didn't have that issue whatsoever.

Yeah ideally, for debugging, this would be a step we can take. However this is not quite as simple as just changing a version number, because:

• We were using Qt 5.10 before, which was released before Python 3.8 which we had to upgrade at the same time. It might mean we have to downgrade Python too. PyQt5.10.1 can be installed on Python 3.8, but I'm not sure how stable it is.
• We're using new features of Qt 5.15 in our source code already (or rather, from Qt 5.12). So it won't be able to launch without removing those features.
• The upgrade to 5.15 fixed a bunch of issues for us on Windows and MacOS, not the least of which is actual support for MacOS Big Sur. If downgrading fixes this issue, it'll reintroduce others. It would confirm that it is an issue in Qt, but it's not a solution we can use for a release.

The upgrade took us some 2 months. A downgrade would take less time, but still quite significant.

@Florin-Popescu what happens if you disconnect from the network before you try launching Cura (without sudo)?

[Florin-Popescu]

@Florin-Popescu what happens if you disconnect from the network before you try launching Cura (without sudo)?

This fixed it for me. After doing this once, it opens just fine even with network enabled. Even with a PC restart and network connected it works on first try. Thank you very much!

Must've been stuck trying to build up a cache or something?

[Ghostkeeper]

Maybe. This is all happening between Qt and the operating system, and not really in our control or knowledge.
This does seem to confirm that the problem is not limited to just Windows.

[nick3975]

I made an account to share my experience with this. I'm on windows 10 and I had a similar issue that started a few days ago where it would take 5+ minutes to open cura, whether it was just opening it up from the shortcut or opening a file such as an STL. Same deal with the materials and profiles section in the preferences. Additionally, I could not use the "Create profile from current settings/overrides" action. I tried to run as admin which did not make any difference. I was on version 4.10.0, and am now on 4.11.0 as I tried to reinstall Cura to see if it would fix the problem, which for me it did not.

After reading about cruzer619's issue with having the network drives connected, I did not think it would apply to me. However, I do have a lot of physical drives connected. These issues also seemed to coincide with me plugging in an additional sd card reader. I unplugged the reader and all of a sudden Cura opens normally again. I tried to replicate the scenario by plugging the sd card reader back in, however I wasn't able to, and cura continues to open normally. I'm not quite sure what the issue was, but it seems to have gone away for me now.

[cruzer619]

@nick3975 this more sounds like the "dialog_save_path" issue. where its looking for a recent file with that letter drive but wasn't there. Once removed, you went back to normal again.

[nick3975]

@cruzer619 Ah I see, thankyou for the clarification

[VigilanteSystems]

Hi, i just had the same problem in 4.10 and 4.11 .. but the comment about sdcards fixed it for me.
I had some printers sdcard still inserted into one of my sdcard readers, when i removed just the sdcard, cura loaded again!
simple fix, i just removed the sdcards from all readers. thanks

[Ghostkeeper]

Interesting. The file dialogue needs to list all of the SD cards on the system in the menu on the left. But I wouldn't expect it to really need to read inside the SD card. Perhaps this is needed to get the title and icon of the drive. But it shouldn't take that much time unless the drive is broken.

Maybe Qt is doing something else with the drive. We don't know.

[vizitys]

@Florin-Popescu what happens if you disconnect from the network before you try launching Cura (without sudo)?

I had the same issue as @Florin-Popescu (on EOS/Arch) and disconnecting my network fixed it for me (version 4.13.1)

[Florin-Popescu]

Hey,

Latest 4.13 fixed it for me too. I still see Cura always get stuck once for ~10s after 30s from starting it, but it always resumes. Not sure if this is related to the previous permanently stuck issue which I experienced, but it's now fixed.

Looks like a timeout was added somewhere?

[jflemieux]

Linux user chiming in.

The issue on 4.13.1 was still happening on my computer (Running EndeavourOS/Arch on KDE).

In my case, the issue only happens while on a Wayland session, Cura loads instantly on a X11 session.

[GregValiant]

Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed?

[jrwaters2]

It can be closed. Sorry if I neglected a step in the process. Thank you.

…

On Tue, Nov 19, 2024 at 8:57 AM GregValiant ***@***.***> wrote: Is this still an issue in current Cura versions (5.8.0 and up)? Can this be closed? — Reply to this email directly, view it on GitHub <#9861 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQBXO3Y7Z2F6F45I6RXOYA32BNUXHAVCNFSM6AAAAABSCS7NXKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWGI2TKOBYG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cruzer619]

Since I'm OP will close it.