Getting file name without adding asset

Question

Here's the set up-
I use Watch Folders to compress videos for DVD, and I don't want to add the original files as assets. However, I want part of the watcher to be a script response that creates a text file with the same name as the original file. I haven't been able to pass the file name as a parameter- it keeps passing the MetaData field name. I've tried File Name and Title (I used quotes and brackets- can't show that on here, it makes it into links).
I'm guessing I'm either using the wrong metadata field or this is impossible, because there is no metadata.
Message was edited by: jamesnw

Answer 1

I thought I had a solution for you, but upon testing it I discovered an unfortunate reality with the way FCSvr reports job status.
You can subscribe to jobs and have that subscription feed the values of the job's fields to a script. The jobs don't track elapsed time, but they do stamp time for \[Updated] at the creation of the job, during the job, and at the close of the job.
I tested this by creating one email response that will send me an email with the timestamp value of \[Updated] and a subject line of \[Job ID] \[Status] to tell them apart. I made two subscriptions, one that would fire upon the creation of a job that executes the response, and one that would fire on the modification of a job filtered for a status of "DONE".
The problem is, the \[Updated] timestamp does not ever change in the metadata, it just gets updated in the GUI separately. More digging found the same is true for the \[Progress] field.
You could have had two scripts, one that writes a timestamp to a file at the creation of a job with the first subscription that is filtered for the kind of thing you bill for based on whatever job field values, and another that finds the difference with the end timestamp at the close with the second subscription that is filtered for the kind of thing you bill for based on whatever job field values plus a \[Status] that equals "DONE". There would be a margin of error of a few seconds, but that just means you could round your billing up to the next minute.
But alas, the job metadata never updates beyond the first values. In fact, if you open a job from the queue after it completes, the timestamp reverts to the initial value.
Maybe you could have the script write a timestamp itself when it runs rather than trying to pull one from the job's metadata...