However, while the symptoms are similar, this is a different cause. For this case, the user’s computer is stopping after the second image during a batch process for my Face Crop plugin. In this case, it is directly related to his custom workspace. I spent about an hour on his computer trying to figure out if there was any specific configuration that triggers it. I rearranged his custom workspace many different ways but it always would stop. The essentials workspace always works.
In this video, you can see the issue toggle on and off by switching the workspaces. For this user, he is running a dual monitor. Not sure if that plays a role. However, all of Photoshop is on one monitor. In the screen recording, you can see both of his monitors.
In the UXP logs, there were zero entries made for the timeframe of this video recording. I recorded this same sequence twice and rebooted between the recording. Both times there were no log entries. The only log entries that were made were during the reboot sequence.
For the other post I made where resetting the preferences fixes it, the workspace is those cases doesn’t seem to play a role. In those cases, we tried setting the workspace to essentials and resettign the workspaces and that didn’t fix it. Only resetting the preferences fixed it for the other post I made. Also, for the other tests in the other post, those were with a different plugin. Those were with EZ Team Builder. The testing in this post was with face Crop.
There is nothing different for what each image in the batch does for processing steps. The second image will run the exact same sequence as the first image. In every case, the first image runs with no issues so I don’t believe this problem is due to any of the processing steps.
I am dealing with a couple of these per day right now. The vast majority of the computers are fixed by resetting the Photoshop preferences. However, this one was unique from the rest so I thought I would post it separately. Maybe it is related to the same bug… maybe something different??? In any case, the occurrences are starting to pile up on me.
Do you have any specs on the types of machines that seem to encounter the problem? Any obvious trend there?
Also – what kind of error handling is in place when a batchPlay command fails? Is that getting logged out to the console (will show up in those logs)? If not, that would be useful information to have.
Would you mind sharing your plugin with us via DM? Unminified would be better so we can more easily trace through the code.
For systems, it is both Windows and Mac equally and various hardware. There is no real common link as far as I can tell.
I have had 3 different plugins doing this so it isn’t related to 1 specific plugin. The plugins each run different sequences of batchPlay too so really nothing common with any exact processing steps.
The one thing that is common is that it NEVER stops on the first image in the batch. So it always runs through the entire sequence perfectly for at least 1 image every time. Also, I have been able to solve every case… almost all of them by resetting the Photoshop preferences. Resetting the preferences is a big common link that fixes it. For the issue in this post, this was a little different and is the first time i’ve been able to directly link it to the workspace though.
What I am thinking of doing is creating a new test plugin that removes a lot of the processing steps and simplifies things. Maybe the issue would still happen with simply opening an image, running a couple of basic batchPlay and then saving the image. This would eliminate a lot of things to look at. Because again, it seem not related to any specific processing sequence but more related to the batching part of it.
If I can create a more simplified test program that has the issue and I can reproduce it on a user’s computer then I will send over the unminified version. I think the biggest problem is that Adobe may not even be able to reproduce the issue. I can’t on my computers either. For the vast majority of the cases, once the preferences are reset the issue never comes back. So that makes troubleshooting extremely difficult.
One more thing that is interesting… No one has ever reported it in Hot Folder which is also a batch processor. A difference with Hot Folder is it processes actions only and doesn’t run process batchPlay commands on each image. So this seems to indicate a possible interaction with batch processing and batchPlay.
I have also done testing where I have it keep track of the last step ran so the user could report it. There doesn’t appear to be a specific batchPlay either. For the last testing I did, it was always stopping after the first batchPlay ran on the second image in the batch. I removed that batchPlay step. then it just stopped after the next batchPlay step after the 2nd image (which was the new 1st batchPlay step).
So based on that, it doesn’t appear to be related to a specific batchPlay command. That is why I am thinking of creating a bare bones batch processing plugin as described in my last reply. I will keep you posted on this and send you the unminified copy when I have a test version ready to go.
