Webinterface

[artjuice]

Hi emcodem,

But man, really, you got 30 gig ram usage from job json file caching in a few days? How many jobs you run through every day?

It's about 300-500 files per day.

@artjuice regarding "multiple systems in shown in one webint", this is the first version that attempts to do this. In network config, you can supply multiple "API Hosts", each of it must be an installation of webinterface. E.g. if you have multiple ffastrans systems, you install at least one webint per installation and set the list of webint hostnames in API Hosts like: host1,host2,host3...

Wow, such a great news!!!
Thx!

[DCCentR]

@DCCentR thanks again for all the insights you provided on the hanging running job display issue. After reviewing everyghing we were still not certain about the details how it came into this situation. However steinar implemented something that should workaround the problems. After all its just a matter about how ffastrans deals with concurrent file access in the /db folder and there are many solutions for one problem possible Not sure if he will or can deliver a patch for 1.4.0.7 version so you can verify the solution @admin, what you think'?

I'm willing to test the fix if it's done

BTW some more observations on my issue, task hangs also happen on other worflows (also on Custom FFmpeg processors). All hung tasks were executed on the same NAS09 server.
I looked up what might be wrong with this server and remembered that the directory with FFAStrans was originally sharded from it. Then I moved the directory (with same name "FF_Install") to SRV-CINEGY1 without turning off the network share of the original folder (it's empty) on NAS09.
I deleted this folder on NAS09 and turned off network share and the current stuck jsons in the monitor directory disappeared immediately
I don't see how this could be related - but it helped with stuck tasks at this time, maybe some residual information about network folders in Windows

I'll continue my observations.

[emcodem]

I deleted this folder on NAS09 and turned off network share and the current stuck jsons in the monitor directory disappeared immediately
I don't see how this could be related - but it helped with stuck tasks at this time, maybe some residual information about network folders in Windows

Thank you so much for keeping an eye on it!
Very intersting that it was always NAS09 that might have initiated the faulty behaviour. What you describe about disabling the share and the locked files disappearing feels kind of scary but if one day we understand why it will for sure be of great help.
Of course unfortunately from what you describe nobody can currently make any sense of it but maybe we finally have finally found the first breadcrumbs for what's the real cause?
Let's see if now after you disabled the share on nas09 we still see the blocked monitor json files...

[andrezagato]

Hello Emcodem.

I started testing with the webinterface recently, so far I was the only one controlling the transcodes. But a new job will benefit from allowing the users to have some sort of control.
What I would like to know is if there is some kind of option for me that allow for faster uploads through the webinterface ? Comparing with a normal filecopy to the server, I experienced a significant difference.

Thanks for the tool! It is really cool!

[emcodem]

Hi Mister @andrezagato

finally! ...i remember in your live stream you didnt quickly find a way to submit files using the webui and gave up trying it I hope you enjoy exploring the possibilities that webui offers. It's also the perfect time for getting started because webint is in the final phase of testing before we have the next really stable major release, so let me know every shortcoming very quick please.

Regarding file upload, well the current implementation a stinky normal web upload after all so speed, reliability and huge files are out of scope. Even if we have 2024 already, there are no to me known free libraries that target the usecase to aim replacing local file transfer. (e.g. spawn a new receiving thread on the server and upload multiple chunks paralell from the client, retry failed chunks...) Most of the solutions i see at work just bring a local tool along that initiates and handles the transfer (also see signiant, aspera and similar in-house solutions from the broadcasters).

There might however be simple and slick alternative solutions for you, depending on your exact usecase. However, straightforward i would say that you need to take care that huge source files are already located on a share where ffastrans can access them before users start their workflow.
Once this is given, e.g. files are in some folder or on the MAM/PAM systems storage or or or... from there you have an easy time and lots of options how to bring the source file into the webinterface file selection, e.g. by dragging a link into webui job starter or by starting a browser tab with the file as parameter in the url etc...

If you like, you can describe your idea/usecase (probably in an extra topic) so we can wrap our heads around how to integrate that nice and easy.

[andrezagato]

Hello emcodem!
Im honored that you remembered me! hahaha you have helped me a lot in the past! And I'm embarassed, you watched that livestream.. with the little to no knowledge of what is possible to do getting a chance to talk about it. I would like to see you guys livestreaming!

Yeah.. back then I had a hard time with webinterface! I got my butt kicked even trying to install it. Now it is so streamlined! It is amazing to get to use it!

So, about my usecase...
I am a part of the team that is setting up a small tv station, I am in charge of the editing workflow. It is a hard news type of TV. So they feed of a lot of internet videos, whatsapp videos, audios, and so forth.
To keep them from just shoving internet videos to the MAM, the IT created a virtual machine with a share, so they could put the files they download in a more controlled space, instead of letting a bunch of windows machines have write permissions to the MAM server.
The plan is to have FFAstrans looking at that share to convert to a more standard file so the editors can work with them. I have the share mapped on their computers, so now they are already using the file transfer.
I just thought that with webinterface I could replace the whole network shared drive from their computers and keep them only using webinterface. It would be a lot more "clean" on my part.. because windows sometimes loses the drive connection. it is a hassle..

Thanks for the help!

[DCCentR]

I deleted this folder on NAS09 and turned off network share and the current stuck jsons in the monitor directory disappeared immediately
I don't see how this could be related - but it helped with stuck tasks at this time, maybe some residual information about network folders in Windows

Thank you so much for keeping an eye on it!
Very intersting that it was always NAS09 that might have initiated the faulty behaviour. What you describe about disabling the share and the locked files disappearing feels kind of scary but if one day we understand why it will for sure be of great help.
Of course unfortunately from what you describe nobody can currently make any sense of it but maybe we finally have finally found the first breadcrumbs for what's the real cause?
Let's see if now after you disabled the share on nas09 we still see the blocked monitor json files...

Disabling network sharing didn't help in the end, the stuck workflows kept appearing even after that, it seems to be a lucky coincidence
And as it turned out they occur not only when running on NAS09 but also on other servers and with other worflows...

I can definitely see that the cause of the stuck json files in FF_Install\Processors\db\cache\monitor now is server.exe
After stopping or restarting the “FFAStrans Webinterface” service, they disappear immediately.

For example, the only one who accessed one of the stuck json (20241126-1239-5702-6a54-9347371dfcbc~1-0-0-0.json) file was the ff web server:

Снимок экрана 2024-11-26 170908.png (714.39 KiB) Viewed 2850 times

web srv Logfile.7z

(1.16 MiB) Downloaded 123 times

None of the other servers involved in the farm accessed it.

[emcodem]

@andrezagato
thanks for the nice words

Totally understood the usecase but i fear it will not really help to replace an unstable network share with a slow web upload hehe...
I understand your thinking but i don't have any solution for you other than kick your IT-Supporters asses to fix the "drive gets lost" issue

The only thing i can add really is that we do it a little similar at work but the "dirty clients" start a little gui where they choose files and enter metadata for the MAM. Once they hit start btn, the local gui tool takes card about copying the files to central NAS and kicks off the ingest workflow in the central orchestrator.
Such a tool is not really much work to write but it's very specific and the easier way is to copy the files just to the share

[emcodem]

@DCCentR you're a debugging master, thank you so much. I'll check your results. We are not finished with this yet

[emcodem]

https://github.com/emcodem/ffastrans_we ... .0.103.zip

Still in pre-release mode. Please test as much as possible so we get a final stable release with all the juicy new stuff!
New feature: you can create new columns in history job viewer and display user_variables from your jobs, check out webint admin settings.
@DCCentR it does not contain any attempt of solution for the locked files, thats for another day