1.1.0.2 | Rebuild history

[taner]

Hi Admin-Team,

I have a question of understanding concerning the Rebuild History-Feature.

Transcoding farm is consisting of 9 nodes.
The nodes are assigned in different combinations to the workflows.
Mediacache is set to global.
All nodes have access to the global mediacache path.

Should rebuild history work regardless of on which node it was triggered?
So for example node1 and node2 are assigned to a workflow.
No other nodes.
When I trigger rebuild history of this workflow at node 3: should it perform regardless whether node3 is assigned to the workflow?
Because nothing happens.
I need to trigger it at node1 or node2.
As long as the mediacache was set to local I had to do it in that way.
But thought that switching over to global mediacache would make that obsolet.

Asking out of curiosity.
It does not affect daily work in any negative way.
And I didn‘t switch from local to global mediacache because of expecting this.

Best
Taner

[emcodem]

Aye taner,
this is a somewhat complex topic as it is depending on the credentials that you log on and start ffastrans.exe.
When you run ffastrans as service this gets a little bit more convusing even.

If you log on using the same username as your ffastrans service is set to run as, AND you start the ffastrans application under those credentials, then it should not make a difference on which node of the farm you are doing this (or on what other computer in the network).

In the end, "rebuild history" will not do more than writing some json files into your /db/wfs/%workflowguid%/mons/%guid% directory. The key point here might be to pay attention to which username is logged on and starting ffastrans.exe. If the currently logged on user does not have permissions to either list the files on the source directory or to write to the ffastrans db directory then the whole thing might not work.

[admin]

Hi taner and emcodem

Actually, taners observation is correct and is not intended FFAStrans behavior. I can see no reason why one should not be able to recreate the cache from any host as long as the host is able to access the monitoring location. Of course emcodems point about the user initiating cache recreation must also have access to the same monitoring location is still valid. Anyway, I will fix this host limitation for the next release.

Thanks for reporting

-steinar

[taner]

Thanks both to you!
One more question: if a transcode fails there is the wonderful feature to restart the transcoding.
Is it already possible to restart from any node because of global mediacache?

[admin]

Yes, retrying jobs can be done from any host. The functionality does not check host exclusion/inclusion.

-steinar

[taner]

Great!

[FranceBB]

Yes, retrying jobs can be done from any host. The functionality does not check host exclusion/inclusion.

-steinar

Yep. I have the server farm running on the servers and the status monitor running on my laptop all the time just to check the progress. Of course my laptop is excluded from every workflow, but I can easily right click and pause, resume and retry jobs (and I've been doing it for quite some time).

[Ghtais]

Hi,

I have a huge amount of file that I want to transcode on a NAS. I had setup a workflow with a Watchfolder pointing directly on this storage.
Unfortunately I had a crash during the night and I had to reboot the machine.
Now i would like to continue with files that have not been transcoded without restart from 0 (Keep files that had been already transcoded)
FFAstrans don't start any other transcode even If I clique on rebuilt history.
Bug or I'am missing something ?
thank you for your help guy

[emcodem]

Aye @Ghtais
Note that when you capture another thread, the original author gets an email and we always have to insert the line "@Ghtais" in order to notify you. So in general it is a good idea to open a new topic instead of posting to an exsting.

Sure, when you "rebuild" history, nothing existing will be processed because it means that all existing files will be marked as already processed. Once you hit that button there is no way back to any other memory state.
The only thing i can come up for you is to go to the folder where the "already processed" files are stored

Code: Select all

...\FFAStrans\Processors\db\cache\wfs\%workflow_guid%\mons\%monitor_guid%

and delete the "not yet" processed files manually.

Alternatively, you could move the "not yet processed" files out of your watchfolder, then press "rebuild history" and then move them in again.

One way or the other, as soon as you hit "rebuild history", all history of your watchfolder will be removed and re-registered.

Last: there is not really any good reason to hit "rebuild history" after a machine crash. Normally you would ffastrans just continue the processing of the "not yet" processed files and submit the stuff you want to reprocess manually.

[Ghtais]

HI Emcodem

Sorry for that, I'am not been aware of this rule. Some other forum ask people to group the same kind of information on the same thread to provide more efficient way to find information using the search function. This is ok for me and you can be sure that I will open a new thread next time

Back to rebuild and thank you to show me where I can find the "already processed" files. It can save me a lot of time in case of new crash

bye