FFAStrans forum

Dear steipal,

during the last days we observed an effect with the video delivery...

When we define multiple delivery directories within one workflow, it sometimes happens that the resulting video file is not copied to each of the specified output folders. The rendering completes with status "Success" and the videos are being delivered but we can only find the file result e.g. in the first and in the third folder, but not in the second folder. It does not happen always, only from time to time. Strange.

Maybe you can have a look over it.

Can we somehow create a delivery logfile or something like that to assist you in narrowing the error.

André

This is very strange behaviour. If it fails you should get an error message. Is it always the second delivery that fails or is it random? Are the destinations are local drive or network paths?

-steipal

Hi steipal,

it seems to be directory-specific.
I did not have missing files in other output folders so far.

The folders are all local directories on a separate partition (E:\)

I will try to run some further tests and try to rearrange the delivery folder entries to give you more specific feedback.

André

Yes, I would appreciate if you did some more test. Are you using any variables on delivery that might not be populated correctly?

You could also try to enable logging in the "Special" tab on you workflow configuration. Every new job should have a unique ID text file that contains logging information. Once you come across a failed job please locate the unique file containing the name of the file you're processing and send that log file to post@ffastrans.com.

-steipal

Hi steipal,

I've got further information concerning this issue for you.

The problem does not lie in the final delivery step but in the recognition of new files in watchfolders.

Our processing was designed in such a way that we in fact use two workflows.
The first workflow takes an input file from an input watchfolder, transcodes it and writes it in an output direcotry.
This directory itself is an input watchfolder for a second workflow which also retranscodes this file and produces a final output in another output directory.

It seems that it rarely happens that ffastrans does not spot new files in such an input directory when it's currently busy with transcoding two or more other jobs. It's not necessary that we cascade several workflows as descibed above, it also sometimes happen in a single workflow scenario that a file is not being processed although it wasn't processed before. We then have to stop and restart this specific workflow and then ffastrans suddenly notices that there is a lonsesome file that also wants to be processed.

However we cannot tell, if the Windows Filesystem Watcher API does not fire correctly or if it is an applicatio-specific issue. Currently I've got the sense that it only happens in situation when ffastrans is currently busy with several other jobs to process and a new file is being copied in an input watchfolder in exactly this period of time.

Greetz, André

Thank you for your feeback concerning this problem. It's very important for the reliability of FFAStrans to nail this issue. At the same time it's very difficult to create a monitoring feature with maximum reliabilty and a minimum system impact AND one that work equally good on both local and UNC paths. If you can help me out; Next time this happen, can you please try and modify the monitored folder? F.ex. manually copy some new files into the folder, rename, delete etc. and see if FFAStrans then picks up the change? I need to know it the monitoring has stopped working or not.

-steipal

I just had this scenario, again.

We were transcoding a file with ffastrans and in the meantime another file was copied in a watchfolder by a user.
This file was not picked up by ffastrans automatically.

When we moved the file outside this directory and recopied it in this watchfolder, ffastrans got the FileSystemWatcher event correctly and started to transcode the second file.

So I would confirm that the ffastrans watchfolder process was still alive, it only did not receive every event in the file system.

André

Thank you André This is very helpful! I will investigate further.

-steipal