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

[Reimar Döffinger]

On Mon, May 19, 2014 at 11:46:00PM -0500, Chris Crochet wrote:
> 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.

This should never happen.
Since there aren't proper FIFOs on Windows, how do you control MPlayer?
Are you making sure there is sufficient space in the buffers before
writing?
Are you checking the return values of any writes you do?

> 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.
> 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.

The seek should have happened before the first position updated after
MPlayer received the command. You should be able to use c) to make
sure it received the command and then use a).
It's still going to be brittle.

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

Which message does it print now? I am not aware of any changes.

> 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.

If you do not need the OSD, there is the osd_show_text function that
should also be printed onto the terminal.
Adding a print after a done seek shouldn't be a problem, though it might
still cause issues if users can trigger a seek as well.
There might also be a good argument for a "user data" property, that
just allows a slave client to store and retrieve arbitrary data in the
MPlayer process. Which should be possible to use for this purpose
as well as other things, and is more generic than a ping/echo command...