Hi Francesco
What machine is the eGPU connected to? Same iMac Pro?
Yes, same iMac Pro via thunderbolt 3.
And quite frankly, the novelty has worn off.
1 Like
Hi Tim, I’m not really aware of anything that might be causing it, could you elaborate on os / flame version?
v2022.1 on Linux, CentOS 8.2, HP G8
This might have been asked before but will there be a Mac release? 
1 Like
There is.
1 Like
Yes, that’s the current one, there should be a tar.gz file for Mac
1 Like
Hi talosh,
First of all, many thanks for this amazing project. I’ve tried it on a few clips, and the results, even if not flawless, are consistently better than the Flame “motion” timewarp.
However, I often get errors with clips which resolution is over 3.2K.
"Slow Down clip(s) with ML execute callback [<bound method flameTimewarpML.slowmo of <flameTimewarpML.flameTimewarpML object at 0x7f8ce0c63b50>>((<flame.PyClip object at 0x7f8ce0c68c60>,),)] failed because of an error of type "Cannot export clip ‘test’ : Source: rgb: Prefetcher intentionally dropped frame 8 fetch status Dropped request: track 0 socket Result."
It happens during the export of the “source” to the tmp directory, sometimes it drops at frame 8,9 or 10…
And sometimes Flames crashes with an “abnormal termination /segmentation fault”.
I’m on Flame 2022.1, Z840,Quadro M6000, Centos 7.6, Cuda 11.2
Strangely, we have another Flame with the exact same specs, which seems to deal better with the higher resolutions. Any idea of what can cause this unstable behavior?
Anyway, many many thanks for your work, I’m sure it will save us countless hours of grueling paintwork.
Hi David, that looks like your flame machine is struggling to read the source file you’re trying to send to the TimewarpML. Does this comes up in the console when you just try to play it with “Play every frame” on a loop?
Hi talosh, thanks for your quick response.
My Flame can’t play 4K real time for more than a few seconds - old SAN - but yes, I think you got a point:
Nothing special in the console if I play one the problematic clips in loop with “Play all frames” selected, but in the other hand I DO have a lot of “Prefetcher intentionally dropped frame xx” if I leave it in “play real-time”. I’ll talk to my IT guy about it.
1 Like
When changing projects I get this popup. is there a conflict?
[‘Traceback (most recent call last):\n’,
’ File “/opt/Autodesk/shared/python/flameTimewarpML.py”, line 3216, in ’
‘app_initialized\n’
’ app_framework = flameAppFramework()\n’,
’ File “/opt/Autodesk/shared/python/flameTimewarpML.py”, line 156, in ’
‘init\n’
’ self.load_prefs()\n’,
’ File “/opt/Autodesk/shared/python/flameTimewarpML.py”, line 241, in ’
‘load_prefs\n’
" prefs_file_path = prefix + ‘.’ + self.flame_user_name + ‘.’ + "
“self.flame_project_name + ‘.prefs’\n”,
‘TypeError: can only concatenate str (not “NoneType”) to str\n’]
Hi Hengy, it looks like it is unable to get the new project name after change, I have to fix it in the code, thank you for pointing it out!
Happy to help.
This is great! Thanks @talosh for doing this, it’s saved us days of paint!
One question though… the MLTW prompt ‘flameTimewarpML: Python exception [Errno 2] No such file…’ pops up every time i do a foreground flame export. Is there a way of stopping this? i assume it’s triggered by the export hook? it doesnt happen on bg/wiretap exports.
Hi Tim, haven’t seen this before, is there any more info on that exception, like the line number it happens at?
i get this in the popup console…
[‘Traceback (most recent call last):\n’,
- ’ File “/opt/Autodesk/flame_2021.1/python/export_hook.py”, line 493, in postExportAsset\n moveMoov(exported_file)\n’,*
- ’ File “/opt/Autodesk/flame_2021.1/python/export_hook.py”, line 563, in moveMoov\n process_qtfaststart_command = subprocess.Popen(qtfaststart_command)\n’,*
- ’ File “/opt/Autodesk/python/2021.1/lib/python2.7/subprocess.py”, line 390, in init\n errread, errwrite)\n’,*
- ’ File “/opt/Autodesk/python/2021.1/lib/python2.7/subprocess.py”, line 1025, in _execute_child\n raise child_exception\n’,*
- ‘OSError: [Errno 2] No such file or directory\n’]*
Hey @talosh!
I’ve seen similar behaviour on our machines. I think the “problem” is this:
The exception handler seems to catch any exception from all scripts and is not limited to those from MLTW. I had artists complaining about problems with MLTW (because that’s what they read in the window title) while the problem was some other script in the pipeline.
I guess you could check if the file path in the exception contains something that you expect and don’t show the window in all other cases. What do you think?
1 Like