-
Worker behavior
I’m having a few issues with how Worker handles files in watch folders.
A common tenet of watch folder processes is to wait for the source file size to report the same size after two inspections. Is this what “Wait for directory to settle” does? It sounds like it waits until all files in a folder have “settled”. Regardless, it appears it does not work. The “Settle period” is respected but that will delay small files from being processed promptly. We send 16K ref movies all the way to 60GB self contained.
Another tenet is to not to process files present in a watch folder when the watcher is launched. Without this a batch of files could be processed twice if the watcher is quit and launched without first removing all files from all watch folders.
Lastly how can I kill a single job in progress without quitting worker and potentially killing other in progress jobs?
Thanks
John -
3 Replies
-
John, I tend to move things from a watch after they are processed, just to avoid the “rescan” issue, but I know that doesn’t work for all workflows.
Not sure about the settle thing, but I’ll take your word for it. I don’t have many with such a wide range so I can usually guess my wait time but in a situation like that I’m sure it’s critical.
I’d also like to be able to kill a single process without stopping the whole app.
bryson
bryson “at” hidefcowboy.com
hidefcowboy.com
-
The settle period is based on whether the file has been modified in the last X minutes according to its modification time but I agree checking to see if the size has changed might be a better way to do that so it’s something we’ll consider.
When the worker is launched there is a delay before the various watch and worker threads are started to give you a chance to manually intervene by unchecking the relevant box before they kick off.
The work queue keeps a list of files it has processed for 14 days or more but Bryson is correct and it’s good practice to have your worker job automatically remove the file from the watch folder after it’s been processed. You don’t have to delete it, move it from the drop box to a more permanent library location if appropriate.
Although you can have many jobs queued and there are separate threads to scan for new files and clips on the server, there will only ever be one job actively running at a time. You’re talking about aborting a job that’s in progress and appears to be stuck? Quitting and restarting the worker is the only way to do this I’m afraid. This won’t harm any other jobs however.
-
[Rolf Howarth] “The work queue keeps a list of files it has processed for 14 days or more “
Thanks Rolf,
So does this list prevent files in it from being run again? This might explain some behavior I’m seeing. Just did a few tests… it looks like files make it into the list once Worker first sees them appear in a watch folder. I would prefer they not make the list until they are completed. It’s not uncommon for someone to submit a bunch of files then realize something is wrong with them… delete them before Worker starts… fix the issue… then resubmit with the same names. The 14 day list would prevent them from being done… correct?
I just Noticed the Delete button in that Tasks widow. That does what I need to running and cued tasks.
Thanks
John Heagy
Reply to this Discussion! Login or Sign Up