Dear Steinar,
now I have to excuse myself for the long delay. I was on vacation until now.
Anyway, I have replaced the def_runner.a3x for about 3 hours ago. In the meantime FFAStrans had processed some files (with the mentioned delay) but the def_log folder remains empty. So there is nothing I can send to you
Rest-API update failed
Re: Rest-API update failed
Dear Steinar,
it took a while but now I have the log files from the def_log folder. For your explanation: The Clients FFAStrans1 and 2 are my new servers which has the problem of finding files in folders delayed. The AUDIOCONVERT Client is the last one of my old FFAStrans farm which runs previuosly with Version 1.2.0 of FFAStrans. On this Client everything works normal. Files were detected after a sleep cycle when this client is the only one allowed for farming.
In the meantime I had start to rebuild my workflows from the scratch. In one of my workflows I monitor a folder with a large ammount of clips (4000+). After rebuilding this workflow I had recognized that the clips were arcodingly processed (detected) after a sleep cycle. After using the "rebuild history" function in the monitor node, the clips were detected delayed.
I hope this helps to find a solution. I'm getting out of ideas.
Best regards
Michael
it took a while but now I have the log files from the def_log folder. For your explanation: The Clients FFAStrans1 and 2 are my new servers which has the problem of finding files in folders delayed. The AUDIOCONVERT Client is the last one of my old FFAStrans farm which runs previuosly with Version 1.2.0 of FFAStrans. On this Client everything works normal. Files were detected after a sleep cycle when this client is the only one allowed for farming.
In the meantime I had start to rebuild my workflows from the scratch. In one of my workflows I monitor a folder with a large ammount of clips (4000+). After rebuilding this workflow I had recognized that the clips were arcodingly processed (detected) after a sleep cycle. After using the "rebuild history" function in the monitor node, the clips were detected delayed.
I hope this helps to find a solution. I'm getting out of ideas.
Best regards
Michael
Re: Rest-API update failed
Thanks, I will take a look at the logs and see if I can make some sense out of it.
-steinar
-steinar
Re: Rest-API update failed
Hi Michael,
In any of the workflows no monitored files are being picked up by AUDIOCONVERT. Only FFASTRANS1 and FFASTRANS2 are picking up new files.
The workflows with ID 20210216-1053-1244-52d3-90d1f74896b7 monitoring \\10.197.5.10\mg\clip.dir and ID 20220914-1227-2883-2dcd-a20ebc64b863 monitoring \\10.197.5.8\mg\clip.dir have files being picked up right after workflow start. So this looks like it's working as expected. There is no delay from a monitoring perspective. The 20220914-1227-2883-2dcd-a20ebc64b863 workflow is started and stopped multiple times during the 14. Sept. I guess this is intentional?
The workflow with ID 20210216-1105-2917-240b-c040853018c6 monitoring \\10.197.5.8\mg\convert is seemingly running for four days before picking up one single file. This might be unusual but I don't know if there is actually only one new file in this dir during this period. However, the log files has been truncated for some odd reason. This is NOT expected behavior and can point to anomalies with the storage.
From what it looks like you're running the FFAStrans installation from an Omneon media grid. I would not recommend this as this storage and it's drivers is not tailored for the way ffastrans utilize the storage as database. I would urge you to move the installation to a Windows hosted share. We must at least make sure it's working as expected in a more compatible installation environment, just to rule out the media grid causing the issues. Is it possible for you to test this before proceeding?
-steinar
In any of the workflows no monitored files are being picked up by AUDIOCONVERT. Only FFASTRANS1 and FFASTRANS2 are picking up new files.
The workflows with ID 20210216-1053-1244-52d3-90d1f74896b7 monitoring \\10.197.5.10\mg\clip.dir and ID 20220914-1227-2883-2dcd-a20ebc64b863 monitoring \\10.197.5.8\mg\clip.dir have files being picked up right after workflow start. So this looks like it's working as expected. There is no delay from a monitoring perspective. The 20220914-1227-2883-2dcd-a20ebc64b863 workflow is started and stopped multiple times during the 14. Sept. I guess this is intentional?
The workflow with ID 20210216-1105-2917-240b-c040853018c6 monitoring \\10.197.5.8\mg\convert is seemingly running for four days before picking up one single file. This might be unusual but I don't know if there is actually only one new file in this dir during this period. However, the log files has been truncated for some odd reason. This is NOT expected behavior and can point to anomalies with the storage.
From what it looks like you're running the FFAStrans installation from an Omneon media grid. I would not recommend this as this storage and it's drivers is not tailored for the way ffastrans utilize the storage as database. I would urge you to move the installation to a Windows hosted share. We must at least make sure it's working as expected in a more compatible installation environment, just to rule out the media grid causing the issues. Is it possible for you to test this before proceeding?
-steinar
Re: Rest-API update failed
Hi Steinar,
Sorry again for my late reply.
It is weird that AUDIOCONVERT did not picked up any files becaue there is one workflow which runs all the time and only these client is allowed to farm the input files. Anyway, your suspicions regarding the storage I'm running FFAStrans from seems spot on.
I was wondering all the time why everything was working fine in my old FFAStrans environment and not so well in my new one (with new servers). I began to test my workflows with an FFAStrans installation on a local drive and it worked well. Finally I have found the cause of the delay. It is related to the file system driver from harmonic, which is required to gain access to the Media Grid storage from harmonic. On the new servers, I had installed the latest version of this driver. On my old servers was a much older version installed and there is almost no delay in pickung up files. So I was installing the old driver to the new servers and it worked as before in my old FFAStrans environment.
I understand your point, that the Media Grid is not the best place to run FFAStrans. But in my case it was the best place for it to run it as a farm, because this storage is totaly failsafe constructed and completly mirrored. My colleauge is just setting up a new NAS and I have already reserved a part of the memory. When he is done, I will move the FFAStrans installation to the new NAS.
If you need further informations regarding the version of the harmonic filesystem drivers. Feel free to ask.
Best regards
Michael
Sorry again for my late reply.
It is weird that AUDIOCONVERT did not picked up any files becaue there is one workflow which runs all the time and only these client is allowed to farm the input files. Anyway, your suspicions regarding the storage I'm running FFAStrans from seems spot on.
I was wondering all the time why everything was working fine in my old FFAStrans environment and not so well in my new one (with new servers). I began to test my workflows with an FFAStrans installation on a local drive and it worked well. Finally I have found the cause of the delay. It is related to the file system driver from harmonic, which is required to gain access to the Media Grid storage from harmonic. On the new servers, I had installed the latest version of this driver. On my old servers was a much older version installed and there is almost no delay in pickung up files. So I was installing the old driver to the new servers and it worked as before in my old FFAStrans environment.
I understand your point, that the Media Grid is not the best place to run FFAStrans. But in my case it was the best place for it to run it as a farm, because this storage is totaly failsafe constructed and completly mirrored. My colleauge is just setting up a new NAS and I have already reserved a part of the memory. When he is done, I will move the FFAStrans installation to the new NAS.
If you need further informations regarding the version of the harmonic filesystem drivers. Feel free to ask.
Best regards
Michael
Re: Rest-API update failed
Do the MG windows drivers still cause bluescreens from time to time?
emcodem, wrapping since 2009 you got the rhyme?
Re: Rest-API update failed
Hi emcodem,
I haven't had any problems with blue screens since Windows 7 SP1 in combination with a version 4.x of the harmonic file system driver.
My old servers for transcoding were running version 3.3.0.0.20140616 of the (then) omneon filesystem driver and even there I had no problems with blue screens.
I have installed this driver on at least 20 clients and 5 servers and all working properly.
Actual I use (except of my trnascoding farm servers) the version 4.0.4.0 of the harmonic filesystem driver.
I haven't had any problems with blue screens since Windows 7 SP1 in combination with a version 4.x of the harmonic file system driver.
My old servers for transcoding were running version 3.3.0.0.20140616 of the (then) omneon filesystem driver and even there I had no problems with blue screens.
I have installed this driver on at least 20 clients and 5 servers and all working properly.
Actual I use (except of my trnascoding farm servers) the version 4.0.4.0 of the harmonic filesystem driver.