It looks like it's the change to count video frames (rather than relying on FFmpeg's PTS) that break this. With some 29.97fps DVDs the file contains only the actual video frames for a 24fps source so if you count them everything goes completely awry.

Probably the best thing is to revert that change and then go back to the bug it fixed and try to fix it properly.

There are some questions, though:

• if it's a 24fps file which is fiddled to 29.97 by some timestamp manipulation, where is the pull-up frame merging being done? Looking at the output of hacks/examine.py it's just 24fps with some wacky timestamps.
• can we tell that it's a 24fps source and extract it as 24fps to avoid the whole pull-up/29.97 mess? could presumably count the frames.
• don't 30fps DCPs made this way look terrible? presumably in the working case DoM is just adding some duplicate frames every so often?
• how could this have been spotted with a test?

Believed fixed by b58ea0495d72d654161958e515dc6c5ba9992b80 and surrounding commits (master) and af680761cf7c3e97660e8e55c68f42e90b026bf9 and surrounding commits (v2.15.x).

Have sent links to the people who were desperate for a fix but heard nothing back, so I'll assume it's OK.