V2.3.1 update working fine also, Win10 vers1903
Hello!
We just released an official hotfix for DPL2.3.1.
Please down load this installer, the issue should be fixed
!! Link edited by moderator !!
Regards,
Svetlana G.
2 Likes
The revised installer worked fine on my Win 10 1903 desktop PC.
Regards, Peter
A good lesson learned from this would be to number EACH installer with it’s version number rather than the generic PhotoLab2_setup.exe which you do for every single version.
i.e properly name each download according to release number. - PL2_Setup_ver_2.3.1_24028 for example.
4 Likes
Fixed version 2.3.1 seems to work…
1 Like
I agree and would like this also. I currently use the check for update, and note the version number, then cancel the upgrade and visit the support portal, create a folder on my machine and name with the installers build number, then download.
There are other methods (like grabbing it from the temp folder) but as long as I get it archived is all that matters to me.
Would also like to point out (and agree) with what Svetlana said. This is a very uncommon occurrence for DxO. It has never happened to me previously. (User since 1.1) Minor speed bump, Nothing to be upset about. They addressed the issue quickly.
I’ll be upgrading mine today.
3 Likes
I had problem with recent install which I did not experience before. It did not install on any of my systems which had the TMP/TEMP on ram disk!
The installer fails in this case. When I move the TMP entries back to the C: drive it installs.
That’s bad because i need two reboots to install it!
Franz,
Not sure I follow. You have a problem with installation because you choose to run your system in a non-standard configuration and you’re surprised when you have issues installing software? The “problem” and solution appears to be obvious.
2 Likes
What is a non-standard installation? I only have the TMP folders on another drive, I had this for years and had no problem, even with DxO in the past, but now the DxO installer is the ONLY one which stops and says it cannot find setup!
So I give feedback to DxO that there is a new problem introduced.
And I also knew how to overcome it for me but un future, if I would be DxO , I would look into it.
Windows created environment variables TMP and TEMP pointing at temporary directories optionally of the user’s choice is the standard configuration. It would be a bug to assume a directory for temporaries is anywhere else.
2 Likes
Isn’t that what I said? The temp folder lives by default on C:, unless you move it.
The point of having the temp directory set by an environment variable is for it to be varied - the clue is in the name.
1 Like
Hello guys,
We’ll have a look at this problem.
Thank you,
Regards,
Svetlana G.
Official Microsoft documentation: https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-gettemppatha
I agree. As it is, for Windows users, multiple downloads of files of the same name are enumerated (digit added to the filename) so you’re not overwriting the current one with the new, and a user should be able to locate the previous version just by picking a photolab installer with a lower (or no) number, but a version number would make this somewhat easier.
That said, I’d expect the version information to be available in Windows (right click an EXE file, select ‘Properties’ from the drop-down, then the tab labeled ‘Details’). I can’t chect this with a PL installer right now as I’m on a work PC, and so don’t have any available to test
Unfortunately, the specific file version is not revealed by this method. The “Properties” dialog below is for PhotoLab 2.3.
Regards, Joseph
Hello,
- Yep, we’ve got the task in the backlog to have the installers enumerated to allow you differentiate them quickly.
Regards,
Svetlana G.
3 Likes
Then the ‘ask’ over in ‘what improvements do you need’ should be to fix this. I’m a retired software architect. IMO this, for a Windows app is a bug. I get how a build procedure can’t easily be modified to produce a dynamically named installation EXE.Version info in the header is easily set with dynamic info (and has been in the MS spec for win EXEs for a few decades - not a new thing).
@sgospodarenko Svetlana, could I trouble you to ask the build team to fix this?
I’ll put an entry in the “what improvements…” section once I’ve had a chance to verify - if that’s needed.
I also find myself wondering how your installation QA team is verifying things…
Thanks!
1 Like
Hello,
I’ve already pushed them as soon as got this message once again and we’ll try to do our best to deliver it with the new release. Internally, it’s not a problem to distinguish builds because they contain the number in the name of the installer but to have the same public - it needs some rework of the server. I can promise that the job will be done and this request will be implemented but I can\t say nothing about the timeframe.
Regards,
Svetlana G.
Thanks!
And once they’ve got it fixed, we’ll have a how-to answer for anyone who can’t figure out which PL installer is which version. 
I have to ask: is there a similar issue with the Mac build? I don’t have a Mac so no way to check myself.