Refreshing metadata... Daz Connect "forgets" install available?
I currently have a mixture of DIM and Daz Connect items. Today, I refreshed my Connect metadata because my G8 essentials broke for some reason (note: I actually had to reinstall the product to correct the problem) and for some reason my database seems to have forgotten about all my DIM installs. That is, each product that is present no longer shows the "install available" dialog that is typically present in Connect on a DIM-installed product.
I'm presuming this is because CMS/Connect, when it detects a product from the support directory during the database refresh, doesn't know where the product originated from.
However, manually refreshing the metadata from DIM doesn't seem to fix the problem, but re-installing from DIM does. Is there another way to force DIM to update the entries in CMS such that the database knows that the product originated from DIM?
edit: Hmm, actually re-installing does not work for some products. At times, if I uninstall the product in DIM, it'll give a small notebook icon with a U in it under Smart Content. Weird.
Comments
The U icon is for user data - as opposed to product data - which certainly suggests something is agley in the database though I'm not sure what. You could try reimporting the metadata, but make sure that the content directories are correct (so that you can load the "uninstalled" files through the Content Library) first.
Well, that's unfortunate.
After some experimentation, I figured out that re-importing metadata will always break DIM installed items. Reinstalling them or re-importing the metadata in DIM was not a reliable fix, as it sometimes left uninstalled items in Daz Connect with the user data icon and no way to install in Daz Connect......
... until I logged off and logged back into Connect, which re-downloaded a list of my account's *uninstalled* products. For some reason, Connect refuses to recognize already installed but incorrectly recognized "user data" items as being installable as it forgot that they were installed through DIM... but did not recognize that the items could be installed once the items were uninstalled through DIM. Strange behavior, but I now know why it is happening.
My workaround now is to uninstall all the packages in DIM, log in and out of Connect, then reinstall the packages in DIM -- and cross-reference to see if anything didn't get reinstalled properly -- and hopefully this will fix the issue.
That sounds like a communication issue of some kind, or even a database problem (DIM writes to a different area of the database which then gets converted to the main area, so I suspect that corruption in the DIM-used area might cause problems without stoping the main part of the database from working).
User data is a protect species - it won't be updated by a reinstall/reimport (people complained, when it was, because updates wrecked their own changes). It is also protected during uninstall, which would be why it remains.
So long story short, there seems to be persistent metadata somewhere in both the support directories and elsewhere. I ended up having to reset my database from scratch in order to get through all of these issues.
However, I now have a different problem: Connect doesn't recognize items in my DAZ Connect folder, which is strange. Double-clicking on an item that's there doesn't work -- it'll redownload the entire product instead of reading the folder that's already there.
edit: nevermind, false alarm, it's only redownloading for some items :) Looks like I'll have to double-click on the items one by one...
edit2: exported the directory listing into excel, extracted all the folder names, then used a SKU expression to select everything and pressed install.
So... after running Daz Connect overnight, it's definitely re-downloading many items in my Connect folder. But there's definitely some items that Connect will scan over quickly and verify. I'm not sure what's happening because it definitely downloaded over 200GB overnight.
edit: The only reason I can think of is that many items were failing their hashes... which is odd.