Hello,
I am not sure if this is a bug or if it’s due to some technical aspects of the implementation, but the resubmit/restart from start function is not working correctly for files that were monitored from FTP (Monitors: FTP). In my case, this involves monitoring and copying files from Avid AirSpeed via the FTP protocol, but I also tested it with a regular FTP setup, and the situation is the same. Specifically, the restart option skips re-downloading the file from the FTP server and instead looks for the localized file in the temporary cache folder.
Also from time to time i had a problem with copy files from AirSpeed via the FTP, but it only appears when Monitors and Deliveries nodes both FTP i think. With last version of FFAStrans and Deliveries to SMB no any errors at all.
Retry ftp-job from start.
Re: Retry ftp-job from start.
It is by design, to re-trigger ftp download you have however multiple options.
1) delete the cache record. Probably not very helpful in your case
2) rename the file on ftp server. Same, will mostly not help in your case
3) uncheck "localize" in the monitor processor
For 3) this means that you need to "download" the file in some other way, or, depending on your workflow you don't even need do download the file but you can instead construct a valid ftp url, populate s_source with the ftp url and hand it to the encoder directly.
E.g. it is possible to submit a source like ftp://username:password@hostname/file.mxf directly to an encoder.
Regarding problems with ftp mon/deliver, this must be debugged on a per-case basis, problems can often be caused by the ftp server itself, too many open connections etc... If you have high latency/WAN connections of course the network is a different beast.
1) delete the cache record. Probably not very helpful in your case
2) rename the file on ftp server. Same, will mostly not help in your case
3) uncheck "localize" in the monitor processor
For 3) this means that you need to "download" the file in some other way, or, depending on your workflow you don't even need do download the file but you can instead construct a valid ftp url, populate s_source with the ftp url and hand it to the encoder directly.
E.g. it is possible to submit a source like ftp://username:password@hostname/file.mxf directly to an encoder.
Regarding problems with ftp mon/deliver, this must be debugged on a per-case basis, problems can often be caused by the ftp server itself, too many open connections etc... If you have high latency/WAN connections of course the network is a different beast.
emcodem, wrapping since 2009 you got the rhyme?
Re: Retry ftp-job from start.
Hi arjuice,
The FTP implementation in FFAStans is not as good as I want it to be. We use the in built Windows API for this and it's not optimal. I'm expecting one day to rewrite this stuff to use a more modern external library.
Retrying is a slightly different problem. We're aware of the situation and it's something we should be able to address.
Thanks for notifying!
-steinar
The FTP implementation in FFAStans is not as good as I want it to be. We use the in built Windows API for this and it's not optimal. I'm expecting one day to rewrite this stuff to use a more modern external library.
Retrying is a slightly different problem. We're aware of the situation and it's something we should be able to address.
Thanks for notifying!
-steinar
Re: Retry ftp-job from start.
I’ve learned the following trick – I create an additional “Monitors: FTP” where I specify the names or masks of the required files. However, it’s not always convenient or quick to do so.
Thx!
Thx!