Ok. Thanks. I took a look at it. It seems like a US feature film (run time of 2:10:56). Can you let me know the title/edition and I'll try to find it in one of my libraries? I detail more below.

Yeah it's National Treasure. I might be able to get it for you from amazon...if I'm lucky enough to find the exact DVD :)

...

"jumping to 1310667" (15s I presume) it then finds itself at 14.8s, Keep in mind that 1310667 is the Presentation Time Stamp number. To convert to milliseconds, just divide by 90. So, 1310667 / 90 = 14.985

Out of curiosity, how much control do you have over the 1310667 number? I'm assuming you're not typing in "1310667" or "14.985". For example, are you using a slider in mplayer's GUI and the slider indicates "15" seconds, but it is changing it to 14.985?

If I'm reading the output correctly, it jumped to either 14.848 (or 14.833) ("14.833333, mpeg at 0.083417 after -> 29.97 14.848166")

So, considering that the time request was 14.985, 14.848 is largely "correct".

It looks like in this (other) case: "EDL rel seek secs 2.962971 12.037029 [12.000000,15.000000] jumping to 1310667" It's jumping "forward 2.962971 secs" Actually now that you mention it, I guess mplayer's code for "relative seek" is currently based off "relative to the most recent NAV packet time" so it might not have been seeking forward with "more than NAV packet precision" I sent mplayer some patches to help them seek better, hopefully that will get committed this eon. After overcoming that, now I get this console output, when attempting to skip from "10 to 15" last NAV packet was 9.600000 ... using mpeg ts appears larger, 10.082091: EDL rel seek secs +4.917909 from pts:10.082091 last NAV packet was 9.600000, mpeg at 10.082091 adding MPEG difference since last nav of 0.258597 # this basically means that, because of my funky math, I'm skipping from "DVD time" 9.858597 4.917909s forward jumping to 1329885 ... A: 11.1 V: 15.16 A-V: -4.098 ct: -0.100 3/ 3 ??% ??% ??,?% 0 0 ... new NAV packet! 14.833333 ... so that's actually really close ( 9.858597 -> 14.833333 for a 4.92s skip) . If I try seeking to "15.2" then it seeks to the same 14.833 mark, as described previous, but at least I've figured out some more mplayer workaround code for that in the meantime :) Thanks for your tips I think it's working now. -roger-