Export to DxO broken after update to LR 7.5

DxO PhotoLab
,
4

Note that this problem is similar to a problem that occurred last year. See http://forum.dxo.com/index.php?topic=13562.0 . I had suggested a workaround that worked but this time, it’s apparently not enough.

Also, note that this error puts LR in an unstable state. When you quit LR, the lightroom.exe process is not terminated and you can’t relaunch it without manually killing the process.

5

OK. Problem spotted.

LR 7.5 has moved the Presets folder. This breaks the LR executable detection routine of DPL. This also breaks the plugin installer. There are 2 problems to fix.

If you have run a Repair of DPL, you should follow these steps :

  • Open C:\Users<user>\AppData\Roaming\Adobe\Lightroom\Modules\dxo-exporter-dpl1.lrplugin\PluginData.lua
  • Check whether the third line says : dxoExecPath = “invalid”,
  • If this is the case, replace “invalid” with “C:\\Program Files\\DxO\\DxO PhotoLab 1\\DxO.PhotoLab.exe” or whatever the dxo executable path might be (beware the double backslash)
  • Save

Then there is a LUA routine in the plugin that must be modified. Do this only if you are in a hurry. Otherwise, wait for the fix from DxO.

  • Make a backup copy of (or rename) C:\Users<user>\AppData\Roaming\Adobe\Lightroom\Modules\dxo-exporter-dpl1.lrplugin\DxOOpen.lua

  • Download this modified version of the file :
    https://www.dropbox.com/s/sc40rjqb26fr2db/DxOOpen.lua?dl=0

  • Move it to the folder where the original was stored.

  • Re-launch LR.

This should fix the problem. This is a quick fix and the code could be optimized. This is enough to wait for the fix from DxO

2 Likes
6

The above also applies to the MacOS but the file paths are different (the modified LUA file should be correct). So the whole procedure must be adapted.

7

Additional note :

If you have lost the plugin files during a Repair operation, you don’t need to re-install. Just run C:\Program Files\DxO\DxO PhotoLab 1\Plug-ins\Export\lightroom-export.exe. This should re-install the plugins only.

8

That’s VERY helpful, Pat … I figured it wouldn’t do any harm to try - and I was delighted to find that It worked on my installation of PS Elements too (which, previously, was not recognising installation of Nik Collection) :ok_hand:

Thank you !
John M

1 Like
9

Hello guys,

We are working on the problem in the urgent way. We will introduce the fix asap. @Pat91 thank you for the investigation.

Regards,
Svetlana G.

10

While you are at it…

While fixing the LUA script is rather simple, there’s another problem on the DxO side with the DPL installer that should be handled. Some of us have noticed that the Repair operation launched from the DPL installer resulted in deleted LR plugins. In some cases, even the Modules folder of LR has been deleted. I think, this is due to the way the DPL installer (and/or the MSI service) operates.

Apparently, when the Repair process is launched, the files are not checked for validity but merely replaced. That is, they are deleted and then re-installed. This is the brute force approach. So, when it comes to installing the LR plugins, they are first deleted and then “re-installed”. But if the routine determining in which folder they should be copied fails, nothing happens and the installation process stops without reporting any error. So, as a result, the plugins are merely deleted and that’s it. I guess that if no other plugins were present in the Modules folder, this folder is itself deleted.

I have not used MSI since a while and I can’t remember whether there’s an option allowing to avoid such a problem. Also, I admit that error management in LUA is a mess (why on earth did they use this language when developing Lightroom ?). But this should be fixed because not all DPL users are aware that they can re-install the plugins by running C:\Program Files\DxO\DxO PhotoLab 1\Plug-ins\Export\lightroom-export.exe.

11

Another remark :

Relying on the folder structure of Lightroom in order to determine the location of lightroom.exe is not safe. They are constantly changing it and this will happen again. We already had the same problem last year, it re-appeared this year and you can be sure that this will happen again.

I don’t know for the Mac, but for Windows, there are many other ways to determine the location of the LR executable. In the registry in the first place. But there are other sources for this information (examining the startup menu for example).

My two cents…

12

In this case, the LUA script I have made available aboce may fail. The Modules folder might have been deleted if the only plugins installed in LR are the two DPL export/import plugins. In this case, just manually re-create this folder (C:\Users\AppData\Roaming\Adobe\Lightroom\Modules).

13

Another good source for finding Adobe installation folders and executable locations is C:\Program Files (x86)\Common Files\Adobe\caps\hdpim.db. This is a SQLite database. All the necessary information is there.

14

The error message “attempt to index field ‘_pathForFolder’ (a nil value)” is caused by a bug introduced in Lightroom 7.5 that affects a number of plugins. An Adobe employee has acknowledged the bug and said it will be fixed in the next release. There is a simple workaround available to the plugin developers.

See the bug report in the official Adobe feedback forum for details: https://feedback.photoshop.com/photoshop_family/topics/lightroom-sdk-lrapplication-developpresetfolders-returns-buggy-fake-folders. If this bug affects you, either as a plugin user or developer, please add your constructive opinion to the bug report. Be sure clik Me Too and Follow in the upper-right corner. This will make it more likely Adobe will prioritize a fix, and you’ll be notified of changes in the bug’s status.

15

Hi John,

Thanks for the information. Regarding the problem in the DxO plugin, both DPL and LR are faulty. In previous versions, the folder returned by LrApplication.developPresetFolders() was one level higher in the folder hierarchy. The routine used by DxO to locate lightroom.exe is rather strange. Now, bubbling up 3 levels (as they did with versions 7.3 and 7.4) instead of 4 bring them to the Resources folder instead of the Lightroom folder. This method is not reliable, that’s why I have recommended using another mechanism to determine the location of the lightroom executable.

So, in that case, the bug in DxOOpen.lua is not due to a failing call to getpath but to a call to getLightroomExecutablePath() in LrTasks.startAsyncTask that actually returns nothing. A true programming language wouldn’t allow a function to have an exit path not returning a result.

Still wondering why they used this language.

16

The error message “attempt to index field ‘_pathForFolder’ (a nil value)” comes from the call to folder:getPath() in LR 7.5.

1 Like
17

Hello guys,

The issue has already been fixed and we will deliver the new build in the coming days.

Thank you
Regards,
Svetlana G.

2 Likes
18

I am still having this issue exporting from PL2 v2.1.0 TIFF to Lr Classic CC v8.1

19

Hello,

Replied to you in your separate post.

Thank you
Regards,
Svetlana G.

20

This same error is happening again now. June 6, 2019.

21

Hello @bridgkat,

Could you, please, give some more info like your OS, LR version etc?

Thank you,
Regards,
Svetlana G.

22

Hi I’m on windows 10 and the latest version of Lightroom through the photography package. I use the Lightroom desktop classic version.

23

Hi bridgkat,

As mentioned above, could you please

  • Open C:\Users<user>\AppData\Roaming\Adobe\Lightroom\Modules\dxo-exporter-dpl2.lrplugin\PluginData.lua in Notepad
  • Check the value of dxoExecPath

or even show the whole contents of the file.