1.0.0.2 | Delivery to output stucks

[taner]

Hi Admin-Team,

Sometimes after encoding a video a file stucks with delivering to output folder.
So far this happens in workflows were a files is processed through multiple branches to different output folders as well as in workflows with multiple inputs to a single output for all branches.
The corresponding host starts with another file in his queue and does not finish the previous file.
In the end all files were finished but with delay.
Media cache is set to local.

Best
taner

[FranceBB]

What exactly do you mean with "stuck"?
I mean, I get that the task is not completed, but what does it say?
Waiting for processor resources on the delivery?
I'm afraid we're gonna need a bit more info.

[taner]

When the host comes to moving the transcoded file to the output folder it stops but picks up the next file within his queue.
Within the status monitor the file which should moved to the output folder is shown as "waiting for output folder" or something else.
It's pretty the last step within the workflow.
As said: sooner or later the host finishes the task.
The host is limited to 1 job at the same time.

[momocampo]

Hello Taner,
If you set your cache to local then I think job n°1 must be finished to begin the job n°2(that's isn't be the case with shared cache).
If you have a workflow with different output, maybe FFASTrans is delivering files but you think files stuck?
In the case of different inputs, this is really more weird, I must speak about with the team.
Maybe I will come back to ask your workflow or give it to us now and I will try.
Cheers.

B.

[taner]

Hi momocampo,

Thanks for insisting!
Files which are shown within the built-in statusmonitor as "waiting for output" were not always delivered immediately after encoding.
They are not available in the output folder.
That's for sure.
Apart from that i rely on the statusmonitor from emcodem because it is more accurate.
Also the built-in statusmonitor regulary show dead entries.
Which means: tasks were shown in a "frozen" state.
I think there was an other topic within the forum which dealt with it.

But as said: the files were not always immediately delivered to the output after encoding but later.

Best
Taner

[momocampo]

Ok Taner, so where do you deliver copared to the FFAStrans cache? on local ? on a nas? on another server?
thanks

[taner]

Hi momocampo,

I'm not sure if i understand the question correctly.
FFAStrans-exe is located on NAS.
Media Cache is set to the internal harddrive of each host.

EDIT: the files were delivered to NAS. Each workflow has its own output-folder

Best
Taner

[momocampo]

OK Taner,
So you have exactly the same config as me. Local cache on each host and ffastrans install files on a nas.
Do you have updated your windows recently? I ask because I am having some issues and we are trying to find out why
Anyway, could you give le your workflow please?
B.

[admin]

Hi Taner,

What you're seeing is probably just how FFAStrans works. Basically, FFAStrans has no way of knowing that you want the delivery node start before another. It just follow a logic where the next node is started once the previous is finished. When you split a workflow, you will of course create several next nodes and the first node in line is the one that will start. The order of this is decided on the order on which you created the nodes, not in the order of which they appear on the screen. But FFAStrans also has a logic that make it finish one "split line" before starting the next in the same run. So in the event you have set max jobs to 1, it should finish one split line before starting the next.

Anyway, I think you should share or at least give a screenshot of you workflow and highlight what nodes you would expect to start before another. The problem might be easily solved with a workflow redesign.

-steinar

[taner]

Hi Steinar,

I see, that would explain the behaviour I observe.
Attached you'll find a workflow.

Happy Xmas!