Several users have had issues with PhotoStructure’s use of PowerShell to gather system and volume metadata, and, frankly, debugging Windows permission issues is a nightmare as both system and security configurations vary wildly, and are almost impossible to reproduce on another machine.
removes the ability for PhotoStructure to run child processes at a lower priority, to prevent library imports from making systems too busy for the user
This is a fairly large change to PhotoStructure, and I don’t know how many people are being affected by it, but this feature request’s votes should help determine relative interest.
The new startup arguments for the powershell process in v1.0 (-executionpolicy bypass and -noprofile) should solve most of the issues related to environment customization and policy settings.
I work with powershell as one of my main tools and is quite proficient with it. I would be happy to help diagnose issues related to powershell.
Thanks! Someone’s getting an EPIPE on fork, which would be (presumably) from some external process (presumably anti malware?) killing the child process. I didn’t find anything relevant in googling, but my search mojo may have been lacking.
Why do you need PowerShell for these features? If you can’t do what you need in Node, what about creating a native library (should be able to do that in any language that can create a standard Windows DLL, so C, C++, Rust, etc) using Node-API, or creating some sort of sidecar process in any programming language and just communicate through named pipes or stdin/stdout?
FYI, I think I get a powershell error when I have photos on a bitlocker-locked drive, if I open PhotoStructure before I unlock the drive. If I’m right, this particular error is not particularly important and will affect <1% of your users, but it might be indicative of the kind of random error you get thrown at you by relying on PowerShell…
@PS_2923 what errors are you seeing when the drive is still locked?
PhotoStructure’s volume scanning (either via PowerShell or via system calls) are wrapped by timeouts, so it should be OK with drives that are in an unknown state (like NFS or SMB mounts when the network is disconnected), but I may have missed something (or need to handle a different kind of flaky situation).
Let me try and reproduce it, I didn’t save the error when it came up. It was definitely the PowerShell error because it pointed me to the help page that pointed here, but I can’t remember specifically what it said…
Curiously, this is when the export is running. If I open PhotoStructure when the export is kicked off, but not yet started, I can trigger a whole bunch of simultaneous timeout errors
Anyway, I wouldn’t worry about this particular error, I blame Lightroom / the various plugins for this, and anyway normally I avoid trying to do anything else whilst exporting since it uses so much processing power. I’ll just make a note to not open PhotoStructure whilst doing an export. As I say, it’s just the kind of thing that might come up with PowerShell involved…
(I running a “vanilla” export from lightroom with no plugins involved and opening PhotoStruture while it was running. Then I just got the one volume timeout error.)
I don’t think this is on you at all. My goal is to have PhotoStructure gracefully handle whatever shenanigans are going on with your system.
I’d be interested in seeing why PowerShell is refusing to launch while LR is doing whatever, though. What happens if you open a cmd prompt and run this while LR is running?
