Mac OSX: Missing files even though Content Manager is set up correctly

aglaia0531_b84979d841

I recently migrated to a new computer and encountered an issue with Daz Studio. I did a full data migration, and all file paths remain the same. My Daz content has been stored on an external hard drive for over 10+ years. Initially, it was on a drive called "iMac Storage," but about five years ago, I moved it to its current external drive, "Daz3D Library", without any problems.

However, after the migration, Daz Studio is now looking for files in "iMac Storage" instead of "Daz3D Library", where the content is located.

What I've Tried So Far:

• Checked and updated the file paths in the Content Management System (CMS).
• Refreshed all content to ensure it's pointing to the correct external drive.

The Problem:
Daz Studio keeps referencing the old drive name ("iMac Storage") instead of the current one.

Here’s a screen recording of the issue, along with images of the errors and file paths:
https://share.vidyard.com/watch/KmQzfWioJYb9uAvSgy5rh9?

What setting is used to search for the "iMac Storage" file path, and where is it so I can ensure Daz only looks for content on "Daz3D Library"?

Any help would be greatly appreciated!

 

Richard Haseltine

I am not sure why the error gives an absolute path, buit I can see issues with your content directories (you have the data and people subfolders selected under Other Import Formats as well as their parent My Library folder) and in your content itself (I can see a My Library folder in the My Library folder) - nested content directrories are always a bad idea as DS can use the wrong one as a starting point for relative paths (which may be the issue with the paths starting with iMac Storage if its parent was set as a content directory on the old system) and opening an item in the inner My library folder will mean DS won't know to look in its data or runtime folders for referenced files - but that would throw a mising file error, which you are not getting in the video. The video looks more like a Connect instal (through Daz Studio) that did not decrypt correcly, so the file is found but cannot be read. Attaching your log file would help.

aglaia0531_b84979d841

After I posted this, I spent a couple of hours digging, and I figured it out. The issue is in the .duf file itself.  The URL telling the file where to look was an absolute rather than a relative file path.  I couldn't figure out why some content was working fine and others were throwing errors.  I probably went through 50 or so items trying to figure out what was going on via logs and such.  I finally decided to look in the .duf files since I couldn't find anything in Daz. 

When you open the .duf file in text editor, it gives the file path for each element.  In the content that wasn't working correctly. The file path forced it to look for that volume that didn't exist.  I'm unsure why...haven't gotten that far in my research.  But here's an example

This is what the .duf shows in files with missing elements: 

"id" : "AdrieTorso_1002.jpg-1",
"name" : "AdrieTorso_1002.jpg",
"map_gamma" : 0,
"map" : [ { "url" : "/Volumes/iMac%20Storage/DAZ%203D/Studio/My%20Library/Runtime/textures/Emrys/Adrie/AdrieTorso_1002.jpg", 

 

When you go in, you do a find and replace of everything bolded above, it turns it into a relative path.  So then it will look like this

"id" : "AdrieTorso_1002.jpg-1",
"name" : "AdrieTorso_1002.jpg",
"map_gamma" : 0,
"map" : [ { "url" : "/Runtime/textures/Emrys/Adrie/AdrieTorso_1002.jpg", 

Once you save it, it will work immediately; no need to restart Daz. 

Now, when searching for the elements during load, the directory assigned in the CMS is used to search and find the proper folder using the relative path outlined in the file. 

Hope this is able to help others running into this issue. 

Richard Haseltine

That could have happened if, when you created the file, the location wasn't set as a content directory - if you had selected the option to browse for the missing file and selected the version not in a content directory then DS would have used the absolute path when saving (because there was nothing for it to be relative to).