I’m a fan of keeping as much as I can from the xml. Between the Fix XML’s script and the one I’m working on now (Auto Scale XML’s), I can get most of the data to work for me. The bug is still a giant pain, but in my testing, this fixes a lot of them.
Here’s what the script does and how to use it:
I don’t think it’s ready for the Logik Portal just yet, but here’s where I’m at with this script if anyone wants to test it:
auto_scale_xmls.zip (64.5 KB)
super cool.
However we have found somethinbg extra broken with these tlactions that no matter what we do cant be fixed :
If you open the project on another flame corruption is suddenly back, there is something inherently broken that does not get fixed until you get rif of the tlaction completely.
@john-geehreng is there any way you can access the axis values of the tlaction with python? my dream is to just b able to replace tlactions with resizes.
But all things considered this should be like the main bug ADSK should look into right now, its crazy that we have to deal with this in the first place
I could be wrong, but I don’t think so. Trying to modify a .action file via python looks like torture, so I’m not going to attempt that.
so there is a .action file somewhere i can investigate? i like danger.
ZOMG Turning off “Use Back” and dragging the Action from the TLFX stack back onto the same clip in the timeline is a new way of fixing the bug I’ve never seen before!
-Ted
@finn - you may need to load an action setup rather than try to directly modify the tlfx action
even dangerously…
@KuleshovEffect - Remember that ‘Use Back’ option usually changes the resolution, bit depth, color management, etc.
a tlfx action should always be timeline resolution.
The bug here is that it sets itself to the resolution of the media instead, which is wrong.
i dont see a way to access that info using python or a file on disk. at all. its all in this non human readable workspace .clip nonsense
but yea again, its not completely fixed if we mess with it in many ways its just temporary , its some deeper issue.
@finnjaeger - Actually, @mybikeislost may have something to show as soon as he is ready.
I take what I can get.
Have spent the last 2 years fighting for source res proxys so that i get xmls with 100% correct scling attributes from premiere for flame .
I cant use any of this as its broken.
Also action itself is the worst choice for timeline repo as a repo should always be relative and never absolute!! If you change your timeline res to UHD from HD the repos should come across / they wont with actions.
This is in the end yet again one of those things that we cant fix, only autodesk can.
what I need is
A) resizes instead of actions
B) a way to conform premiere XMLs into Avid MC to export AAFs from there (lol)
also anyone noticed that this bug in all the years of its existence has not made it on the officially “known defects” release notes?
How ? why ? what?
for reference this has been logged as
FLME-64284 : Corrupt Actions when conforming XMLs from PremierePro
it’s not a bug because there is no standard, and since one party intermittently and randomly changes their definitions, the goalposts are constantly changing.
if it were just automatic, open ai would have written a prompt interpreter by now.
consider your frustration to be job creation and economy balancing.
well ill replicate this bug with a xml from fcp7 now, hold my beer.
there is nothing moving, its just broken, its a clear bug in flame .
i updated my zip above because i found i have a much better chance of not seeing that bug if I delete the tl-action, create a new one, and then loading it. here too:
auto_scale_xmls.zip (64.5 KB)
this is just a workaround while we wait for someone to address the bug or maybe just wait for OTIO.
Your updated script worked for me. No bugged action in sight. You’re a legend!!!
ooof man, thats a great idea completely removing them and then reloading them froma. setup file is SUPER interesting ill go try that as well …
Right now I am installing macOS sierra on a old macbook so i can run FCP7 , if the OG FCP7 XMLS dont create this issue for whatever reason it would at least give us a hint.
@hildebrandtbernd check dis.
+1 seems to fix it for me too
Even when I open the timeline on a different machine or try anything to break it. legendary stuff, i dont even know what to say.
absolutely legendary, i made a tiny version that only does the Action fixing and nothing else , so its easier/faster use if you dont need all the other functionallity, all credits to @john-geehreng however
Better version here:
fix_corrupt_action_only.py (3.6 KB)
and yes i know how stupid of a hack this is , its not clean code as, but it works 
(fixed the issue where i required a custom named sequence, this is just the fix now). this should also iterate over all the sequences you have selected i hope
@john-geehreng for president.
If you want to keep the original Action from the xml, I’ve had luck ‘correcting the corruption’ by adding then deleting source fx on the segment like this:
def refresh_segment_source(selection):
print("----------------------------------------------------")
print(" Refresh Sources...")
print("----------------------------------------------------")
for item in selection:
if isinstance(item, flame.PySegment):
# Print the names of existing effects
effect_names = [getattr(fx, 'type', 'Unknown Effect') for fx in item.effects]
print(f"Processing segment: {item.name} - Existing effects: {effect_names}...")
# refresh the Source by adding and removing a dummy Source effect....
for effect_type in ['Source Colour Mgmt', 'Source Pybox', 'Source Image', 'Source Look']:
if effect_type in effect_names:
print(f"{effect_type} effect already exists in segment: {item.name}. Skipping...")
continue
try:
effect = item.create_effect(effect_type)
flame.delete(effect)
print(f"Successfully added and removed {effect_type} effect.")
break
except Exception as e:
print(f"Error: Could not add {effect_type} effect to segment: {item.name}. Exception: {e}")