"Waiting on Resources"

[jwietholter]

I have setup multiple workflows, some single encoders that then export to one directory, others have multiple encoders that all export to the same directory. FFAStrans picks up the files from the monitored folders (or receives them if I manually submit them) without issue. Similarly, it encodes them without issue. However, when it reaches the end of each job's encode (in my case, each one a Custom FFmpeg encoder), IF there are additional files in queue, the encode stays in the monitor, and the monitor reports the status as "Waiting on Resources." Once a job has reached this point, the next job in the queue begins. This process repeats (adding a new line in the Status Monitor for each job and each job has a status of "Waiting for Resources"). When all of the jobs are processed for that queue, then all of the jobs are written to the output directory at that time without issue.

Should FFAStrans be writing each of these jobs to the destination folder after each encode as opposed to waiting for ALL encodes to complete?

As it stands now, waiting for all jobs to complete is not an issue, however, it would be more convenient if each job were to write to the destination folder as it was completed in case I needed to act on those files before the next ones were ultimately processed.

Thanks!

[admin]

What version of FFAStrans are you using?

-steipal

[veks]

Hi all!
I know this is an old post, but I'm having an exact problem in the latest version.
I have 6 workflows with 10 or so watchfolders.
Encoding in 7 profiles (same source) and delivering it to one UNC destination and moving the source to "finished jobs" folder.

This is what's in the FFAStrans monitor, and it's hanging like that:


I've also set this:


Any thoughts about what might be wrong?
CPU is in idle whole the time now. So there are available resources.

Also, any way to re-queue the jobs from the beginning without moving files or manually importing files?

Thanks!

[momocampo]

hi veks,
I had the same issue from one of my workflow but impossible to know why the workflow freezes.
I spoke to Encodem and he says I can try to uncheck "Log to file" in configuration menu/special(if it is check). Since no issue but I know I have already have this issue without check "log to file" so ....Weird.

[veks]

hi veks,
I had the same issue from one of my workflow but impossible to know why the workflow freezes.
I spoke to Encodem and he says I can try to uncheck "Log to file" in configuration menu/special(if it is check). Since no issue but I know I have already have this issue without check "log to file" so ....Weird.

Hm, now I checked workflow IDs.
It might be the problem that I've duplicated all workflows, and removed not needed "processor nodes" and changed watchfolder.
Also, all of the root temp folder for all workflows goes to the same "workflow ID" folder.
Might this be causing the problem?
And if it is causing the problem, any way to change the workflow ID somehow without creating a new workflow?

Thank you!

EDIT 1: Now I see that also in ".ini" file of a workflows the variable "watcher_id" is also the same.
I'd say that this might be the root of causing this problem.

[emcodem]

Hey @veks
very nice findings, thanks a lot for reporting!
I tried to reproduce the issue and for me, when duplicating a workflow with watchfolder nodes, the node GUID of the start_proc in the ini is always the same but the watcher_id changes with each duplication. In fact, the watcher_id always corresponds to the filename of the ini file.

So you say the watcher_id is the same in multiple workflow ini files, correct? How did you duplicate the workflow, using ffastrans gui -> rightclick -> duplicate?
Also one more question, when the processing stops for you, can you have a look if rest_service... and exe_manager... process is running? -The background of this is that this process should always be there when running as a service and exe_manager... process takes care about keeping it alive.

[veks]

Hey @veks
very nice findings, thanks a lot for reporting!
I tried to reproduce the issue and for me, when duplicating a workflow with watchfolder nodes, the node GUID of the start_proc in the ini is always the same but the watcher_id changes with each duplication. In fact, the watcher_id always corresponds to the filename of the ini file.

So you say the watcher_id is the same in multiple workflow ini files, correct? How did you duplicate the workflow, using ffastrans gui -> rightclick -> duplicate?
Also one more question, when the processing stops for you, can you have a look if rest_service... and exe_manager... process is running? -The background of this is that this process should always be there when running as a service and exe_manager... process takes care about keeping it alive.

Hi, thanks for your help
Yes, I've duplicated it via application.
Rest_service and exe_manager were running. Tho, FFMpeg.exe wasn't!
Also, I couldn't delete jobs via FFAStrans gui or web GUI.
It only worked when I've deleted physical .ini files for jobs.

Now, I'm testing again, sending few files to see if I'll reproduce the problem again.

[emcodem]

hey veks,
Good info, thanks!
Maybe if you have the problem again, you can upload and send us the full contents of the .cache folder?

[admin]

Hi guys,

I don't think you should bust your ball to much on this one. The current version of FFAStans has lots of issues which has been addressed in the upcoming 1.0.0 version. Orphaned/stuck jobs are just some of these issues.

-steinar

[veks]

Hi guys,

I don't think you should bust your ball to much on this one. The current version of FFAStans has lots of issues which has been addressed in the upcoming 1.0.0 version. Orphaned/stuck jobs are just some of these issues.

-steinar

That's great to hear

Any ETA when the release should happen?

Ty!