Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Did that too.
Afraid that's all I got. Sorry. :down: Like MBusch, I can't get the new CMS to work.
Just to be perfectly clear about the new PostgreSQL DB with the Public Beta.
If I download and install using DIM, will I still be able to use DS 4.6.2.120 with CMS and the Valentina BD?
Just want to be sure.
Yes, the Valentina CMS will still work for the general release (and for the beta if you don't install the PostgreSQL CMS).
ETA: but DIM will add new metadata to the PostgreSQL DB if it is installed and not the Valentina DB .
Hello!
Nice to hear that PG will be the new DB for the content manager.
I already use PG for a some other applications and because of this I have the following questions:
1) Does DS rely on a specific version of PG?
2) Are the SQL scripts available to install the user, tables... manually? (I prefer to have the control about the things that will be added/modified to my DB)
3) Is it possible to configure DS how to connect to PG?
Thanks in advance for any hint.
With kind regards,
Ruediger Kabbasch
I have seen something similar when there was a crash on Install.
You can try this.
1. Shut Down DS and/or Install Manager and give it time to exit.
2. Kill the still running PostgreSQL instances.
3. Open Install Manager and see if PostgreSQL is installed, if it is uninstall it.
4. Reinstall PostgreSQL.
If that doesn't work please file a ticket so we can work with you one on one and get it cleared up for you.
Tried hard. It just does not works. No Postgre process running at all. I filled a Support Ticket and attached DIM and DS logs.
Hum, maybe I found the error: looking at DIM's Hlog.txt I see these messages:
Executing file: PostgreSQL CMS_9.3.4/DAZ 3D/PostgreSQL CMS/im/initialize.dzime
File: PostgreSQL CMS_9.3.4/DAZ 3D/PostgreSQL CMS/im/initialize.dzime was in manifest but not found in zip : PostgreSQL CMS (Mac) Public Build +Beta+
It could be?
I uninstalled, rebooted and reinstalled the new CMS files a few times and re-imported the metadata and CMS is now working for me.
I have seen something similar when there was a crash on Install.
You can try this.
1. Shut Down DS and/or Install Manager and give it time to exit.
2. Kill the still running PostgreSQL instances.
3. Open Install Manager and see if PostgreSQL is installed, if it is uninstall it.
4. Reinstall PostgreSQL.
If that doesn't work please file a ticket so we can work with you one on one and get it cleared up for you.
Tried hard. It just does not works. No Postgre process running at all. I filled a Support Ticket and attached DIM and DS logs.
Hum, maybe I found the error: looking at DIM's Hlog.txt I see these messages:
Executing file: PostgreSQL CMS_9.3.4/DAZ 3D/PostgreSQL CMS/im/initialize.dzime
File: PostgreSQL CMS_9.3.4/DAZ 3D/PostgreSQL CMS/im/initialize.dzime was in manifest but not found in zip : PostgreSQL CMS (Mac) Public Build +Beta+
It could be?
Hello,
Which version of Mac OS X are you running?
Yes, the Valentina CMS will still work for the general release (and for the beta if you don't install the PostgreSQL CMS).
ETA: but DIM will add new metadata to the PostgreSQL DB if it is installed and not the Valentina DB .Note you can reimport Metadata in the 4.6.2.120 version of DS and that will add your new content to the Valentina DB.
Note that the way PostgreSQL works you can have multiple databases for multiple applications and they won't step on each other.
1. We are using the current version of PostgreSQL as of about 2 weeks ago.
2. Not at this time, though if you want to create such scripts you could, however we are not supporting that, at this time, you are on your own.
3. Other than port and location, in theory, yes, however we aren't supporting it at this time, you are on your own.
Tried hard. It just does not works. No Postgre process running at all. I filled a Support Ticket and attached DIM and DS logs.
Hum, maybe I found the error: looking at DIM's Hlog.txt I see these messages:
Executing file: PostgreSQL CMS_9.3.4/DAZ 3D/PostgreSQL CMS/im/initialize.dzime
File: PostgreSQL CMS_9.3.4/DAZ 3D/PostgreSQL CMS/im/initialize.dzime was in manifest but not found in zip : PostgreSQL CMS (Mac) Public Build +Beta+
It could be?
Hello,
Which version of Mac OS X are you running?
Running OS X 10.9.2. Just to clarify: initialize.dzime is present in the zip package and was installed. The executing command is pointing to the wrong path, it should be Applications/DAZ 3D/PostgreSQL CMS/im/initialize.dzime
For those people having issues finding the Public Beta in Install Manager. If it still doesn't show up, please make sure you don't have the Public Beta Hidden.
Thanks Spooky, that last screen grab did the trick...
Thanks for your reply Spooky!
O.K., but do DS rely on this version? To make my question more precise: Which versions of PG do you support?
(I ask this just because it's not possible for me to uninstall/install PG just to keep DS running.)
Thanks again for any information.
While you are correct, the first part of the path is "wrong"... "Applications" would be "wrong" in the same way. The base folder of the path doesn't matter for scripts that are executed from their extracted paths, "post" install; the base folder in the path is [explicitly] ignored in this case. Where it does matter is when a script is executed "pre" install, before any files are extracted, as the path actually references the structure within the zip itself. That said, this particular script is run "post" install, so even though the base folder name is not consistent with the structure of the zip... it doesn't matter, because it's [explicitly] ignored anyway. We will be fixing the "not found in zip" error, but that is not what is at fault here; the script runs as expected on several machines also running OS X 10.9.2 that we've tested on, regardless of this log entry.
What the script does is build the installed cmscfg.json file*, such that it references the bin directory of the PostgreSQL installation. This is how Install Manager and DAZ Studio know where the PostgreSQL binaries are located; e.g. so they can, for instance, start and stop the PostgreSQL server when they start/stop. This file also serves as the switch for whether the applications fall back to using the Valentina DB; if the file exists and the information within it is valid, use PostgreSQL, if either of those is not true, fall back to Valentina.
*You can "Show Installed Files..." from the context menu (right click) or option menu (far right arrow) for the PostgreSQL package, and then click the link for "/DAZ 3D/CMS/cmscfg.json" to open the folder in the OS file browser.
This is what the file looks like [by default] on Windows:
This is what the file looks like [by default] on Mac:
If your file doesn't look like one of the above, then the script didn't execute. If it does, which I suspect it will, then the problem lay elsewhere...
What I suspect is actually at play here, is permissions settings on the executable files themselves. A script used in the publishing process, for converting a Private Build package to a Public Build package, unzips the package on a Windows machine, makes a couple of tweaks to non-executable files and then zips it back up. The act of unzipping a package intended for a Mac, built on a Mac, on a Windows machine will cause important permissions settings to be lost in the process. I'm looking into it now... and if that turns out to be the case, I'll be updating the package once we've tested it.
-Rob
Greetings,
Hrm; I haven't gotten it running yet myself. (I've tried reinstalling and such.)
@ruekaka - I believe that they run their own PGSQL instance, custom configured for their apps needs. If it collides with your instance you should edit what DAZ Studio expects the port to be, that way their locally running instance likely won't have issues with yours. I'm fairly sure they won't be able to use an arbitrary local PGSQL, especially given that they expect to be able to start and stop it with the app.
My longer-term desire would be to do something completely wacky: not have to run Postgres locally at all, but have it connect to a machine that I control on the larger internet. (My dedicated host is nicely firewalled off so that only certain machines under my control can reach the DB's ports on that remote system.) That way all my machines can interact with the same CMS database. They already share the content directory via Dropbox, so the underlying directory structure is mirrored.
Given what I've seen so far, it looks like that's not possible yet, but this is a small first step in that direction.
-- Morgan
being new to DAZ betas, how does one submit a bug report? The Age of Armour Advanced lights and the Atmospheric cameras have a few issues, I think
Use Help > Contact Us to submit a ticket to Tech Support, with "Bug Report" in the title.
If you never had the beta before installing those items, they only installed to the general release. If you uninstall and reinstall them with DIM after the beta is installed they will install to both the general release and the beta.
huh - go figure.. that fixed it..
Thanks!
While you are correct, the first part of the path is "wrong"... "Applications" would be "wrong" in the same way. The base folder of the path doesn't matter for scripts that are executed from their extracted paths, "post" install; the base folder in the path is [explicitly] ignored in this case. Where it does matter is when a script is executed "pre" install, before any files are extracted, as the path actually references the structure within the zip itself. That said, this particular script is run "post" install, so even though the base folder name is not consistent with the structure of the zip... it doesn't matter, because it's [explicitly] ignored anyway. We will be fixing the "not found in zip" error, but that is not what is at fault here; the script runs as expected on several machines also running OS X 10.9.2 that we've tested on, regardless of this log entry.
What the script does is build the installed cmscfg.json file*, such that it references the bin directory of the PostgreSQL installation. This is how Install Manager and DAZ Studio know where the PostgreSQL binaries are located; e.g. so they can, for instance, start and stop the PostgreSQL server when they start/stop. This file also serves as the switch for whether the applications fall back to using the Valentina DB; if the file exists and the information within it is valid, use PostgreSQL, if either of those is not true, fall back to Valentina.
*You can "Show Installed Files..." from the context menu (right click) or option menu (far right arrow) for the PostgreSQL package, and then click the link for "/DAZ 3D/CMS/cmscfg.json" to open the folder in the OS file browser.
This is what the file looks like [by default] on Windows:
This is what the file looks like [by default] on Mac:
If your file doesn't look like one of the above, then the script didn't execute. If it does, which I suspect it will, then the problem lay elsewhere...
What I suspect is actually at play here, is permissions settings on the executable files themselves. A script used in the publishing process, for converting a Private Build package to a Public Build package, unzips the package on a Windows machine, makes a couple of tweaks to non-executable files and then zips it back up. The act of unzipping a package intended for a Mac, built on a Mac, on a Windows machine will cause important permissions settings to be lost in the process. I'm looking into it now... and if that turns out to be the case, I'll be updating the package once we've tested it.
-Rob
Thanks Rob for clarify the workflow. I think you should be correct about the issue: probably is a permission settings. Both *. dzime files not have executable permissions. I changed their permissions in terminal command line, but they still not execute.
Do you install using an account that can admin (do sudo)?
Do you install using an account that can admin (do sudo)?
Yes, I am sure that.
Erm ...
Public build installed, new CMS installed, Public DS and DIM access the new CMS. Everything working.
But -
When I start the Public DS now - every time, this is, not just the first time - the DS splash window appears promptly, but then just sits there for about 4 minutes 40 seconds with the little message 'Connecting to CMS' shown in the splash window. Then it finally gets on with it, various other messages appear instead of the connecting to CMS one, and in about 20 seconds the DS main window opens. This is despite the fact that the new CMS's multiple processes appear in the task window within seconds of starting DS.
Similarly, if I start DIM (DS not running), although the DIM and new CMS processes appear in the Task Window immediately, there is no other indication at all that DIM is actually starting for somewhat over four minutes, at which point the DIM main window finally appears.
Something's not right. DS and DIM shouldn't be hanging around for between four and five minutes just trying to connect to the new CMS during load. And they DO connect to the new CMS eventually, so it's not just that they are hanging trying to connect to a broken CMS.
Absolutely correct. (And said better than I would have said it. :) )
It is not designed to interact with any other PostgreSQL databases.
Yes, I am sure that.We think we have it figured out, and why it works here at DAZ plus on our tester's systems. The one that went out with this Public Beta was zipped on a Windows machine. The one we have installed on Macs here at DAZ, and sent to our smaller test team and used in testing before sending this to you guys was zipped on a Mac. Zipping an application on Windows can cause permission errors on the Mac.
Working on getting a new build together. Oops.
Nice catch!
Guessing on permissions, but the wrong permissions it was (as Yoda would have put it)
Yes, I am sure that.Hey Mario,
I just responded to your Support ticket. (In case it isn't sending out proper e-mails. LOL)
Yes, I am sure that.Hey Mario,
I just responded to your Support ticket. (In case it isn't sending out proper e-mails. LOL)
Thanks, I got the message and tested the new package. It does not work still. I send comments in the ticket.
Thank you for this. Found the updates and installed.