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?
The PostgreSQL does not start on my Mac installation. Start CMS manually also does not works. Fallback works as mentioned, if I uninstall PostgreSQL, DS Beta uses Valentina.
How can I start the new CMS?
When you launch either Install Manager or DAZ Studio it should automatically launch. We have run into issues where it does not launch from DAZ Studio if you have just closed Install Manager, of just closed DAZ Studio and it hasn't finished its clean up before you launch/relaunch DAZ Studio.
Could that be what is happening here?
Also note the external start and stop CMS is for Valentina and not for PostgreSQL. (The ones from start or in the folder, not the ones in DAZ Studio.)
I don't think so. DIM also reports an "Error connecting to CMS". The same message from DS 4.6.3.29 log.
I tried uninstall and re-install the Postgre Package twice. Looking at the Activity Monitor I cannot see the Postgre service running.
Let me know if I can try any other trick.
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+
The PostgreSQL does not start on my Mac installation. Start CMS manually also does not works. Fallback works as mentioned, if I uninstall PostgreSQL, DS Beta uses Valentina.
How can I start the new CMS?
When you launch either Install Manager or DAZ Studio it should automatically launch. We have run into issues where it does not launch from DAZ Studio if you have just closed Install Manager, of just closed DAZ Studio and it hasn't finished its clean up before you launch/relaunch DAZ Studio.
Could that be what is happening here?
Also note the external start and stop CMS is for Valentina and not for PostgreSQL. (The ones from start or in the folder, not the ones in DAZ Studio.)
I don't think so. DIM also reports an "Error connecting to CMS". The same message from DS 4.6.3.29 log.
I tried uninstall and re-install the Postgre Package twice. Looking at the Activity Monitor I cannot see the Postgre service running.
Let me know if I can try any other trick.
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+
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 .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.
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
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.
The PostgreSQL does not start on my Mac installation. Start CMS manually also does not works. Fallback works as mentioned, if I uninstall PostgreSQL, DS Beta uses Valentina.
How can I start the new CMS?
When you launch either Install Manager or DAZ Studio it should automatically launch. We have run into issues where it does not launch from DAZ Studio if you have just closed Install Manager, of just closed DAZ Studio and it hasn't finished its clean up before you launch/relaunch DAZ Studio.
Could that be what is happening here?
Also note the external start and stop CMS is for Valentina and not for PostgreSQL. (The ones from start or in the folder, not the ones in DAZ Studio.)
I don't think so. DIM also reports an "Error connecting to CMS". The same message from DS 4.6.3.29 log.
I tried uninstall and re-install the Postgre Package twice. Looking at the Activity Monitor I cannot see the Postgre service running.
Let me know if I can try any other trick.
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?
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.
Note that the way PostgreSQL works you can have multiple databases for multiple applications and they won’t step on each other.
Yes, I'm aware of this. I already use different databases for different applications.
1. We are using the current version of PostgreSQL as of about 2 weeks ago.
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.)
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.
No problem to be on my own here, but how do you create the roles, tablespaces, schemas, tables etc. without scripts? Can you at least provide the information about the data structure? Do you use a fix name for the database, the schema, for the login role, ...?
To be honest, I don't think I would allow an application to make any changes on my DB settings without to be able to control it. I'm pretty sure I'm not the only one ;-)
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
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:
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.
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.
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.
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
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:
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.
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)?
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)?
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.
@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.
Absolutely correct. (And said better than I would have said it. :) )
It is not designed to interact with any other PostgreSQL databases.
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)?
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.
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)?
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)
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.
That sounds like either a virus checker or firewall performing a deepscan on launch. (For either DS or PostgreSQL or both.) You should be able to "Whitelist" those, after it performs the scan the first time of course, to change that behavior, or it will keep doing that until your Virus Checker and/or firewall gets enough reports to whitelist it on an update.
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)?
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.
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.
Thank you for this. Found the updates and installed.
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.