Bryson Jones
Forum Replies Created
-
Excellent and thanks for sharing that solution here!
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
This can be a sticky one. Thank you for starting this thread.
Can the Squarebox guys pitch in on this?
We generally don’t move files once they are in place, but you should be able to do this.
Using a full path to proxy, which makes managing large proxy sets easy, this is the system path mapping.
/Volumes/drive-name/folder/file.mov
goes to:
/Volumes/proxy/Volumes/drive-name/folder/file.mp4
I’ve heard of making all proxy in a single folder but this doesn’t work as expected. We are normally moving via automation so we can just relocate the proxy to match the new path, but a stand alone user can’t really do this.
Is there a fix for this other than moving the proxy? Great tutorial subject here.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
It’s telling you where it hurts.
There’s an illegal character in the XML config files. As a test, backup your worker.xml and workset etc. (Contact support for the exact files) and then try restarting Worker clean.
https://www.squarebox.com/catdv-backups/ That’s a link to where the files we’re speaking of are.
If that works, you can then check the XML configs for the bad character using a text editor. Or, if it’s a small config, just rebuild it or restore from a backup of your Worker XML files. (You are keeping a backup right?)
That’s all I got, but contact support because this may be a known issue that I’ve just not seen but that Java error is pointing to your config or workset files.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Amazing…
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
This is a common problem in larger deployments and the answer, as in most things DAM-related, is planning.
The short answer is buy another Worker. But that may not be feasible for you.
If you log into a North Shore integrated system you’ll see a set of fields left blank in every server. The first 20 are reserved for common automation related fields so that regardless of the meta schema, the Worker (which can only subscribe to one field set per node) can perform actions based on those fields.
Also, we most commonly simply make one large field set with all fields in one set, if permissions allow, so that instead of re-using USER 25, let’s say, you just add the other field as a higher number. Production 1 uses 20-50 and production 2 is fields 51-75 or whatever.
Documentation and planning is key, from day one. Going back later and patching things like this up is a bummer.
So to summarize, establish a common set of fields that are either assigned or reserved for automation across all fieldsets or standardize your fieldset. There’s no penalty for leaving blank fields in your db.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Sounds like this might be permissions.
Did you do an OS X permissions repair after the upgrade? (might be useless but try it first.) Also, contact support on this.
Once you save the field set you might have to quit and reopen the worker but the fields should update.
Remember, you can always use the USER Field ID to program the worker. The fields are there, just not named.
If you don’t see the user fields even, then you need to raise the “Num. user fields:” setting in the CatDVServer tab of the Worker configuration.
(Note that you must remove your field set info in order to change this.) Just put it up to 100 or something slightly beyond your field needs.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
I tested your action on a Mac worker and it worked as it should.
I put it 2 folders deep in the watch folder.
(watch/grandparent/parent/file)
and the Worker picked it up and moved it into the output folder bringing over the enclosing folder.
(output_folder/parent/file)
I’m wondering if this is a windows issue. As I said, I’d really try to use variables for this as in the long run it’s just a better method.
If you chose “expand variables” as an option, these would be the variables you need to put in the destination after the path to your output folder. (These are OS X paths obviously, but it all works in Windows too.)
/path/to/output_folder/$q/$f
$q = parent folder name
$f = file name with extension i.e file.jpg
Be careful and have fun.
But this behavior is potentially a bug that should be reported as well.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
We have a script called “metadata inject” that writes into the wrapper of an mpv or mp4 file.
We also have a version that does the same for stills. We don’t check to see if the data is there, that’d be custom but could be done for sure.
You can script it yourself, if you’re handy, there are tons of command line image tools. But if you are tired of messing with it, get a hold of your dealer/integrator, they might be able to put something together as well.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
Could you give us some more info on the path? It seems that you are picking up the “enclosing folder” which we don’t do a lot (I’ve never used that myself actually) but it seems like Worker is taking the “enclosing folder” of the ingest/watch folder.
You can test this easily by putting a file directly in the watch and then in a couple of folders deep. If they show the same enclosing folder, you have your answer.
This looks like a good job for some variables. I’d get your integrator to show you how they work. It’s a powerful tool. Hope that helps a little.
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com
-
You are correct, in most cases.
The worker is treating each asset as an import, whereas the client app can import 100 and then save them as one transaction.
The database adds some overhead and so, in our experience, one save is faster than 100.
Also, you may have analysis steps turned on in the Worker that may not be running in the client. (check this and thumbnails and other such ops.)
We don’t usually use a Worker for large imports unless it’s something that a human shouldn’t be waiting on like transfers from outside. If it’s assets off of a drive, etc, we offer the idea that a user putting the data where it goes and then importing it into CatDV Pro is probably far faster and can be better, as you’d often want a person to look over any incoming media anyway, before it was published into the db.
This makes new users mad to hear. (What??? I bought this to automate things!! You guys are idiots!!) You can of course automate all sorts of things but sometimes it’s best to manually publish to start things off and make sure everything is placed and happy.
Exceptions: Very regimented workflows where the media is very consistent and arrives in a very clean and organized fashion. Also, imports where no one is waiting on the media right away. Or shops where a lot of automation horsepower is utilized and the users simply monitor those actions. (One Worker Node is almost never enough to accomplish more than basic automation’s. We average 2-3 on a mid-sized system.
The Worker is amazing, but every automation has some overhead. You might want to save your cycles for more important things that can’t be fixed with a simple “drag and drop.”
Finally, the good news, as you said, you don’t have to watch that run. You can do other good stuff, like rest. 😉
bryson
bryson “at” northshoreautomation.com
northshoreautomation.com