Fixed issues with messaging on failed connections to be more accurate (some occurances incorrectly stated that the username or password were incorrect)

Fixed the “Update Metadata” action in context menus for products so that it now forces an update to the metadata cache rather than refreshing from the local cache

Fixed the LOCAL USER product image (./resources/images/local-user-product.png was missing)

Fixed an issue that could cause multiple unending connection attempts (prevented the application from successfully closing)

Fixed an issue where account credentials were not being converted before being handed to Daz Connect (caused login to fail when non-ASCII characters were used)

Fixed migration triggers for products where the StoreId is not “DAZ 3D” and/or where the ProductToken is empty

*Note:A "Configuration Changed" message is expected to display for all users that have logged into Daz Connect upon launching this build; until said user has logged into Daz Connect a minimum of one more time; the system configuration detection algorithm changed to resolve differences as noted above, so everyone is impacted. Note that switching between builds provided by the General Release channel and the Public Build channel (and the Private Build channel for those involved in that endeavor) will cause this message to display; until such time that the builds offered through all channels are using the same algorithm.

Important Notes:

The first time you launch Daz Studio 4.9, any data that exists in the content database is migrated so that it can be used in Daz Studio 4.9.

The amount of time the database migration operation takes is proportional to the amount of data to be migrated.

The database migration operation does not delete the data that it migrates from the previous location so that it remains accessible by earlier versions and other applications, such as Carrara.

Daz Studio 4.9 uses the same PostgreSQL database as Daz Studio 4.6 and later, and/or other applications, such as Carrara.

A portion of the data contained within the database is shared amongst versions but not entirely. For example:

Creating a category in either Daz Studio 4.9 or 4.8 will cause that category to exist in the other version

Assigning a file to that category in Daz Studio 4.9 will NOT cause that file to be assigned to that category in Daz Studio 4.8

Assigning a file to that category in Daz Studio 4.8 WILL cause the file to be assigned to the category in Daz Studio 4.9

Reseting the database in any version of Daz Studio that uses PostgreSQL (e.g., 4.6 or later) will purge all of data in the database, including any data that may be used by earlier versions or other applications, such as Carrara.

After the initial migration operation, edited metadata in Daz Studio 4.8 will not be migrated to Daz Studio 4.9.

A workaround is to export User Data from Daz Studio 4.8 and reimport User Data in Daz Studio 4.9.

Previous 4.9 Beta Threads:

Comments

What is new in this build? Do I need to update my copy?

This is a maintenance release. It resolves several issues discovered since the 4.9.0.63 General Release. The first post contains hightlights and more detail on specific fixes/changes/improvements can be found in the Change Log. All new downloads of the Daz Studio Pro BETA product (SKU: 12000) will be of this version.

While this release does address a number of issues relating to the preservation and/or restoration of User Data, it does not address all of them. As this build addresses the majority of outstanding User Data related issues, we have decided to move forward with the fixes that have been made thus far. We have identified, and are actively working on, another set of fixes that address some remaining User Data issues in a 4.9.2.x follow-up release.

If you had an issue where migration from Daz Studio 4.8 to Daz Studio 4.9 did not migrate your custom categories, or custom data please file a support ticket and explain that this happened to you. We do have a script that we will be handing out on a case by case basis to help recover that data, but it is not for everyone.

Is there a plan to update DIM so that it no longer writes to the database? Or to add other database editing tools to Studio?

Otherwise, people who use DIM primarily as a way to download and unzip archives -- rather than actually installing to their content directories -- are going to have databases with duplicate entries they can no longer get out of the database.

Yes, that function makes very much sense, to those who are not using DAZ Connect for installation.

I've been watching this developement and gave it every chance, but you are seriously alienating people here.

When an option ceases to do anything at all, except perhaps consume CPU cycles simply because a function (that does absolutely nothing now) is called, and the things it once operated on in an earlier database schema (i.e., content instances) are handled in a significantly different way in the current database schema, then it no longer makes sense to provide that option.

Now, it is understandable that an option named thusly could be misinterpreted to mean that choosing it caused an operation other than what it was actually doing to be performed (a problem with naming something vaguely enough to be considered less technical, but too vaguely to accurately represent a complex problem). Whether or not it makes sense to add a new option that does something that is more along the lines of what these options were misinterpreted to do, is a separate (albeit related) matter. Adding options that do make sense in the new way things are handled has been discussed for 4.9.2.x. But make no mistake, what these options actually did no longer make any sense whatsoever; as the thing they operated on is no longer a thing because said thing was found to be at the root of several issues that have caused quite a bit of user confusion over the past few years.

to be franly said,, I may need not everytime explore the Target ,,, I just need the item to wear actor,,,,, ,then serch by category without context,,not product,,,and need one base compatible actor. do not need many cute girls which I have (iclude man,, sometimes,,)

do not you think so----------------------------------------------??

just adding one cute filed in the area,, is more reasonable,,,, is it so hard work ?? please please please,,,.

Is there a plan to update DIM so that it no longer writes to the database? Or to add other database editing tools to Studio?

Otherwise, people who use DIM primarily as a way to download and unzip archives -- rather than actually installing to their content directories -- are going to have databases with duplicate entries they can no longer get out of the database.

No, there is not a plan to prevent Install Manager from installing metadata to the database. Understand that downloading a package through Install Manager does not automatically insert the metadata provided within that package into the database, rather the act of actually installing a package is what performs the insertion of metadata (if the CMS is running).

Are there plans to change which tables within the database are inserted into? Eventually. However, there are other applications (and earlier versions of Daz Studio still in use) that rely on the older database structure, and those uses have to be taken into account as well.

Are there plans to add options to Daz Studio that allow the older structure to be cleaned up? Eventually. Realize, however, that such an option already exists to a degree through the use of functionality that has been present in Daz Studio for quite a while (i.e., export user data, reset database, reimport metadata). The reason it isn't consolidated into a single convienent option (or as few options as make sense) in the Content DB Maintenance dialog is because there is still some work to be done here; e.g. the ability to repair a Daz Connect installed product (after the database has been reset) without prompting for login as opposed to re-installing a Daz Connect installed product (which, aside from offline packages, requires an active connection) and, because the files to be installed are already present on disk where they are expected to be, skipping the download/install part of the process and simply re-inserting the metadata that allows them to be displayed.

The 4.9.1.x builds are not intended to address every issue (as has already been stated above). They are intended to address several issues that block a subset of the userbase from using 4.9 as it was intended. The 4.9.2.x builds (which are also already being worked on) will address additional issues wherein the associated risk is greater and so requires more time/testing. There is no point in forcing users whose issues are resolved by the 4.9.1.x builds to continue to wait while development continues on the issues that do not affect them. If we took the approach that all issues must be resolved before any build can be released, there would never be any releases because there will always be issues. That is the nature of software development.

Yes, that function makes very much sense, to those who are not using DAZ Connect for installation.

I've been watching this developement and gave it every chance, but you are seriously alienating people here.

When an option ceases to do anything at all, except perhaps consume CPU cycles simply because a function (that does absolutely nothing now) is called, and the things it once operated on in an earlier database schema (i.e., content instances) are handled in a significantly different way in the current database schema, then it no longer makes sense to provide that option.

Now, it is understandable that an option named thusly could be misinterpreted to mean that choosing it caused an operation other than what it was actually doing to be performed (a problem with naming something vaguely enough to be considered less technical, but too vaguely to accurately represent a complex problem). Whether or not it makes sense to add a new option that does something that is more along the lines of what these options were misinterpreted to do, is a separate (albeit related) matter. Adding options that do make sense in the new way things are handled has been discussed for 4.9.2.x. But make no mistake, what these options actually did no longer make any sense whatsoever; as the thing they operated on is no longer a thing because said thing was found to be at the root of several issues that have caused quite a bit of user confusion over the past few years.

-Rob

So, just to be sure that I understand what that meant: you're saying that even though "Remove orphaned file references" and "Consolidate file references" appeared to work, they actually did not function correctly because they were designed for Valentina and not for PostgreSQL. Is that right?

Is there a plan to update DIM so that it no longer writes to the database? Or to add other database editing tools to Studio?

Otherwise, people who use DIM primarily as a way to download and unzip archives -- rather than actually installing to their content directories -- are going to have databases with duplicate entries they can no longer get out of the database.

No, there is not a plan to prevent Install Manager from installing metadata to the database. Understand that downloading a package through Install Manager does not automatically insert the metadata provided within that package into the database, rather the act of actually installing a package is what performs the insertion of metadata (if the CMS is running). [...] Are there plans to add options to Daz Studio that allow the older structure to be cleaned up? Eventually. Realize, however, that such an option already exists to a degree through the use of functionality that has been present in Daz Studio for quite a while (i.e., export user data, reset database, reimport metadata).

OK.

Although that should probably be amended to "if the CMS is present", since DIM seems to insert metadata into my database without ever being able to start it (according to the log file), which I find impressively baffling, but things seemed to work, so ... whatever. (Er ... that "whatever" wasn't directed at you. That was my reaction when I realized what DIM said it was and wasn't doing, since it didn't seem possible, but as I say, it worked.)

How does the export-reset-reimport process clean up the database? Wouldn't it just export whatever was in the database so that any duplicates or errors would be maintained?

All I want is a way to reintroduce my home made meta data into the fold rather than have it grouped under the umbrella of "Local User" I don't understand nor agree with this as being "correct" as stated by DAZ from my ticket or Spooky in another thread. It was not the "norm" in 4.8, I could find my stuff right along with the other categorized products regardless of WHERE the product was sold be it here, Hivewire, Renderosity or even a freebie maker that took the time to make meta data.... makes no sense and continues to make no sense to me regardless of the in house thinking around all this.... It's very off putting regardless!! I mean all the Hivewire items are not even categorized any more, they are under Unassigned ... how does that happen? Becuase it's not in house? If so that's just bunk! Products are products and if the artist takes the time to make proper meta data tags then this all should be where it should be...........

Yes, that function makes very much sense, to those who are not using DAZ Connect for installation.

I've been watching this developement and gave it every chance, but you are seriously alienating people here.

When an option ceases to do anything at all, except perhaps consume CPU cycles simply because a function (that does absolutely nothing now) is called, and the things it once operated on in an earlier database schema (i.e., content instances) are handled in a significantly different way in the current database schema, then it no longer makes sense to provide that option.

Now, it is understandable that an option named thusly could be misinterpreted to mean that choosing it caused an operation other than what it was actually doing to be performed (a problem with naming something vaguely enough to be considered less technical, but too vaguely to accurately represent a complex problem). Whether or not it makes sense to add a new option that does something that is more along the lines of what these options were misinterpreted to do, is a separate (albeit related) matter. Adding options that do make sense in the new way things are handled has been discussed for 4.9.2.x. But make no mistake, what these options actually did no longer make any sense whatsoever; as the thing they operated on is no longer a thing because said thing was found to be at the root of several issues that have caused quite a bit of user confusion over the past few years.

-Rob

So, just to be sure that I understand what that meant: you're saying that even though "Remove orphaned file references" and "Consolidate file references" appeared to work, they actually did not function correctly because they were designed for Valentina and not for PostgreSQL. Is that right?

I believe it's not a Valentina/PostgreSQL issue but rather the structure of the database - 4.9 uses a different structure from 4.8 and earlier and so, among other things, can't have instances and need the user to say which version they want when double-clicking a file. The removed functions worked on those features of the 4.8 and earlier database, which aren't in the 4.9 structure, and so would do nothing in 4.9 (and the specific database management issues they addressed won't affect 4.9).

then why DAZ do not offer more easy way to add shop ID for other package, .I do not know, why it distrub DAZ business.

Only DAZ can only offer content, by DAZ connect, and DAZ DIM. then keep DAZ shop ID , as unalterable. for each asset of product. but User set shop ID for non DAZ contents cause no problem,

In part, because I've been occupied with matters that are deemed "higher priority." In part, because I've had little to none of "my own time" to donate over the last several months (refer to the previous sentence). In part, because the ability to remove a Store (in the case of a typo or incorrect configuration) whilst protecting some assumed values (i.e., DAZ 3D and LOCAL USER) through a public API did not exist—you'll notice from the highlights in the first post and the change log, that I have added this piece recently (in what little of "my own time" I've managed in recent days). I have also written a few scripting samples recently that do the work that is required for adding/removing a Store to the database so that metadata for products against that Store can be inserted, and I am in the process of resolving some recent performance issues with the Documentation Center server so that I can post said samples (along with a considerable amount of additional scripting API documentation). Said scripting samples are (intentionally) extremely easy to modify.

Yes, that function makes very much sense, to those who are not using DAZ Connect for installation.

I've been watching this developement and gave it every chance, but you are seriously alienating people here.

When an option ceases to do anything at all, except perhaps consume CPU cycles simply because a function (that does absolutely nothing now) is called, and the things it once operated on in an earlier database schema (i.e., content instances) are handled in a significantly different way in the current database schema, then it no longer makes sense to provide that option.

Now, it is understandable that an option named thusly could be misinterpreted to mean that choosing it caused an operation other than what it was actually doing to be performed (a problem with naming something vaguely enough to be considered less technical, but too vaguely to accurately represent a complex problem). Whether or not it makes sense to add a new option that does something that is more along the lines of what these options were misinterpreted to do, is a separate (albeit related) matter. Adding options that do make sense in the new way things are handled has been discussed for 4.9.2.x. But make no mistake, what these options actually did no longer make any sense whatsoever; as the thing they operated on is no longer a thing because said thing was found to be at the root of several issues that have caused quite a bit of user confusion over the past few years.

-Rob

So, just to be sure that I understand what that meant: you're saying that even though "Remove orphaned file references" and "Consolidate file references" appeared to work, they actually did not function correctly because they were designed for Valentina and not for PostgreSQL. Is that right?

I believe it's not a Valentina/PostgreSQL issue but rather the structure of the database - 4.9 uses a different structure from 4.8 and earlier and so, among other things, can't have instances and need the user to say which version they want when double-clicking a file. The removed functions worked on those features of the 4.8 and earlier database, which aren't in the 4.9 structure, and so would do nothing in 4.9 (and the specific database management issues they addressed won't affect 4.9).

What I expected this to do is actually save the filter settings of each sub tab individually.

Currently it seems the filter options are now forced upon each other subtab when changing it in just one subtab.

- - -

Example:

What I like it to save is:

All: Sort by Product ID: Highest First

Installed: Sort by Name

Available: Sort by Order Date Recent first

- - -

What currently happens is:

When I set "Available" to "Sort by Order Date Recent first" all the other sub tabs ( Installed, All) are also switched to the same filter options.

- - -

- Is that working as intended or is this a bug?

- Could it be possible to improve the system to save the selected filter option for each subtab indiviually?

The Install State Filter Bar, at the bottom of the Products Page, does not actually switch between independent filtered pages, each with their own respective lists of results. Rather, selecting a filter on the bar applies that filter on top of what would otherwise be the result of selecting the "All" filter (which actually means "do not apply any install state filter at all" but "All" fit much better in the confined space and conveys the same basic message). The Sorting Selector is actually a sibling to the bar, not a child of a page contained by it.

This does not mean it cannot be made to behave differently, rather it gives some insight into why it behaves the way that it does. Making it behave the way you describe was discussed as a possibility before it was implemented as it is now, but after a bit of back and forth it was concluded to have a net-negative impact where having the ability also forces the responsibility—i.e., instead of being something that CAN be done for some users in some cases, it becomes something that MUST be done by all users in all cases.

So, just to be sure that I understand what that meant: you're saying that even though "Remove orphaned file references" and "Consolidate file references" appeared to work, they actually did not function correctly because they were designed for Valentina and not for PostgreSQL. Is that right?

I believe it's not a Valentina/PostgreSQL issue but rather the structure of the database - 4.9 uses a different structure from 4.8 and earlier and so, among other things, can't have instances and need the user to say which version they want when double-clicking a file. The removed functions worked on those features of the 4.8 and earlier database, which aren't in the 4.9 structure, and so would do nothing in 4.9 (and the specific database management issues they addressed won't affect 4.9).

...OK, I think I sort of get this.

If you have DIM download and unzip to one directory, rearrange however you want, and then copy to another directory to use the Content Library (and I'm not talking at all about Daz Connect-installed things here, because I do understand that it doesn't work that way), you'll have a cluttered database, but you'll sorta kinda be fine. And there's nothing you can really do about that clutter unless you're willing to plunge into Smart Content and clean things up manually.

Assuming that the "Scan mapped directories for content" option continues to operate as it has, Smart Content may be able to find a moved item, but it may get shifted into "Local User" rather than where you'd expect it to be?

Will Smart Content show a broken icon for the item in the unmapped directory, and the actual icon (with, in all likelihood, thoroughly distressed metadata) where it actually exists, or will you have two broken icons and need to do more manual repair? (I realize that doing all that file movement breaks some of the connections between Smart Content and the database; I just want to make sure that other database-dependent functions, such as Transfer Utility, continue to function properly.)

With a 4.9 database, if, for example, you have it scan mapped directories for content, will it now automatically say, "Oh, this directory here is unmapped, therefore it's getting removed by default"?

I'm not trying to be obstreporous, truly; I'm just trying to understand how it all fits together, and whether this cleanup now gets handled behind the scenes because 4.9 doesn't deal with multiple instances of the same file, or if it doesn't get handled at all and you wind up with a wild and furry database if you don't do some work to prevent that.

And I do realize that this is sort of an edge case, so thank you both for taking the time to work through it with me.

Although that should probably be amended to "if the CMS is present", since DIM seems to insert metadata into my database without ever being able to start it (according to the log file), which I find impressively baffling, but things seemed to work, so ... whatever. (Er ... that "whatever" wasn't directed at you. That was my reaction when I realized what DIM said it was and wasn't doing, since it didn't seem possible, but as I say, it worked.)

The CMS being present is an implied prerequisite—it must be present to be running, however being present does not require it to also be running—ergo "if the CMS is running." If the CMS is not running, metadata cannot be inserted into the database—it simply does not work any other way. That being said, and given the injection of Valentina DB into the discussion, I will point out that, while Install Manager will still fall back to the Valentina DB CMS if the PostgreSQL CMS cannot be found (and Valentina DB is installed/running), Daz Studio 4.9 drops support of Valentina DB altogether (see Has the Content Management Service (CMS) changed?). In either case, your description of what did/didn't happen does not provide enough of the right information to determine what exactly happened, or why.

How does the export-reset-reimport process clean up the database? Wouldn't it just export whatever was in the database so that any duplicates or errors would be maintained?

It doesn't "clean up the database" in the more general sense (i.e., fix bad data that results from manual fiddling), rather it "allow[s] the older structure to be cleaned up" (i.e., purges duplicate data in the 4.8 tables) and inserts a single copy of that data in the 4.9 tables. But again, this option is not for those that use applications that rely on the 4.6/4.7/4.8 database structure, and it is not entirely automatable yet.

In part, because I've been occupied with matters that are deemed "higher priority." In part, because I've had little to none of "my own time" to donate over the last several months (refer to the previous sentence). In part, because the ability to remove a Store (in the case of a typo or incorrect configuration) whilst protecting some assumed values (i.e., DAZ 3D and LOCAL USER) through a public API did not exist—you'll notice from the highlights in the first post and the change log, that I have added this piece recently (in what little of "my own time" I've managed in recent days). I have also written a few scripting samples recently that do the work that is required for adding/removing a Store to the database so that metadata for products against that Store can be inserted, and I am in the process of resolving some recent performance issues with the Documentation Center server so that I can post said samples (along with a considerable amount of additional scripting API documentation). Said scripting samples are (intentionally) extremely easy to modify.

-Rob

Thank you, I can wait you complete documentes about new 4.9 DB system.

then I have still some questions, about usage of

"user_data.dsx" and new "12345678_LOCAL_USER.dsx" ( dsx of local user product) properly for buck-up DB records.

eg I set some duf as new product,, then I remove the duf reference from the Local_User rpoduct, too.

now on daz studio, (current DB) I can not see the duf as Local_User product.. (it is good for me)

then I hope to buck-up current DB records .

I think I need to export the Local_User product.dsx too,, to buck up my modify, is not it?

And if it is not recommended,, (remove assets reference from Local_User product) , is there any demerit ?

(eg it may cause problem to re-import it,, lost category etc,,,or may conflict with user_data.dsx? )

I think,, many records included in one user_data.dsx,, may cause more difficulity to keep and check my editting for each assets.

it is same about Local_user product,, actually I feel difficulity to serch my assets, in Local_user product.dsx

when I hope to edit it..(in content DB editor,, or when I check record by xml editor,,,too)

then prefer to manage not by user_data.dsx but by each small product.dsx package.

Although that should probably be amended to "if the CMS is present", since DIM seems to insert metadata into my database without ever being able to start it (according to the log file), which I find impressively baffling, but things seemed to work, so ... whatever. (Er ... that "whatever" wasn't directed at you. That was my reaction when I realized what DIM said it was and wasn't doing, since it didn't seem possible, but as I say, it worked.)

The CMS being present is an implied prerequisite—it must be present to be running, however being present does not require it to also be running—ergo "if the CMS is running." If the CMS is not running, metadata cannot be inserted into the database—it simply does not work any other way. That being said, and given the injection of Valentina DB into the discussion, I will point out that, while Install Manager will still fall back to the Valentina DB CMS if the PostgreSQL CMS cannot be found (and Valentina DB is installed/running), Daz Studio 4.9 drops support of Valentina DB altogether (see Has the Content Management Service (CMS) changed?). In either case, your description of what did/didn't happen does not provide enough of the right information to determine what exactly happened, or why.

My apologies, I shouldn't have mentioned that. It turns out to be related to something that got fixed earlier. I didn't mean to inject more confusion into things.

And I don't use Bryce or Carrara, so I don't have Valentina installed. Thank goodness; Valentina got corrupted almost monthly toward the end.

It doesn't "clean up the database" in the more general sense (i.e., fix bad data that results from manual fiddling), rather it "allow[s] the older structure to be cleaned up" (i.e., purges duplicate data in the 4.8 tables) and inserts a single copy of that data in the 4.9 tables. But again, this option is not for those that use applications that rely on the 4.6/4.7/4.8 database structure, and it is not entirely automatable yet.

I would like to thank you developers to include this welcome feature. This IDs will be very helpful specially when they are being used in future and updated products. I think it is also a necessary step to make Smart Content in some future release to auto detect which is the best material or shader to be selected in the context.

Also, the flaws in Smart Content seems mostly fixed in this version. The application is running without any visible issue for me. I was able to detect that the culprit of my CDT on Studio exit was and older plug-in file which maybe was installed manually in some previous version. After cleanup the plug-in folder and reintall my plug-ins the issue vanish.

Still not using DAZ Connect as metadata auto retrieve brokes my workflow and seems unacceptable to me, but 4.9 in overall is a solid update. Good job DAZ and thank you again.

I start adding material shaders to my scene after about 6 shaders loaded i can not load anymore to my scene or if i am loading materail shaders they are not appearing on the objects in my scene if i save the scene and reload still I cannot load material shader I have to close studio and completely start again very odd and very frustrating