Do I lose my access to PL6 if I upgrade to PL7?

I am considering upgrading to PL7 from PL6 as I do enjoy using the software a lot, plus I am planning to get Filmpack 7 and PL7 is somehow a requirement.

Looking at the price, it is not a drastic difference between
Upgrade to PL7 + Buy FP 7
and
Buy new PL7 + FP7 discount offer

I wonder if I do the upgrade, do I still have the three slots to install my PL6 with?
That is, if I upgrade, do I have the license for the number of PCs being 6 (PL63+PL73), or only 3 (PL6/7*3)?

According to DxOs licens model, your licence for PL6 is upgraded and turned into a licence for PL7.
Although so far previously already installed and licensed PL6 will continue to work. But I dont believe you will be able to deactivate them via DxO Support or install and activate new installs of PL6.

1 Like

Based upon my understanding you are correct. You can legally load PhotoLab Elite on three machines, no more. If it worked in the way @Sandbo was asking about, as an owner of licenses from PhotoLab 1 to 7, I could theoretically have it installed on 35 different computers.

It is not clear, however, if you had already loaded a previous version, PL 6 as an example, onto three different machines whether a PL 7 upgrade can only be installed on the same three machines. That is not likely the case since over time old machines are put out of service as new machines are added. It may depend on whether all three installations are performed before or after the upgrade.

Mark

Thanks for the replies, it clears it for me.
While I don’t think I actually need all six PCs, upgrading saves me 42 euro while also costing me the PL6, it’s something to think about.

In fact, the license for one version (e.g. PL6) is perpetual (forever :smiley: ).
The “update” indication is a sales promotion.

Pascal

Not sure about that, because DxO had removed upgraded versions from my shop account.
Be it as it may, it’s always a good idea to keep the old installers and activation codes.

1 Like

@platypus ALWAYS a good policy with all software!

Plus keep interim release code files, even though DxO has lost the once sensible strategy of naming each version, I think it was included with PL4 and vanished with PL5 and has not returned on PL6 and PL7.

All good software developers should number the releases but some don’t (DxO and others) so the user should make sure not to overwrite any code file when downloading and to assign the correct id. to the code file at the start of the download or immediately after the download.

In addition PL7 appears to be “re-using” the PL6 database and thereby rendering it useless for any future PL6 activity.

I thought I had checked after installing PL7 that it was “pointing” to a PL7 database but while monitoring PL7 file activity I found that it closed the PL6 database and I then got the following when I tried to start PL6.10

this was reported during testing but is still present in the released version!

So when moving to a new release (please note these comments come from a Win 10 user)

  1. Secure the previous (current) release database (create a backup) with a suitable name to enable continued use of the previous release.

  2. Install PL7 which appears to then use the previous release (PL6) database and render it useless for use by that previous release.

  3. Choose an appropriate location for the PL7 database in line with your standards or the default/mandatory standards and restart PL7 with the database in that location. I cannot retest the whole installation procedure to test out all the options etc. so there is an issue of carrying over the PL6 database if the user so wishes! For continued use of the old database contents use the ‘Restore’ option and select the PL6 database (the one that PL7 just highjacked) which will require a restart of PL7.

  4. Start PL6 and it will encounter the corrupted database issue indicated earlier in the post and create a new one!

  5. Use the DxPL command to restore the backup database for PL6
    image

  6. PL6 and PL7 should then be accessing their own copies of the same database and will start to diverge at that point if both products are used. The PL6 database can be loaded into PL7 at any stage but not the other way around. PL6 DOPs will be accepted by PL7 but not the other way around.

Work done in PL7 stays in PL7 work done on PL6 can be migrated into PL7 as a DOP or as a database (or that is the way it has been in the past).

@DxO_Support-Team @Musashi all of this could have been avoided!

In spite of the correct use of the designated (by me) PL7 database, PL7 is still using the PL6 cache for better or worse!?

The Read statistics highlighted are for a single touch on these two thumbnails

Whether these are logical reads or physical reads or the software I am using is “miscounting” I do not know but this is a huge number of operations just for one thumbnail/image and it will be repeated every time an image is selected!?

I had noticed that PL7 incorrectly addressed the PL6 database (thus corrupting it), in a couple of unofficial beta/RC versions.

The officially released version, on the other hand, didn’t do it and correctly addressed its own new database (at least for me).

There seems to be some variability in this behaviour…

@Lucabeer I thought it had for me but then I found a close statement for the PL6 database in my activity log for PL7 and then had the corrupt database report from PL6.9 originally and then from PL6.10 when I repeated the test.

It is possible that I caused PL7 to take a wrong turn or !!??

To me, when it happened it was completely spontaneous, as it happened as soon as PL7 was opened. Even BEFORE I could do anything (setting preferences, editing images, etc)

@Lucabeer I checked PL7 (which should never have been near that machine, I test on another machine so that the test environment is completely separate from my normal system) because I knew about the original issue and thought it showed a database in the correct location, i.e. PL7 related.

I was running tests on PL7 because of my concerns about the very high read statistics I had found on PL6 and when I closed PL7 down I noticed a PL6 database close in the activity log, opening PL6 confirmed that PL7 had been “fishing in the wrong pond”.

But I was not in the testing mindset, had not taken snapshots of every potentially interesting/suspicious data until this

so I cannot attest to the reliability of my statement!

1 Like

That’s a very technical analysis, I hope it points to developers in the right direction!

The problem of the new version of PL using the database of the previous version (and corrupting it) has been around for years. It seems that DxO hasn’t figured out why it happens. I should think it would be evident in the code (in other words, how hard can it be to make sure that PL can never do this?), but apparently it’s more complex. I believe the problem has never occurred for me.

@Lucabeer That particular snapshot is just the proof that PL7 was closing the PL6 database!

The reason it was captured was because I had noticed the number of Reads executed just to select an image i.e. the figures vary but about 2,600 reads and 10,788,864 bytes read for a JPG and 4467 reads and 25,644,544 bytes read for a RAW.

The amount of data is probably correct for a JPG and a RW2 file, i.e.

but the number of ‘read’ operations detected by the monitoring software is rather large!?

@Egregius I had my PL4 database completely ignored when moving to PL5 but was able to recover the situation, one user lost all their ‘Projects’. In this case I am not sure how it happened because I would not select the PL6 database for PL7?

It seriously worries me that things that have been on the “wanted feature” list for years and others that are crying out for a product fix are just ignored! The PL7 release provides a ‘Delete’ function for a directory, which does delete everything by the way, but lost “asynchronous” indexing to be replaced by a command attached to the directory i.e.
image

  1. This is badly constructed because it obscures the directory you are about to index, rename etc…

  2. The indexing is now done while traversing the actual directories themselves rather than being initiated as a separate process with its own selection menu.

  3. It lost its asynchronous behavior to be replaced with a process that must complete before the user can actually continue to use the product. How could such a feature change make it past any rational design review, surely someone must have spotted the obvious flaw and suggested just leave things as they are and use the development resources elsewhere.

There is scant development undertaken in the area of image housekeeping/husbandry and when it is it seems to go wrong or be badly designed/badly implemented.

For DxO that appears to be a correct assessment and that doesn’t auger well for the future.

However, I like the change to the menu extension for “local adjustments” but where is the “on/off” switch for each item.

Apparently no-one at DxO thought it a useful adjunct, i.e. to make the sub-menu structure follow the guidelines followed for the main menu structure!

I tried using another product the other day for correcting the thousands of old photos I am scanning and it provided no simple toggle to see the photo with or without a correction being applied, i.e. “is this better or is that better” and realized one simple DxPL feature I value a lot which is absent from the new local adjustments sub-menu.

PS:- and why has it taken since PhotoLab 1 to replace a system that was hard to see and hard to adjust (but certainly small)

image

with a system that makes the feature usable

but missing the “on/off” (per edit feature) toggle!