How can I automate the proxies building??

[Bryson Jones]

Automation of any job generally requires CatDV Server and a Worker Node. From there, there are several ways to manage this:

1 – Have the Worker create proxy based on a server query or watch folder. (Server Queries are far better for this for many reasons.)

2 – Have the Worker Node send the job to an outside application. (Compressor, Episode or other command line script-able trans-coding app.)

Barring that, you could, in theory, automate proxy creation with some shell scripting but it would likely be more trouble (and money) than it’s worth unless you are really handy with shell scripts.

bryson

bryson “at” northshoreautomation.com

northshoreautomation.com

[Matthew Stamos]

Most customers use the Worker node to automate proxy generation but some folks use thrid party transcoders as well. I would explore the Worker Node as there are a few ways to make simpe rules of what you want to make proxies of based on Metadata or watch folders. Also the Worker Node does a whole lot more so it is a highly recommended addition to any catDV deployment. Here is a link to the product page and a couple youtube videos of basic operations.

https://www.squarebox.co.uk/worker.html

https://www.youtube.com/watch?v=n2W68fdAkc4

https://www.youtube.com/watch?v=wSISCZxpr7Q

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Nicholas Wautier]

Im using worker to build proxy today, but why would a query be better than a watched folder?

Nicholas Wautier
Camera Corner / Connecting Point
nicholas.wautier at cccp dot com

[Rolf Howarth]

It all depends on what sort of workflow you’re trying to set up.

Typically you might use a watch folder to import assets into the system and create proxies. You can also implement a publicly writable drop box which moves files to the read only library location to control access to your shared storage (perhaps you want to avoid all your users randomly putting files anywhere they think of on your disk or accidentally moving or deleting files which are still in use).

Server triggered tasks might then be used to process files based on a status change. For example, if a file is marked as To Be Archived, you might copy it to slower long term archive storage and delete it from your SAN, or if an asset is marked as Approved For Publication you might generate an H264 version and ftp it to your web site.

[Bryson Jones]

It’s a bit beyond this forum to write it all, but there are several reasons that I prefer it. (Note that “better” is really up to you, this is my personal preference and others like watch folders.)

Mostly it’s for better control over the process. If I don’t want to make proxy of certain files, I can choose. If I want to do the jobs later or in a certain order (These go first!!) I can do that. I can even set up delayed jobs by choosing a script flag that will only run at night.

If you drop 1000 files into your watch, you’re going for a long ride until you can do another job.

It makes for easier recovery from errors/resubmission. Jobs never fail, ever, right? Why drag and drop again, just seach, reset the trigger flag and move on about your business.

In my opinion, moving files is a bad way to do anything in modern workflows. If you have shared storage, why would you bother moving a file other than to put it in place the first time? (This one is HARD for some folks to grasp but there are many ways to handle it.) Send a job or any process, a path and let it run in place.

Finally and this goes to reliability, If you want to “proxy everything” that’s fine, remember when you ingest you can have server queries run automatically based on rules of what data is missing, not just what data is there. (i.e. if proxy status is blank, send job to proxy.) so even if there’s a watch folder for initial ingest, often there are many actions that should be performed and by breaking them up, you can better troubleshoot and track status. A common first time mistake is to build an action with many many things happening. When that has a problem, or when you want to introduce a small change, you have to change the whole thing.

For example:

I want to make proxy of my files that I ingest from this drop folder.

Ok, so what does that mean really?

I want to ingest files. (1)

I want to find the video files in this batch (2) and make proxy. (3)

Do they stay in place in that drop folder? Hopefully not, let’s move them. (4)

What about stills? Ugh, I forgot, ok, figure out what’s a still and make a .jpg proxy of those. (5 &6)

Audio, dang! Ok, find those and only proxy .wav files. Move .mp3’s to a separate folder structure. (7,8, 9?)

I just wanted to make proxy.

This is just an example and you can totally make a drop folder, for video only, that leaves files in place and makes proxy. That works. But you may find that as you automate you want to do more or different things and so doing things by metadata (check format and if it contains “VIDEO” send to the proxy job etc.) might be better.

Again, I invite you to play and test, that’s the best way to learn but as things get deeper, know that workflows often need more “logic” than a simple watch can provide. But in the early days even the delaying of a job as I mention in the second paragraph, is enough to see the benefit of firing a job from a server query instead of moving a file into a watch folder.

Hope this helps more than it confuses. I see Rolf has replied as well, gotta go read his.

bryson

bryson “at” northshoreautomation.com

northshoreautomation.com