Files are using their localised file names as their output names in the WebInterface

[SheldonABS]

Hi Team,

I've noticed a bug within the latest version of the WebInterface where once a file has finished transcoding, it uses its localised file name as its name in the File column. I have attached screenshots.

We have recently updated the instance of both FFAStrans and the WebInterface on three of our machines and we have noticed this on two of our machines. The weird thing about it is that it seems to be targeting different extension types depending on the machine. Screenshots 1 & 2 are the problematic ones and screenshot 3 is the unaffected one.

Screenshot 1 shows that the majority of files that complete transcode come out with the localised file name in the file column, however we noticed that on this machine it is only for the .mp4 files that are inputted. When we input a .mxf file, this outputs as its original file name without any issues.

Screenshot 2 shows that only few files are affected but it only seemed to affect .mov files that are inputted. Inputting a .mp4 or .mxf files into this machine has a result of its original file name as its output.

Screenshot 3 for reference only has .mxf files as inputs.

It doesn't seem to matter which workflow the files go through but if they are their "targeted" file type it outputs as its localised file name. Currently we have a workaround in place of adding an additional column for its filename which is done using a populate variables node to assign the original file name to "s_filename" and display that on the WebInterface but we'd prefer it to be like the previous versions where this wasn't present if possible?

Please could we have any suggestions on how to resolve?

Do let me know if you need any more details and thanks in advance for the help!

[emcodem]

Hey Sheldon, sorry for the delay.
My guess is that this depends on the branching of the workflow, let me see if i can reproduce it cleanly and come back...

[SheldonABS]

Hi emcodem,

No worries, thanks for looking into this

[emcodem]

Sorry no chance for me to reproduce the issue, i dig through the source code of ffastrans and webint to see how this is possible but yet nothing found.
Could you please share (in PM):
1) a whole job log of one affected job (e.g. open Job Details, hit download and send me the whole zip)
2) which setting you have for "Prefer Job state" in webui-Clog Icon-WebUI Setting (where you also set "FFAStrans Path")

[emcodem]

Hi again!
thanks a lot for the job logs. I was able to confirm the exact reason(s).

Upgraded webint already solves this for your case. You see "dispelled" jobs in your history, this should not be the case and was fixed already. What happens is that webint imports your dispelled branches and marks them as error. In case a branch ends with error, it shows the file name from the internal "current file" variable instead of "original file" - this is something where webint works differently compared to the inbuilt status monitor and i corrected that just now too.

Fixed from Release v1.4.0.308 (note that there was heavy security work going on these days, new release coming soon)

Potential workaround (note this text is partly AI generated):

WebUI version only recognises a dispelled branch if dispel":true sits within the last 1000 bytes of the branch log. The problem is, the term "dispel:true" only sits in the last 1000 bytes of the branch log if you dont have too many conditions in the corresponding conditional node.

When a conditional dispels, FFAStrans logs the array of checks with every condition of that node, including ones never evaluated ("result":null). Then comes the final "node end" entry. Each condition adds roughly 110 bytes, and the closing entry adds about 300

So the 8-condition "House Format" checks are the problem, in both the "MXF" and the "NOT MXF" variants.

Workaround: make each dispelling conditional short

Combine the eight checks into one condition. Add a Populate Variables node before the conditionals that builds a single string, e.g.

s_profile = %i_interlace%|%i_height%|%i_v_bitrate%|%s_format%|%i_a_sample_rate%|%s_v_codec%|%f_frame_rate%|%i_a_bit_depth%

and replace each 8-row conditional with one row:
- "MXF House Format": %s_profile% = 1|1080|50000000|mxf|48000|mpeg2video|25|24
- "NOT MXF House Format": %s_profile% ≠ 1|1080|50000000|mxf|48000|mpeg2video|25|24

The logic stays the same:
- "all equal" (the AND chain) is the same as the whole string being equal
- "any differs" (the OR chain) is the same as the string being different

Their conditions already compare as strings, so the values compare exactly as they do now. Each dispel then logs one condition, about 530 bytes from the end, like "Correct Loudness", which the old check catches.

Rule of thumb if they'd rather keep separate rows: at most about 4–5 conditions per conditional node, because FFAStrans logs all rows on dispel, not just the evaluated ones.

Caveats

- Existing rows won't change. Jobs already imported keep the wrong name, because the WebUI never refetches them.
- The string must match exactly what the variables expand to on their system. They should check one job's log for the actual values, e.g. %f_frame_rate% showing 25 and not 25.000.
- Test before rolling out. I haven't run this in FFAStrans. It's based on the log format in their job and on the old detection code.

[SheldonABS]

HI!

Thank you for the in-depth explanation. That all makes sense and its quite interesting how the old detection code all works - This is something we'll keep this in mind for any future workflows that we create.

We do want to avoid changing our current workflow with the workaround of reducing the number of conditions in the conditional nodes as that would mean changing a number of our current workflows which isn't really something that's feasible at the moment for us - You mentioned that this has been fixed from release v1.4.0.308 onwards but as mentioned in their release notes, they're not recommended for production as they're pre-releases. Is there any ETA on when the production ready version will be released?

[emcodem]

Absolutely, there is pressure again from some CVE's against the nodejs we ship embedded. I hope @FranceBB updates their installation soon, his and @momocampo installs are the leading ones, if both of them work in every feature they use, i can release with confidence.
Of course you are very welcome to test an updated version, as you can run as many instances on a single host as you want, it should be pretty straight forward to test.

[SheldonABS]

Noted, I hope they update their installs too haha! I presume there is no current projected release date but if one does come up it would be great if you could let me know if possible? Maybe replying to this thread?

In the meantime, I will go ahead and test an updated version and see how it would react with all our workflows.

Thanks again for the help!

[FranceBB]

I hope @FranceBB updates their installation soon

Yep, I've submitted everything for this to be updated in prod too, but we're a bigger organization now, so the days in which I could simply swap things without change management are gone (and the meetings have quadrupled XD).

In the meantime, I will go ahead and test an updated version and see how it would react with all our workflows.

Yep, give it a spin, the more people test, the easier it is for us all to discover any problems (and you will also benefit from the NodeJS security updates which are always nice).