[MPlayer-users] How to determine when a seek is complete?

[Chris Crochet]

I've switched from using .NET's process control wrapper to direct kernel
API calls.  While this didn't directly solve anything, it definitely helped
advance diagnosis.

It appears you're correct in that after a seek command is sent, the next
position update *printed* by MPlayer always reflects the new position.  But
due to the multithreaded nature of my program, I can't rely on the next
position *received* by my control code being the new position, and that's
not something I can realistically fix.  So I still need a reliable method
to determine when a seek is complete and the position is updated.

For testing the updated code, I fell back to a simpler method.  When a seek
is needed it sends the following commands, back-to-back with no delay:

   seek [pos] 2
   get_file_name

Where [pos] is the desired position, and "get_file_name" can be anything
MPlayer will print a recognizable response to.  When the response is
received, the seek is considered complete.

At one point in testing, I had a bug where command line parameters were not
being correctly passed; but "get_file_name" was always generating a
response.  However, after fixing this bug, "get_file_name" was usually
being dropped.  Aha!

It seems the responsible parameter is "-cache 2048", and that after a seek,
commands are dropped until the cache is sufficiently filled.  I don't
detect any error writing to stdin during this time.

My full list of parameters, in case this issue is dependent on something
else as well:

-cache 2048
-nofs
-noquiet
-identify
-slave
-nomouseinput
-sub-fuzziness 1
-osdlevel 0
-vo direct3d
-af scaletempo
-ao dsound
-wid [handle]
-colorkey 0x020202
-font "Tahoma"
-subfont-osd-scale 2
-speed 1.001
-pausing 2