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

[Chris Crochet]

I have a frontend using MPlayer in slave mode.  It has a slider control
that displays the current position.  This control can also be clicked to
perform a single seek, or dragged to "scrub the timeline".

When dragging, it can send dozens of seek commands to MPlayer in a very
short time.  Depending on which MPlayer version is used, I've seen this
result in at least one of the following issues:

1) MPlayer queues all the commands, then struggles to catch up; seeking
repeatedly for a few seconds after the user stops moving the control.
2) MPlayer drops some of the commands.  Not an issue unless it drops the
final one, which it sometimes does, resulting in an incorrect final
position - and that's the one that counts most.
3) In extreme cases, MPlayer freezes up entirely for a while.

None of which is really MPlayers fault, I shouldn't be spamming it with so
many seeks.  I should be waiting until the previous seek is complete before
sending another.  And there's my problem - I haven't found a reliable way
of doing so:

a) I can't simply wait for the next position update.  I've observed one or
more being produced after a seek command is sent, but before the seek is
executed; so use of this method does not ensure I'm not sending another
seek before MPlayer processes the previous one.
b) I can't compare the position MPlayer reports against my last seek
position, as MPlayer appears to seek to the nearest keyframe.  As keyframes
may be frequent or very sparse, I have no idea where to set the threshold
for a fuzzy comparison.  I'd have to set it high by default, which would
mean I could never perform small seeks on any media file that supports it.
c) I can't wait a predetermined amount of time before the next seek, as
seeking may be a slow operation in some media types.

I did find a very hackish method that worked great in the Windows release
version, but NOT in r37205:

* Send a seek to MPlayer, set a [seeking] flag in my code, and increment a
[seekid] variable.
* When [seeking] is set, each time a position update is received, send
"set_property tv_brightness [seekid]".  This is an invalid command since,
at least on my system, no TV hardware is present.
* When the corresponding error message "Failed to set property
'tv_brightness' to '[seekid]." is received, where [seekid] matches,
consider the seek complete.

Sending the invalid command more than once is necessary, since the first
command following the seek is sometimes dropped (issue #2 above).
 Comparing the [seekid] returned in the error message is necessary since
I'm sending the invalid command multiple times, and receipt of a second
error message may be delayed (issue #1 above) until after I've received the
first error message and already started a new seek; making the new seek
seem completed before it actually is.

r37205 breaks this method, as it returns a different error message - which
doesn't include the arguments for the invalid command.

I'm sure I could make it work again with something even more hackish (and
fragile), but there's got to be a better way to do this!  Is there
something I've overlooked?

If not, adding some official method to determine when a seek is complete
would be very helpful.  If MPlayer sent something like "seek complete" over
the slave interface, that would be most straightforward.  Or a dedicated
command that does nothing at all but echo its parameters back when it is
eventually executed would work too, saving me from abusing other commands
for this functionality as I've been doing.