Job log errors, questions, and reporting FAQ | Scene7

This error occurs when there is a file of this name in the upload queue. The servers were getting redundant records in the database queue due to race conditions when the same file that another application server was processing. Before queueing a file, Scene7 now checks that another file of the same name is not already in the upload queue.

You can ignore the DailyCatch jobs. They provide a collective job log for all non-job instant publish transactions for accounting purposes.

1. When an image is uploaded, Scene7 uses a mechanism called Early Publishing. To improve publish performance, the Optimized Pyramid TIFF file is sent to the image servers.
2. At publish time, only the manifest files are recompiled, which contains the details of the optimized files.
3. The exception is if an image is changed after upload, then it's resent with the publish. You can assume that anything marked for publish exists on the live servers.

It is expected that the number of files "Published" don't match the number "Uploaded," regardless of when the two jobs are run, except in coincidental circumstances. This outcome is a result of how the Upload and Publish process was designed. All image file transfers take place during the "Upload" portion of the workflow. Files imported into SPS and optimized. But, those optimized versions are also sent to the production Image Servers as part of that same job. This process has allowed us to streamline the file transfer pipeline and greatly improve performance. However, as a result, there is no longer a file transfer event to record during a Publish job, because the file has already been sent. Instead, Publishing now just generates the manifest file and sends that to the servers. Since that is the only event which takes place, typically they are the only entries in the logs for a Publish. There is one for each set of manifest files sent to each server location.