UXP getPlayerPosition() returns wrong/stale timecode until sequence is switched

Premiere Pro
, , ,
1

Hi,

I have a UXP panel that reads the playhead position with sequence.getPlayerPosition() and displays it as timecode. The panel timecode often doesn’t match the timeline or source monitor until I switch sequences and back.

First attempt: I pressed Get Position. The timecode on the panel does not match the timecode on the timeline playhead or the source monitor.

1
1675×990 83.9 KB

Second attempt: I clicked on another sequence, then clicked back to my original sequence, and pressed Get Position again. Now the timecode on the panel is correct and matches the timeline/source monitor.

2
2720×995 102 KB

Debug console (UXP Dev Tools): Two `TickTime` outputs. The first is from the first button press (wrong). The second is from after switching sequences and pressing the button again (correct).

First press (wrong):

TickTime { seconds: 4015.978633333333, ticks: "1020122828524800", ticksNumber: 1020122828524800 }

Panel showed: 01;06;55;28 (timeline/source monitor were at 01;07;09;19)

Second press, after switching away and back to Test (correct):

TickTime { seconds: 4029.5922333333333, ticks: "1023580900742400", ticksNumber: 1023580900742400 }

- Panel showed: 01;07;09;18 (matches; timeline/source monitor were at 01;07;09;19, one frame is normal rounding)


Code that produces the console output above:


const app = require("premierepro");

const project = await app.Project.getActiveProject();

const sequence = await project.getActiveSequence();

if (!sequence) return;



const time = await sequence.getPlayerPosition();

console.log(time);

I don’t think the bug is in my conversion code—the same conversion gives the right timecode when getPlayerPosition() returns the right numbers. It looks like getPlayerPosition() is returning incorrect or stale data until the sequence is “refreshed” by switching away and back.


Has anyone else run into this?


Edit: I am seeing these issues on Premiere Pro 2025 & 2026 but it seems to work on Beta 26.2.0.


Thanks.

2

Nice details, thanks!

We’re tracking this behavior as DVATA-1118.