FFastrans 1.0.0 beta is out and I wonder if a new feature could be possible.
Currently, we can see in status monitor which file in which workflow succeed. BUT if I have several monitor folders (called A and B for example) in ONE workflow impossible to know which file succeed (from monitor folder A or from B).
So, I must create 1 workflow with only 1 monitor folder to know what file is ok in status monitor (or from where the error comes).
Maybe it will be a good idea if we can see in the status monitor the workflow AND the name of the monitor folder. With this, we could group all h264 encoders in 1 workflow and know from which encoder a file succeed(or doesn't succeed).
Hey Benjamin!
I guess there will be no more features for the 1.0 release, but it might be interesting to talk about this for the next release or for the 1.0 Webinterface.
So basically you want a new column for Finished Jobs on the Job Monitor Interface where the Watchfolder is displayed.
I think i can add this to the job monitor. Is this an information you always need to see (takes space in the monitor columns) or you only want to get when viewing the job details (job details is a new thing coming with Version 1 of the webinterface)?
Yes it's an important information for me. More, I have to create several very little workflows with only "monitor folder>h264>delivery" just because I must know from where comes the error. With a new column with folder monitor name(which is editable) I could create only 1 workflow with many monitor folders inside.
The only problem that I see is I will not use sleep timer too avoid too much cpu resource but it will be ok anyway.
I know exactly the need to have multiple watchfolders that link to one workflow. That is one reason why the scheduler exists. My plans for this are that in future, you do not modify your workflow to add a new watchfolder but instead you create a new job on the webinterface just like you do create a scheduled job currently.
However, the way is pretty far way until we are there and meanwhile displaying the watched folder as you said might be a useful feature.
Features are not strictly locked for 1.0.0 but there wont be any "dramatic" changes.
I see your point Benjamin and I have sometimes been annoyed by this shortcoming myself. Although it's not complicated code wise, it's not as trivial to implement as it may seem. The source of which a job has come about is not always a monitor. It might be submitted manually through the gui or posted the API, and whatever method is possible in the future. So we need more a "job origin" kind of information which is not tied by one specific method of starting a job.
I will put it in the backlog but it will probably not be ready for 1.0.0.
