Webinterface

[momocampo]

Well done dear @encodem, another cool feature.
And you know, your Webui is with me each work day.

B.

[taner]

Wow!
Didn't expect that!
Many Thanks!
Made a short test and it works great so far.
And from my point of view it is indeed more valuable to see all inoming files, both them residing within watchfolders and those which are really queued in.

ThANKS !

[taner]

An observation: when submitting files the QUEUED-box shows zero.

[emcodem]

@taner
thanks for notifying about the queued box issue, what happens now is that the incoming count overwrites the queued count hehe...
i'll fix this and probably add a count box for incoming but i want to wait a little and see if steinar decides to do some more changes in this area for the upcoming release.
Please let me know any other observations!

[taner]

Hi emcodem,

No problem at all.
Just wanted to report.
Another observation: there were a couple of files within a watchfolder which were not transcoded.
They were not listed within the built-in statusmonitor but were shown within the webinterface-monitor.
They were shown as "incoming" but transcoding did not start.
Apparently the problem was related to the filenames.
After shortening the filenames transcoding started.
But: within the webinterface-statusmonitor they were still listed als "incoming" with their original filenames.

Best
Taner

Edit: after deleting the workflow within ffastrans the files were not listed anymore within webinterface-statusmonitr

[taner]

Another observation:
All jobs within webinterface-statusmonitor are sorted by status.
All "active" jobs are on top of the list.
When a job is changed to "active" it jumps to the bottom of the list remains there a couple of seconds and jumps back to the top of the list.
When the jobs are sorted that all active jobs are listed in the bottom of the list than everything stays fine.

[emcodem]

@taner
thats really useful, thanks for submitting all the observations and please just keep it coming if you have more

After shortening the filenames transcoding started.
But: within the webinterface-statusmonitor they were still listed als "incoming" with their original filenames.[/code]

This is most interesting, it means that ffastrans left a file in a folder like this

Code: Select all

C:\__PATH_TO__\FFAStrans\FFAStrans\Processors\db\cache\wfs\WORKFLOWGUID\mons\PROC_GUID\i

This is also the folder that i work with when showing the incoming tickets. My/our assumption was that each and every .json file in there would end up in an active job (with the exception of a few cases like file dissapears while it was growing) AND that there will never a ticket just stay in there forever.
But in your case it obviously did not end up in a job, nor was it removed from the \i folder by ffastrans.

This is very interesting (could be a ffastrans bug actually) and i really want to catch this case but yet i cannot reproduce this behaviour. Tested with maximum possible length filenames and folders locally and on UNC.
If you have any more cases of that, please submit more info about the filename and paths.
You can then get rid of the "Incoming" displayed job that hangs forever by navigating to the folder above and just delete the corresponding json file.

All jobs within webinterface-statusmonitor are sorted by status.
All "active" jobs are on top of the list.
When a job is changed to "active" ...
...

This makes sense to me, the "status" field changes all the time between Sentences and numbers. e.g. an starting job might have the status "Waiting for resources" for a few seconds and then change to "134/275...." when it transcodes. It is just natural that it jumps around in the list when you sort by status i guess. Can you confirm this? Sorting by state might make more sense than sorting by status...

[taner]

Concerning the files which stuck within ffastrans/webinterface-statusmonitor: this happened a couple of times with other files too.
When this happens then they continue to briefly appear and disappear within ffastrans - processors - db - cache -tickets - <subfolders>.
As long as I don't delete the approriate content of the wfs-folder or delete the workflow it does not stop by itself.
Unfortunately I haven't had the time to dig deeper into it (looking for similarities between these files) or reporting it to the forum.

[emcodem]

hey @taner

i think we can skip this one. We had an internal discussion and it looks like this is most likely already solved with the next ffastrans release.
(Un)fortunately when showing the incoming files on the user interface, we might reveal one or two bugs that always have been there but you didnt notice and they were not really disturbing until now big sorry to @admin

[taner]

Hi emcodem,

Just a question of understanding: do I need to run ffastrans as service on all transcoding-hosts (running with the appropriate NAS-user) to have the possibility altering tasks?
Setup:
ffastrans-exe is located on NAS.
ffastrans and webinterface-statusmonitor on NAS are running as service with the local administrator-account.
Transcoding-hosts are not running as service.
At the moment the transcoding-hosts are running as local users, no domain-controller (coming soon).

When a ffastrans-task is performed by any transcoding-host rather than NAS I'm not able to stop restart etc. a task.
The transcoding-hosts does have access to the ffastrans-folder on the NAS.

Best
Taner