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

Chris Crochet chris at weldtest.com
Thu May 22 01:41:38 CEST 2014


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


More information about the MPlayer-users mailing list