CyberLink Community Forum
where the experts meet
| Advanced Search >
Multiple PD Install Users
Reply to this topic
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4692 Offline
[Post New]
I had posed the question to support, but response was the basic is your PD up to date, update your video drivers,... none really relevant as usual.

My question, have any multi PD install users identified how to fix the interoperability issues?

Basically, my question to support, I have PowerDirector 16 (PD16) which came with ColorDirector 6 (CD6) and PowerDirector 18 (PD18) which had ColorDirector 8 (CD8), all full releases and perpetual keys. When one utilizes ColorDirector from the Fix/Enhance menu in a PD16 editing session, it loads the CD8 package to perform the color edits. How can one enforce that PD16 opens CD6 which was part of that package release? I can launch CD6 manually, but the interoperability feature which opens CD from the Fix/Enhance menu within PD16 opens the most recent CD installed version vs the CD release that was part of that PowerDirector release.

It looks like they maintain a interoperability tree at C:\Program Files (x86)\CyberLink\Shared files\InteropPalette.

For those that have multiple PD and CD installed, does yours behave like stated above? It does not matter what versions you have, as long as you have two that supported CD. The older PD version will always launch the most recent CD version vs its released version when launched from with PD Fix/Enhance menu.

The same is also true for AudioDirector.

I get around the issue by maintaining multiple images to restore that have that unique version of PD but that's a real hassle. I often need it because an older edited file, say PD16/CD6 is not 100% compatible and often different results with PD18/CD8 and PD16/CD8 often creates other anomalies the video receiver does not care for.

Jeff
Reply
vn800rider
Senior Contributor Private Message Location: Darwen, UK Joined: May 15, 2008 04:32 Messages: 1940 Offline
[Post New]
Hi Jeff,

Not doing so much editing these days, so never thought about the issue.

On a quick hack about, I reckon there may be a way round, but it brings some compromises (as always!) but to my mind only minor.

I believe you are correct in the interoperability problem. I think the key is in the file interop.ini which is held (on my system) in all the x64 sub-folders of C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\?.?\

On my desktop system the series ?.? run from 2.0 to 9.0, corresponding to the installations of PDR I have installed which are 12,14, 15,16 perpetual and then 365 subscription (=17,18,19 equivalents)

I have CDR 4,5,6 and then 365 (= 7, 8, 9 equivalents)

So, looking at the differing interop.ini held in each sub-folder (and ignoring anything to do with Action Director) they look like this:
C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\2.0\x64
[PowerDirector]
ver=11,12
[ColorDirector]
ver=1,2

C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\5.0\x64
[PowerDirector]
ver=11,12,13,14,15
[ColorDirector]
ver=1,2,3,4,5
[ActionDirector]
ver=1,1.1,2,2.1,3

C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\9.0\x64
[PowerDirector]
ver=11,12,13,14,15,16,17,18,19
[ColorDirector]
ver=1,2,3,4,5,6,7,8,9
[ActionDirector]
ver=1,1.1,2,2.1,3

It's a straight progression of content from 2.0 to 9.0, although I've only given 3 examples.

Given that these are plain text files they can, of course, be edited.

WARNING
For those folk who are not adept at doing this sort of thing, take backups of original files and only work on copies. Editing this sort of system file might screw your PDR/CDR functioning if you get it wrong. Be careful!!

So a couple of working examples editing the interop.ini file:
C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\9.0\x64
[PowerDirector]
ver=19
[ColorDirector]
ver=6
[ActionDirector]
ver=1,1.1,2,2.1,3

This seems to tie PDR19 (in my case PDR365) to CDR6 not CDR9 (or CDR365 in my case)


Another example:
C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\5.0\x64
[PowerDirector]
ver=15
[ColorDirector]
ver=5
[ActionDirector]
ver=1,1.1,2,2.1,3

Ties PDR15 to CDR5


C:\Program Files (x86)\CyberLink\Shared files\InteropPalette\9.0\x64
[PowerDirector]
ver=19
[ColorDirector]
ver=4
[ActionDirector]
ver=1,1.1,2,2.1,3

Ties PDR19 to CDR4

Whilst I haven't tested all combos exhaustively, so PDR14 doesnt call up CDR at all for an unknown reason - probably needs a re-install, and my perpetual PDR17 is on the laptop, I suspect, with a small bit of file management, you could tie any version of PDR to any version of CDR by using edited interop.ini files in their respective and proper file locations.

Wonder if this is an easier way to get what you require, either by having a set of "alternate" interop.ini files to suit or by just a quick edit when necessary??

I haven't explored the Audiodirector side - I can't yet find a similar set of files that might control the functioning in the same way!

Adrian Life is really simple, but we insist on making it complicated. (see below)
Confucius
AMD Phenom IIX6 1055T, win10, 5 internal drives, 7 usb drives, struggling power supply.
Reply
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4692 Offline
[Post New]
Thanks Adrian,

Yes, I had played similar tricks with some success, hence the pointer to the location. What's strange is I think CL is trying to keep track since the interop.ini file in InteropPalette\9.0\x64 has the array of values with all in product release order. It to me looks like some aspect of this file is not being read and applied correctly.
I had not resolved as it appears InteropPalette\9.0\x64 settings also affect prior versions so it appears more than just a change in each release interop.ini file.

I would have liked a opinion from CL support, but my ticket started so low on the thought curve I can't see value going forward. Your attempt was several light years ahead of support, appreciate it.

It appears you have similar wrong interop experience as I discussed so I think something amiss with what CL is doing to keep each product properly coupled.

Jeff
Reply
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4692 Offline
[Post New]
Looks like another user with the same issue:

Quote My promise to test earlier versions ran into a snag. On one PC, I have PDR15-19 & CDR5-9 installed but the most recent version opens, whichever version of PDR is used. I've temporarily uninstalled CDR to test CDR8 but the results seem to be similar thus far.
https://forum.cyberlink.com/forum/posts/list/84139.page#post_box_347955

Obviously another PD bug, 3rd user test with anomaly, nothing logical would imply that's proper functionality. I pointed CL support to this thread after dismal initial response to ticket, I will wait for their follow up response now that they see a multi user issue.

Jeff
Reply
optodata
Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 6212 Offline
[Post New]
I don't see any reason to jump through all these hoops to manually define which version of CD (or AD) you want PD to use.

As far as I can tell PD, reads through the registry multiple times to determine which other CL programs and versions are installed, but when asked to invoke CD (or AD) it relies on the presence of the highest version number listed at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CyberLink

On my system, I have CD3, 4 and 9 installed, and I made a backup of (exported) the full CD9 and CD4 keys.

If I delete both registry keys with PD365 closed, it calls CD3 when requested because it's the highest remaining version of CD. If I close PD and restore the CD4 key, PD365 calls CD4.

No messing around with InteropPallette or any .ini files or system images; just make backups of the higher CDx (and ADx) keys and restore/delete them as needed.

I'd also make a copy of the full Cyberlink key so there's a reliable recovery of all the original keys.
Reply
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4692 Offline
[Post New]
Quote I don't see any reason to jump through all these hoops to manually define which version of CD (or AD) you want PD to use.

As far as I can tell PD, reads through the registry multiple times to determine which other CL programs and versions are installed, but when asked to invoke CD (or AD) it relies on the presence of the highest version number listed at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CyberLink

On my system, I have CD3, 4 and 9 installed, and I made a backup of (exported) the full CD9 and CD4 keys.

If I delete both registry keys with PD365 closed, it calls CD3 when requested because it's the highest remaining version of CD. If I close PD and restore the CD4 key, PD365 calls CD4.

No messing around with InteropPallette or any .ini files or system images; just make backups of the higher CDx (and ADx) keys and restore/delete them as needed.

I'd also make a copy of the full Cyberlink key so there's a reliable recovery of all the original keys.

I doubt reading through the registry for highest installed version is the approach or modifying the *.ini files would not have an effect, which multiple users clearly show it does.

Seems like the Interoperability should work without unloading/loading windows registry keys every time you want to run a compatible released product set. That's in essence what the *.ini files do is define proper product run configuration. I'd suspect CL support runs into this frequently supporting their diverse install user base and will hopefully have some easy compatible approach once the question was properly understood.

Jeff
Reply
tomasc [Avatar]
Senior Contributor Private Message Joined: Aug 25, 2011 12:33 Messages: 5532 Offline
[Post New]
Quote My question, have any multi PD install users identified how to fix the interoperability issues?

I am sure that someone will have the answer soon and post it. I find that all the previous versions of PD opens the latest installed CDR including PD12. Never pursued this interoperability issue since each of the earlier versions of CDR can be opened and used as a standalone app if desired.

This message was edited 1 time. Last update was at Jan 02. 2021 12:10

Reply
optodata
Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 6212 Offline
[Post New]
Quote Seems like the Interoperability should work without unloading/loading windows registry keys every time you want to run a compatible released product set.

I totally agree, I'm simply sharing what I saw when using ProcMon and that manipulating the registry keys provides the desired result. without very much effort.

It's only a workaround and not a substitute for a proper version interoperability across CL apps.
Reply
optodata
Senior Contributor Private Message Location: California, USA Joined: Sep 16, 2011 16:04 Messages: 6212 Offline
[Post New]
Here's a video I just made showing how quick and easy it is to swap which CD version is invoked from any version of PD. I didn't even need to close PD to make the changes:



Note that I had previously exported the CD4 and CD9 keys, which is mandatory to restore full functionality before deleting them.

I've tested this on PD13, 14 and 365(19) with CD3, 4 and 365(9). All combinations are accessible and PD doesn't need to be closed when making registry changes.
Reply
tomasc [Avatar]
Senior Contributor Private Message Joined: Aug 25, 2011 12:33 Messages: 5532 Offline
[Post New]
This is ingenious. The CD4 and CD9.reg keys were first exported before making the screen recording. The keys were deleted, and restored later from the desktop in the video. Don’t know if PIX used this method or the uninstall to perform his tests as the time signature is too close.
Reply
JL_JL [Avatar]
Senior Contributor Private Message Location: Arizona, USA Joined: Oct 01, 2006 20:01 Messages: 4692 Offline
[Post New]
I just wanted to close this thread out, after several dialogs back and forth with support, they had no solution to maintain proper interoperability to couple like released versions of their products together as was asked in the OP and the support ticket. They could only suggest continued uninstalling, reinstalling, patching products to get the proper combination of released products for that particular editing session.

So other than multiple different approaches to address deficiencies, no permanent solution identified for proper released version interoperability.

Supports final comment as typical was simply: "we've escalated the suggestion to the product team as a program improvement reference."

Jeff
Reply
Reply to this topic
Powered by JForum 2.1.8 © JForum Team