In previous articles I’ve shown how to create custom preview generators using Archiware’s scripting engine. In addition to using custom preview and metadata scripts, there is a method of automatically adding these items to any archived asset with P5 Archive by preparing the filesystem appropriately.
Lets say we want to archive the file /Volumes/MySAN/Projects/01-Movie.mov.
We also have some metadata we want associated with that file and a proxy that has already been generated. Lets assume our metadata fields are as follows:
Project: MyProject Producer: Mike Editor: Brian
We also have a proxy we already created that lives at /Volumes/MySAN/Projects/proxies/01-Movie.mp4
Knowing that these elements exist, we can create a folder containing the elements that will automatically get picked up by P5 when the archive of that file runs.
First, we need to create the folder in the relative location. So if our file is at /Volumes/MySAN/Projects/01-Movie.mov, we will want to create a new folder at /Volumes/MySAN/Projects/.com.archiware/presstore/
Inside this folder, we need to create two more directories, previews and metadata, and in each of those folders, a new folder with the name of the file we want to archive. You should now have the following folders created:
These folders would need to be created for each and every file you plan on archiving and associating metadata/previews with.
Associating the Preview
If you’d like to have P5 pick up your proxy at /Volumes/MySAN/Projects/proxies/01-Movie.mp4 when archiving /Volumes/MySAN/Projects/01-Movie.mov, you could either copy or symlink the file:
This would make a copy of the proxy file which would then be moved into the P5 preview index at archive time:
cp /Volumes/MySAN/Projects/proxies/01-Movie.mp4 /Volumes/MySAN/Projects/.com.archiware/presstore/previews/01-Movie.mov/preview.mp4
This would simply link to the proxy and still make a copy into the P5 preview index at archive time:
ln -s /Volumes/MySAN/Projects/proxies/01-Movie.mp4 /Volumes/MySAN/Projects/.com.archiware/presstore/previews/01-Movie.mov/preview.mp4
After running either of these commands, you should now have a valid preview file called preview.mp4 in your .com.archiware/presstore/previews/
Note: this also works with any other format that has a web capable MIME extension, so .jpg,.mp4,.mov, and so on. P5 will pass this proxy through the default MIME handler on the system. It determines MIME type by extension, so make sure your preview has a properly formatted name.
Associating the Metadata
Now that we’ve created our copy/link to our preview, we likely will want to associate metadata as well. First, we will have to determine what fields line up to which elements in P5. For our example above, we will need 3 metadata fields in the P5 archive index to send information into. I’ve set up these elements in P5 as follows:
These line up to my three fields above:
Project: MyProject Producer: Mike Editor: Brian
We will now need to build a standard Apple plist file that contains our metadata map. For more info on Apple’s plist DTD, see here.
<dict> <key>user_project</key><string>MyProject</string> <key>user_producer</key><string>Mike</string> <key>user_editor</key><string>Brian</string> </dict>
This file needs to be saved as metadata.plist in our metadata folder /Volumes/MySAN/Projects/.com.archiware/presstore/metadata/01-Movie.mov/. You should now have a file in the following location:
Clearly this isn’t all that useful for day to day manual archiving, but if triggering an archive of files from a third party system, you could relatively easily loop through all those files being submitted for archive, create symlinks and plist files, and then submit the archive. Upon success, it is safe to simply remove the
directory. This could be done as a post job action in P5 or initiated by your triggering system upon successful job completion. The benefit of using this method over the standard scripting method is that there is no post-processing needed by Archiware to be done on job completion and no further lookup is required for previews/metadata. In situations where it is difficult to determine specific information (paths, metadata) about a file from its full path alone, this method will provide a much easier way of generating this content.
Because of the way this method works, it does require write access to the source filesystem and does require writing custom files/folders into that source. If working with volume level/read-only filesystems, it won’t provide much use. There also is the post-job management aspect if you’d like to keep your source filesystem clean. On *nix filesystems, these directories won’t show up to clients, but within an Windows or cross-platform environment, it can be quite messy.