Maybe this is what I noticed today where it was hanging at initialization and would finally load modules after a noticeable delay. This happening on launch of the application (not just first startup). I use a multi monitor setup with my HP laptop and so maybe had Slicer last up on a multiple monitor, but this hang I observed today was without any external displays connected.
Delayed startup is most likely a different issue than not starting at all. Delay may be due to Windows malware checks.
Are subsequent startups faster? Is startup slow again after restarting Windows?
Subsequent startups where equally slow and restarting Windows didn’t help.
It was only once I deleted the following file that it was fast to start again:
“C:\Users\butlej30383\AppData\Roaming\NA-MIC\Slicer.ini”
I haven’t yet narrowed down the specific setting that might be causing the issue.
1 Like
It might have been an an extension that did some time-consuming operations at startup.
Apologies if I have discovered a separate issue from what the “Slicer doesn’t load” original author was posting about.
@lassoan I didn’t have any extensions installed so I continued debugging. I was able to narrow it down to a setting specifying a recent file that is unavailable because it was on a local file share at work that I don’t have access to at home.
Slicer was hanging at the splash screen showing “Initializing user interface…” where it took 45 seconds for it to finally begin loading modules as seen on the splash screen. Once I removed the following key (see below) from the RecentlyLoadedFiles section, the startup of Slicer was back to being fast. I couldn’t even see “Initializing user interface…” at the splash screen because it was so fast.
Is Slicer doing checks on the recent files to determine if they are still present and in this case that request to the local file share (that isn’t connected anymore) takes a long time and only reaches a timeout after 45 seconds for that request?
RecentFiles\1\file=@Variant(\0\0\0\b\0\0\0\n\0\0\0\x14\0s\0i\0n\0g\0l\0\x65\0\x46\0i\0l\0\x65\0\0\0\x1\x1\0\0\0\b\0s\0h\0o\0w\0\0\0\x1\x1\0\0\0\xe\0n\0o\0\x64\0\x65\0I\0\x44\0s\0\0\0\v\0\0\0\x1\0\0\0\x30\0v\0t\0k\0M\0R\0M\0L\0S\0\x63\0\x61\0l\0\x61\0r\0V\0o\0l\0u\0m\0\x65\0N\0o\0\x64\0\x65\0\x31\0\0\0\b\0n\0\x61\0m\0\x65\0\0\0\n\0\0\0\x1a\0U\0n\0\x66\0u\0s\0\x65\0\x64\0V\0o\0l\0u\0m\0\x65\0\0\0\x10\0l\0\x61\0\x62\0\x65\0l\0m\0\x61\0p\0\0\0\x1\0\0\0\0\x10\0\x66\0i\0l\0\x65\0T\0y\0p\0\x65\0\0\0\n\0\0\0\x14\0V\0o\0l\0u\0m\0\x65\0\x46\0i\0l\0\x65\0\0\0\x10\0\x66\0i\0l\0\x65\0N\0\x61\0m\0\x65\0\0\0\n\0\0\x1n\0/\0/\0\x31\0\x39\0\x32\0.\0\x31\0\x36\0\x38\0.\0\x31\0.\0\x36\0\x39\0/\0G\0\x65\0n\0\x65\0r\0\x61\0l\0_\0I\0m\0\x61\0g\0\x65\0s\0/\0R\0&\0\x44\0 \0\x44\0\x61\0t\0\x61\0/\0Q\0\x41\0 \0\x61\0n\0\x64\0 \0Q\0\x43\0/\0Q\0\x43\0 \0\x44\0\x61\0t\0\x61\0 \0R\0\x65\0p\0o\0s\0i\0t\0o\0r\0y\0/\0S\0V\0L\0\x31\0\x32\0/\0\x30\0\x39\0\x32\0\x32\0\x32\0\x32\0/\0Q\0u\0\x61\0l\0i\0t\0y\0\x43\0o\0n\0t\0r\0o\0l\0/\0\x32\0\x30\0\x32\0\x32\0_\0\x30\0\x37\0_\0\x30\0\x39\0/\0U\0l\0t\0r\0\x61\0s\0o\0u\0n\0\x64\0 \0S\0t\0r\0\x65\0\x61\0m\0 \0T\0\x65\0s\0t\0s\0/\0\x42\0-\0M\0o\0\x64\0\x65\0_\0\x32\0\x44\0 \0S\0\x63\0\x61\0n\0_\0\x32\0\x30\0\x32\0\x32\0_\0\x30\0\x37\0_\0\x30\0\x39\0-\0\x32\0\x30\0_\0\x31\0\x34\0_\0\x30\0\x37\0/\0U\0n\0\x66\0u\0s\0\x65\0\x64\0V\0o\0l\0u\0m\0\x65\0.\0m\0h\0\x64\0\0\0$\0\x64\0i\0s\0\x63\0\x61\0r\0\x64\0O\0r\0i\0\x65\0n\0t\0\x61\0t\0i\0o\0n\0\0\0\x1\0\0\0\0\x16\0\x63\0o\0l\0o\0r\0N\0o\0\x64\0\x65\0I\0\x44\0\0\0\n\0\0\0\x32\0v\0t\0k\0M\0R\0M\0L\0\x43\0o\0l\0o\0r\0T\0\x61\0\x62\0l\0\x65\0N\0o\0\x64\0\x65\0G\0r\0\x65\0y\0\0\0\f\0\x63\0\x65\0n\0t\0\x65\0r\0\0\0\x1\0)
Thank you for the investigation,this is a very interesting find. Network resources may take some time to become available, so it makes sense for the operating system to wait for them a bit.
Graying out unavailable files in the recent file list is a nice feature, but maybe we should replace it by an on-demand check, when the user selects an item. In case of failure, a popup could be displayed that has the option of removing the file from the list.
Could you submit an issue to the Slicer bugtracker about this? Thank you!
Issue created:
1 Like
Hi guys, we are facing this issue right now. Our users are in a distributed filesystem environment that uses large files and scenes that cannot be saved locally. Most of the .mrml scenes are on network locations. Often times they move the mrml or delete them, and it takes 1m to timeout for each invalid path at the recent files list. One invalid network path takes the app launch time from 20s to 1m20s
Would it be a solution to have this check completely removed at startup and let the error happen when the user clicks to load a recent file that is not available?
Thanks in advance
I would agree that the app should not check if the file still exists at startup when populating the recent files menu. It should just add the list of items and therefore will no longer show unavailable entries as disabled items in the menu. Upon clicking an item that is missing/unavailable the load event should fail. The item in the recent list should remain as-is and stay enabled as the file may be restored to its original location or the network connection may be restored to make it available.
1 Like
It is nice if it is visible that a file is unavailable, but I agree it is not worth delaying the application startup (or showing of the menu because of it), when the delay is long. We should do the check each time the most recently used file list is shown and disable the check for non-local files. But if these are not trivial to implement then it is simpler to just remove this check completely (it would be just a minor inconvenience for users, not happening very frequently).
Another option is to do this kind of operation asynchronously.
Another option is to do this kind of operation asynchronously.
Yes, we cannot block the GUI each time the user open the most recently used files section, so if there is any check then it must be done in the background.