Page 1 of 2

1.0.0.2 | Delivery to output stucks

Posted: Mon Dec 21, 2020 1:47 pm
by 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

Re: 1.0.0.2 | Delivery to output stucks

Posted: Mon Dec 21, 2020 2:56 pm
by 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.

Re: 1.0.0.2 | Delivery to output stucks

Posted: Mon Dec 21, 2020 3:56 pm
by 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.

Re: 1.0.0.2 | Delivery to output stucks

Posted: Tue Dec 22, 2020 5:07 pm
by 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.

Re: 1.0.0.2 | Delivery to output stucks

Posted: Tue Dec 22, 2020 5:27 pm
by 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

Re: 1.0.0.2 | Delivery to output stucks

Posted: Tue Dec 22, 2020 5:40 pm
by momocampo
Ok Taner, so where do you deliver copared to the FFAStrans cache? on local ? on a nas? on another server?
thanks

Re: 1.0.0.2 | Delivery to output stucks

Posted: Tue Dec 22, 2020 6:13 pm
by 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

Re: 1.0.0.2 | Delivery to output stucks

Posted: Tue Dec 22, 2020 6:43 pm
by 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.

Re: 1.0.0.2 | Delivery to output stucks

Posted: Wed Dec 23, 2020 10:47 am
by 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

Re: 1.0.0.2 | Delivery to output stucks

Posted: Fri Dec 25, 2020 5:23 pm
by taner
Hi Steinar,

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

Happy Xmas!