DAZ Studio Pro BETA - version 4.6.3.29!

24567

Comments

  • RAMWolffRAMWolff Posts: 8,079
    edited December 1969

    Did that too.

  • SiennaBlueSiennaBlue Posts: 194
    edited December 1969

    Afraid that's all I got. Sorry. :down: Like MBusch, I can't get the new CMS to work.

  • stiks1954stiks1954 Posts: 151
    edited December 1969

    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.

  • FixmypcmikeFixmypcmike Posts: 17,301
    edited April 2014

    Stiks1954 said:
    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 .

    Post edited by Fixmypcmike on
  • ruekakaruekaka Posts: 330
    edited December 1969

    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

  • MBuschMBusch Posts: 533
    edited December 1969

    MBusch said:
    MBusch said:
    MBusch said:
    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?

  • SiennaBlueSiennaBlue Posts: 194
    edited December 1969

    I uninstalled, rebooted and reinstalled the new CMS files a few times and re-imported the metadata and CMS is now working for me.

  • TotteTotte Posts: 9,794
    edited December 1969

    MBusch said:
    MBusch said:
    MBusch said:
    MBusch said:
    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?

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Stiks1954 said:
    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.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    ruekaka said:
    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


    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.

  • MBuschMBusch Posts: 533
    edited December 1969

    Totte said:
    MBusch said:
    MBusch said:
    MBusch said:
    MBusch said:
    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

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited April 2014

    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.

    Filters.jpg
    551 x 517 - 132K
    Filterlocation.jpg
    438 x 350 - 57K
    Post edited by DAZ_Spooky on
  • RAMWolffRAMWolff Posts: 8,079
    edited December 1969

    Thanks Spooky, that last screen grab did the trick...

  • ruekakaruekaka Posts: 330
    edited December 1969

    Thanks for your reply Spooky!


    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 ;-)

    Thanks again for any information.

  • rbtwhizrbtwhiz Posts: 1,431
    edited December 1969

    MBusch said:
    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:

    {
     "PgBin": "C:/Program Files/DAZ 3D/PostgreSQL CMS/bin"
    }

    This is what the file looks like [by default] on Mac:

    {
     "PgBin": "/Applications/DAZ 3D/PostgreSQL CMS/bin"
    }

    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

  • CypherFOXCypherFOX Posts: 3,294
    edited December 1969

    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

  • hacsarthacsart Posts: 758
    edited December 1969

    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

  • FixmypcmikeFixmypcmike Posts: 17,301
    edited December 1969

    hacsart said:
    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.

  • hacsarthacsart Posts: 758
    edited December 1969

    huh - go figure.. that fixed it..

    Thanks!

  • MBuschMBusch Posts: 533
    edited December 1969

    rbtwhiz said:
    MBusch said:
    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:

    {
     "PgBin": "C:/Program Files/DAZ 3D/PostgreSQL CMS/bin"
    }

    This is what the file looks like [by default] on Mac:

    {
     "PgBin": "/Applications/DAZ 3D/PostgreSQL CMS/bin"
    }

    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.

  • TotteTotte Posts: 9,794
    edited December 1969

    MBusch said:

    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)?

  • MBuschMBusch Posts: 533
    edited December 1969

    Totte said:
    MBusch said:

    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.

  • DavidGBDavidGB Posts: 538
    edited December 1969

    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.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    Cypherfox said:

    @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.

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited April 2014

    MBusch said:
    Totte said:
    MBusch said:

    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.

    Working on getting a new build together. Oops.

    Post edited by DAZ_Spooky on
  • TotteTotte Posts: 9,794
    edited December 1969

    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)

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited December 1969

    MBusch said:
    Totte said:
    MBusch said:

    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)

  • DAZ_SpookyDAZ_Spooky Posts: 3,100
    edited April 2014

    DavidGB said:
    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.

    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.
    Post edited by DAZ_Spooky on
  • MBuschMBusch Posts: 533
    edited December 1969

    MBusch said:
    Totte said:
    MBusch said:

    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.

  • Kismet2012Kismet2012 Posts: 3,338
    edited December 1969

    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.

Sign In or Register to comment.