I believe it should tell you what it’s doing beforehand. That script is what launches the installer.
You can contact support online. There is sometimes live chat as well, and we frequently do screen shares for lingering issues so there is certainly a way to get help. For your specific issue, Permission Denied (0) nearly 100% of the time is caused by either a firewall or antivirus blocking the app from connecting to our servers to verify login info. If you’re running into that, that’s what I’d check first.
Thanks Adam, firewall was the culprit. Thank you again.
1 Like
You’re welcome, I’m glad that solved it for you!
I think maybe I should add something to that error specifically to explain potential solutions because it is very frustrating when it occurs and the solution is again pretty much 100% of the time firewall/antivirus related.
I don’t think any message came up to reassure me. I have since downloaded from the link at the top of this thread. No unnerving messages this time…
I can work on the messaging for this some more. From what I see it should pop up this dialog with an “Ok” button:
The app will now update in the background. The application will not be usable until the update is finished, but you may continue to use it after the update is complete.
I think this doesn’t explain what osascript is or how the installer will work, so I can definitely work on that wording. Due to the way the update system works though, the earliest it could be changed would be 3.4.3, but then it’d only show up when updating to 3.4.4, so it will take a while for you to see the change.
The reason we’re using osascript here is because it’s as far as I know the only way to run an application (in this case MacOS’s installer app which requires admin) as administrator. Specifically, the script being run is:
osascript -e 'do shell script "installer -pkg \\"${installerPath}\\" -target /" with administrator privileges'
Where ${installerPath} is the path to the .pkg file that was downloaded for the update. This essentially runs an applescript that runs the real command (installer -pkg "${installerPath}" -target /) as administrator.
Hope this explains everything!
I saw that message but it needs to say that osascript will be triggered in the process. Just to reassure nervous people like me!
Currently talking to some people for how best to reword this, so you should see it change two updates from now.
Sill crashing on an Apple M1 while doing batch, using DeNoise as a stand alone app.
Thread 24 Crashed:: Dispatch queue: com.apple.CoreMLBatchProcessingQueue
0 libsystem_platform.dylib 0x1971e4144 _platform_memmove + 52
1 CoreML 0x19ee379dc bool CoreML::vectorizeMultiArray<float, float>(CoreML::MultiArrayBuffer const&, CoreML::StorageOrder, CoreML::MultiArrayBuffer&) + 184
2 CoreML 0x19ed9dd88 -[MLMultiArray(CopyingAndVectorization) copyIntoMultiArray:error:] + 108
3 CoreML 0x19edbb8e8 -[MLNeuralNetworkEngine bindInputFeatures:bufferIndex:cleanUpBlocks:directBindingRequested:error:] + 2016
4 CoreML 0x19edb6bf4 -[MLNeuralNetworkEngine evaluateInputs:bufferIndex:options:error:] + 164
5 CoreML 0x19edb9234 __54-[MLNeuralNetworkEngine evaluateInputs:options:error:]_block_invoke + 44
6 libdispatch.dylib 0x19700ebac _dispatch_client_callout + 20
7 libdispatch.dylib 0x19701de00 _dispatch_lane_barrier_sync_invoke_and_complete + 56
8 CoreML 0x19edb9058 -[MLNeuralNetworkEngine evaluateInputs:options:error:] + 376
9 CoreML 0x19edade04 __62-[MLNeuralNetworkEngine predictionFromFeatures:options:error:]_block_invoke + 128
10 libdispatch.dylib 0x19700ebac _dispatch_client_callout + 20
11 libdispatch.dylib 0x19701de00 _dispatch_lane_barrier_sync_invoke_and_complete + 56
12 CoreML 0x19edadc78 -[MLNeuralNetworkEngine predictionFromFeatures:options:error:] + 436
13 libaiengine.2.1.30.dylib 0x10e0b955c -[CoreMLLinker runModel] + 128
14 libaiengine.2.1.30.dylib 0x10e0ba06c aiengine::CMBackend::runModel(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::vector<cv::Mat, std::__1::allocator<cv::Mat> >&) + 160
15 libaiengine.2.1.30.dylib 0x10e0ae03c aiengine::ModelBackend::process(aiengine::ModelInput*) + 136
16 libaiengine.2.1.30.dylib 0x10e0be9cc aiengine::AIModel::runModel(unsigned int) + 136
17 libaiengine.2.1.30.dylib 0x10e0c4414 aimodels::NormalImage::process(cv::Mat, QMap<QString, QVariant> const&) + 236
18 libaiengine.2.1.30.dylib 0x10e0bcdd0 aiengine::AIModel::process(std::__1::pair<cv::Mat, QMap<QString, QVariant> >) + 84
19 libaiengine.2.1.30.dylib 0x10e08a3b8 aiutils::TileProcessor::process(aiengine::AIModel*, cv::Mat&, QMap<QString, QVariant> const&, unsigned int) + 312
20 libaiengine.2.1.30.dylib 0x10e08c5c4 aiutils::TileProcessorPool::run(unsigned int) + 176
21 libTDenoise.dylib 0x10dc8d754 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (aiutils::TileProcessorPool::*)(unsigned int), aiutils::TileProcessorPool*, unsigned int> >(void*) + 68
22 libsystem_pthread.dylib 0x1971cd240 _pthread_start + 148
23 libsystem_pthread.dylib 0x1971c8024 thread_start + 8
This looks like a separate processing/engine crash. Would you mind going to Help > File Logging, zipping up your logs, and sending them to me?
In the meantime, you may be able to avoid the crash by changing your processor in Preferences.
Okay, sent to you as a DM
Just “upgraded” to 3.4.2 on my M1 Mac mini (running 12.1). Hadn’t seen the ‘crash on start’ bug listed among the fixes. Well, I’ve seen it now. I tested it on several TIFFs (and a DNG) generated by Lightroom Classic, and all of them seg-faulted the program.
Fortunately, still had my 3.4.1 full installer, so was able to downgrade and therefore wasn’t a huge issue, but definitely a miss there.
Forgot to mention: I tried at least three different ways of loading the images, and all failed (all three ways involved opening the image or DeNoise AI from the Finder. When I tried doing ‘Edit in’ from Lightroom, there was no indication that it even started (nor any dialog from Apple that the program had crashed).
Also forgot to mention: tried opening DeNoise AI either with, or without, Lightroom Classic running. That made no difference. Also (and the reason I tried killing Lightroom), my Mac mini has 16GB of RAM.
Just to confirm your theory, I changed to the prefs to use the CPU and managed to process all 370 images in a the same batch that was crashing on the with the processor set to “Apple M1” It just took 6 times longer to process each image.
Strange that you are having issues with batch processing. I have been using DNAI as a plugin with On1PR 2022 without issue, but can also confirm that it’s working as a standalone. I sent 23 images through it in both Auto and M1 mode and each image took less than 5 seconds. In CPU they took around 35.
I am on an M1 Mac Mini with 16GB RAM.
Mine where 2 second versus 12 seconds on the CPU but there were 370 of them, I haven’t given the latest version through the level of testing I did for 3.4.1 but that version crashed after ~ 70-90 images of the set of images I was processing.
I eventually knocked up a script to move the images that had been processed out of the directory they we in, so I could quickly load the rest and process them and it took around 4 runs to do the lot.
It was quite happy processing the image it crashed on before as the first image of the ‘new’ batch.
I do need to have a play, see if it the the same for all the models or just the Raw model that I was using for those images, or just related to DNG’s although looking at the stack it seems to be past the image load and actually processing the file.
Can you send me logs for these crashes? It might be engine based, in which case you’d need to switch your processor in settings but I can’t know what it is based on your description alone.
If it successfully processes 70-90 images before crashing while using the RAW model then it’s possible that it might be a memory issue. When a supported RAW file is loaded we store a lot more information than just the image data, and it’s possible maybe we aren’t clearing something. I’d have to look into it.
Ever since updating to v. 3.4, I’ve had constant crashes whether in plugin mode or standalone, using an M1 MBP Max, 64 GB RAM. I did go thru the plist dance, the download-the-full-installer ad nauseam. What did work was a full uninstall and then fresh install. Works fine now.
