View Bug Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001241 | DCP-o-matic | Bugs | public | 2018-03-18 01:07 | 2020-12-16 00:28 |
Reporter | carl | Assigned To | carl | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Summary | 0001241: OS X verification takes ages | ||||
Description | Need to work out if there's a way to see what OS X is up to in this time. | ||||
Tags | No tags attached. | ||||
Branch | |||||
Estimated weeks required | |||||
Estimated work required | Unknown | ||||
|
Yup, would be good to understand what is going on there. DCP-o-matic is not alone there, however. Seems that some Apple X-Code releases took multiple hours to verify... Wondering wether the speed of the internet connection has something to do with it? Or is it just a local operation the sort of 'hash through it and do some complex calculations', so, more a question of app size and disc speed? Or is it also some sort of an antivirus scan if the app is not downloaded from the app store? I would like to go back a few test versions to see when that started. Currently I believe it now happens even for versions prior to when the code signing business started...
|
|
Okay, don't know if unrelated testing helps much, but, I tried to start the latest version of Barcos Communicator (setup tool for Barcos DCI projectors). Looks as if Barco does not have an Apple developer account, so I needed to CTRL click in order to open it. The app is about 220MBytes in size, quite similar to DCP-o-matic. When I started it up initially, there was a very short verification process/bar, just a few seconds. Then the 'Not from an identified developer' message popped up. I quit, and downloaded the app again from Barco. This is a ZIP, not a DMG. When I drag the newly downloaded version into my app directory and start it, there is no new verification taking place. This is different from DCP-o-matic - even when I download and install the same DCP-o-matic version again, the whole verification is run through again for the first time I execute the program. Oops, this is not consistent - when I delete pre-existing versions, then unzip a downloaded version and start again, I get a new (short verification). Yes, there must be some sort of caching, or a database, or something. It is hard to see through what exactly happens there...
|
|
I see a very long verification phase for Graphic Converter 10 as well (even longer than for DCP-o-matic ).
|
|
I get the same long (3min) verification even if I reinstall 2.11.17 and run for the first time.
|
|
From what I can see the CPU is busy during this time and it the processes that run open the dylibs that DCP-o-matic depends on, so it looks like it might be some kind of malware/virus scan due to it coming from the internet. I'm not sure where such virus/malware is supposed to have come from... |
|
Seems this is a known issue, Apple seems to be aware of it. It hits many people with different software. I guess we have to put that Readme into the DMG and wait for Apple to fix it. Maybe also put something on the mailing list and forum, just so people know there is nothing wrong. It's especially annoying, since on the Mac, you have to download and install all 5 apps individually, and each app takes so long to verify... It's a bit cumbersome for Mac users currently, also because you can't download all 5 apps, at once, you still have to wait until the running download is finished, then click on the next, etc... Then mount DMG, click one app at a time, wait for verification finish, etc...
|
|
Today, I installed a photographer tool (CaptureOne) on a brandnew Mac Book Pro running High Sierra. I could start it without CTRL-Click, the Gatekeeper verification took about one minute. This, however, is much faster than my 5 year old MacBook. Maybe some of the libs DCP-o-matic uses make this more time consuming. I missed installing DCP-o-matic on that machine for a test.
|
|
I think this is resolved, as much as we can resolve it ourselves. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-03-18 01:07 | carl | New Bug | |
2018-03-18 14:49 | Carsten | Note Added: 0002300 | |
2018-03-18 17:25 | Carsten | Note Edited: 0002300 | |
2018-03-18 17:26 | Carsten | Note Edited: 0002300 | |
2018-03-18 18:02 | Carsten | Note Added: 0002301 | |
2018-03-18 18:03 | Carsten | Note Edited: 0002301 | |
2018-03-18 22:28 | Carsten | Note Added: 0002302 | |
2018-03-19 00:21 | Carsten | Note Added: 0002304 | |
2018-03-19 00:28 | carl | Note Added: 0002305 | |
2018-03-19 14:57 | Carsten | Note Added: 0002307 | |
2018-03-19 14:58 | Carsten | Note Edited: 0002307 | |
2018-03-19 15:45 | Carsten | Note Edited: 0002307 | |
2018-03-22 23:43 | carl | Target Version | 2.14.0 => |
2018-03-28 00:14 | Carsten | Note Added: 0002337 | |
2020-08-18 23:25 | carl | Assigned To | => carl |
2020-08-18 23:25 | carl | Status | new => resolved |
2020-08-18 23:25 | carl | Resolution | open => fixed |
2020-08-18 23:25 | carl | Note Added: 0003903 | |
2020-12-16 00:28 | carl | Status | resolved => closed |