FFAStrans forum

emcodem wrote: ↑Fri Feb 07, 2020 3:28 pm Hi veks, good to see you again!
You point out a valid question but this is not foreseen in ffastrans and it will be a hassle to implement too, not sure if we solve that but we will discuss for sure.

Anyway, that was the reason why i implemented the scheduled jobs in the webinterface. Unfortunately one needs some scripting knowledge. I could easily provide you a script as you need it but for this you would need to describe exactly what your workflow does (it does not only "list" the files in a folder).

1) make sure your webinterface is running with the same credentials as ffastrans does.
2) on the webinterface, add a new scheduled job, hit the edit condition button and insert this script.
3) change the first 2 lines to your watchfolder and the log file where the current contents will be logged to in case there were changes
4) save and close the script and alter the frequency of the scheduled job to e.g. 1 minute

let me know if you can live with such a solution and if you need something different than just log the filenames.

Code: Select all

var watchfolder = "c:\\temp";
var logfile = "c:\\dev\\log.txt";

//do not change this code unless you know what you do
var fs = require("fs");
var oldfiles = [];
var tempfile = process.env["appdata"] + "\\store.json"
try{oldfiles = require(tempfile)}catch(ex){}

var newfiles = [];
fs.readdirSync(watchfolder).forEach(file => {
  newfiles.push(file);
});

//make diff between new and old
let difference = newfiles
                 .filter(x => !oldfiles.includes(x))
                 .concat(oldfiles.filter(x => !newfiles.includes(x)));

//remember new files for next run
fs.writeFile( tempfile, JSON.stringify( newfiles ), "utf8", function(){} );

//write log if directory content changed
if (difference.length != 0){
	fs.appendFile( logfile, "\n" + new Date() + " " + watchfolder + "\n", "utf8", function(){} );
	fs.appendFile( logfile, JSON.stringify( newfiles , null, 4), "utf8", function(){} );
}

emcodem wrote: ↑Mon Feb 10, 2020 9:24 am Hey!
if i was you, i would try to do this without the use of a .txt list.
Automatic retry of only a certain part of a workflow is always a huge hassle as it needs a lot of testing of all possible cases. Typically instead of implementing such workarounds, one concentrates on the actual issue, the cause why sometimes not all bitrates are being transcoded correctly.
The problem is that one can only workaround known errors but for me it looks like you want to workaround unknown errors. As unknown errors cannot be tested, typically the workaround does not work as intended too.

Are you sure this is worth the effort? Are you aware that there are a some problems left that you did not yet think about?

If you really want to continue this path of workarounding unknown errors, i suggest a totally different way then you think about right now. But you will need to use Version 1 for it as your workflow is already pretty big.

1) stay in one workflow, don't split off into another one
2) write a python script that is able to check the existence and validity of the mp4 files and .smil file, execute it after all deliveries were done. There is no need to check if the files are still growing with python as all deliveries were already done, but you will need to check e.g. the duration of all videos.
3) for start, concentrate on retry the whole workflow by moving the source file back to the watchfolder (rename if neccessary). It will be a LOT of work to retry only a part of the workflow.

Can you imagine what i say, does it make sense, would it probably work?

Regarding multiple instances of webinterface on a per-workflow base, you are talking mainly about the job monitor piece, it should only show the files from a certain workflow, correct?

emcodem wrote: ↑Tue Feb 11, 2020 9:29 am Ay, thanks for your PM with the workflow.
I checked and you are correct, the Synchronize option does not work - appearingly it does not work at all in the 9.4 Version that you can currently download from the ffastrans main page. In fact it behaves as if the "Hold node (with synchronize)" was just not there at all.
I also checked with the latest beta, there it works. Are you sure you cannot drive with Beta 7.1? - the 1.0 release should come in the next days.
Currently i am checking back with the others if we have a simple solution for you without upgrading, stay tuned.

Maybe it is best if you just do sequential transcoding and deliver instead of paralell (until you upgraded to 1.0). As you said you have only 8 cores (which means 4 cores without Hyperthreading), it should not take much longer as each and every single transcode will utilize 100% CPU anyways.

admin wrote: ↑Wed Feb 05, 2020 9:50 pm Importing legacy xml workflow packs will be available in the final 1.0.0 version scheduled for release 14. february.

-steinar

veks wrote: ↑Tue Feb 11, 2020 10:10 am Maybe some of the solutions would be to do what I've described before.

veks wrote: ↑Tue Feb 11, 2020 10:10 am But I'd need some explanation and help how to upgrade to it without much hassle.

veks wrote: ↑Tue Feb 11, 2020 10:10 am There should be an option inside the custom FFMpeg node for choosing "use source file" so that next node doesn't take previous file being transcoded which is a problem.

veks wrote: ↑Tue Feb 11, 2020 10:10 am P.S. so, HOLD is fixed in latest beta?
Can I sideload beta while having stable installed too, but without turned on workflows?

veks wrote: ↑Tue Feb 11, 2020 10:10 am EDIT 1: also, I can't switch yet to beta because of this?