Skip to main content
May 11, 2025

XML Import Unifies Essential Graphics Clip Markers (Markers Incorrectly Sync)

  • May 11, 2025
  • 2 replies
  • 304 views

Product Version: 25.2.2
OS:Windows10 Pro 22H2

 

Bug Description:

Importing an XML file containing Essential Graphics (EG) clips into Premiere Pro causes their clip markers to become incorrectly unified/synchronized. Adding a marker to one imported EG clip results in the same marker appearing on all other EG clips from that XML. This prevents independent marker usage on EG clips after an XML roundtrip, hindering workflows релиing on clip-specific markers.

Key Behaviors & Observations:

  • Alt-dragging an EG clip to copy it can also cause marker unification, even without XML export/import.

  • Ctrl+C/Cmd+C and Ctrl+V/Cmd+V to copy/paste EG clips initially preserves marker independence.

  • However, after an XML file (containing these initially independent EG clips) is imported, any method of copying these imported EG clips (Alt-drag or Ctrl+C/V) then results in marker unification.

  • This issue seems to stem from the XML import process incorrectly unifying the underlying source graphics (masterclipid and file id become identical for multiple clips, as verified by comparing XMLs before and after import).

Steps to Reproduce (XML Import Issue):

  1. Create two EG clips. Ensure their markers are initially independent (e.g., via Ctrl+C/V copy).

  2. Export the sequence as XML.

  3. Import this XML back into Premiere Pro.

  4. Add a marker to one imported EG clip.

  5. Observed Result: The marker appears on all imported EG clips.

Expected Result:

EG clip marker independence should be maintained after XML import.

Impact:

Severely impacts workflows requiring unique markers on numerous EG clips (e.g., for timing SFX, annotations).

Similar Previous Reports:

Requested Solution:

Fix the XML import process (and potentially Alt-drag copy behavior) to ensure Essential Graphics clip source integrity is maintained, allowing for independent clip markers.

Thank you.

2 replies

May 13, 2025

Hi Ian,

Thank you so much for looking into this and reproducing the issue! I'm very grateful that it will be escalated to the team.

Regarding your question, "Did this work for you before in a previous version of Premiere?":

After further testing with Premiere Pro 24.6.4, I've found some nuanced behavior that's important to share, as it's not as straightforward as I initially recalled, and it sheds more light on the current issue in 25.2.2.

Observations in Premiere Pro 24.6.4:

  1. Immediately after importing an XML containing Essential Graphics (EG) clips and opening the newly created sequence from that XML:

    • If I selected an imported EG clip, targeted the track, and then performed a Copy (Ctrl+C) and Paste (Ctrl+V) operation, the newly pasted clip would indeed become an independent instance with its own unique source graphic. This allowed for independent clip markers.

  2. However, this ability to create independent clips via copy-paste in 24.6.4 was also a temporary state.

    • If I closed and reopened the project (even without quitting Premiere Pro), or possibly after performing other significant operations or switching sequences for a while, then attempting the same Copy and Paste procedure on the XML-imported EG clips (from that same initially imported sequence) would no longer result in independent clips. The markers would then sync, similar to the behavior in 25.2.2.

This suggests:

  • The "special state" immediately after XML import, where copy-pasting could lead to independent EG clips, existed in Premiere Pro 24.6.4 as well.

  • The XML import process itself, in both versions, seems to be the primary trigger for an initial (and often problematic) unification or ambiguous linkage of EG clip sources.

The key difference experienced now in Premiere Pro 25.2.2 might be:

  • While the XML import still causes this source unification, the default behavior of Copy and Paste for EG clips in 25.2.2 might have changed to more strictly preserve the (already unified) source linkage, making it much harder (or only possible under very specific, fleeting conditions right after XML import) to achieve the separation that was more readily (though still temporarily) available via copy-paste in 24.6.4 during that initial post-import state.

  • My earlier, less precise recollection was that copy-paste in 24.x was a general workaround, but it seems it was also tied to that "freshly imported XML sequence" context.

In summary:

  • The root cause appears to be how Premiere Pro's XML importer handles the source/master clip relationships for Essential Graphics, leading to an initial state where clips are not truly independent.

  • Both versions (24.6.4 and 25.2.2) seem to exhibit a very narrow window of opportunity immediately after an XML import, within that newly created sequence, where a Copy & Paste operation might produce an independent EG clip.

  • However, this "window" seems less reliable or a more strictly defined condition in 25.2.2, or the subsequent default copy/paste behavior in 25.2.2 no longer facilitates this separation as readily as it did in 24.6.4, even within that brief window.

My XML analysis (shared previously in my bug report, showing masterclipid and file id becoming shared after import) further points to this XML import/source handling as the core issue.

I hope this clarification on the 24.6.4 behavior is helpful. The critical need is for a reliable way to ensure EG clips maintain or can easily regain their marker independence after any XML workflow.

Thanks again for your help,
rishuu55

IanB_360
Community Manager
Community Manager
May 12, 2025

Hi @edit.terashima 
I can reproduce this on my end and will make sure it is seen. It looks like the XML is taking the very first clip marker applied to any TEXT or GFX clip and applying that same Marker on every TEXT/GFX clip in the new sequence. It does ignore the individual markers that were created in the original sequence. Did this work for you before in a previous version of Premiere? 

We are here to help.

Ian