[MPlayer-users] MPlayer Graphics FrontEnd & Idle Mode

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Thu Mar 27 19:38:11 CET 2008


On Thu, Mar 27, 2008 at 09:55:30AM -0600, Kevin DeKorte wrote:
> Sure something like that work, but is obviously not a nice clean method
> of doing that since you would end up with a playlist that looks
> something like this..
> 
> realfile1.media
> done://done
> realfile2.media
> done://done
> realfile3.media
> done://done
> 
> And you would have to manage a playlist like that by knowing the "magic"
> you put in it. While it may work, I don't consider that an acceptable
> solution.

Well, it depends on what exactly you want to do, but obviously you would
not manage that playlist with the extra files in it, you would manage
the normal one and extend it before passing it to MPlayer.

> Monitoring the status line isn't any good either since when the file is
> complete the status line is just no longer outputted, a timeout would
> have to be implemented to look for the last status line and then
> magically "guess" that file was complete when the timeout expired
> because no more status lines were being issued.

Yes, but you might want to know and do something when mplayer hangs, too
so that timeout is not exactly such a bad idea anyway...

> There was a patch that printed "media done" or something like that,that
> was posted to the list, and it never got merged.

Find it, send a ping or whatever. Patches that are not actively pushed
have a very hard time, and there is no room in my brain to remember
these kind of patches.

> | I'm sure you can find a whole load of other ways (e.g. get_property
> filename is probably
> | useful for this as well), besides sending a patch that adds whatever
> you need to MPlayer.
> 
> get_property filename is useless since if there is no file being played
> since it doesn't do anything. The slave interface works best when there
> is one  request and one response. So anytime a request doesn't give a
> response the interface is basically broken. What would a developer have
> to do? Implement a timeout for the property request to fail? That is
> unacceptable. Responding with "ANS_PROPERTY_FILENAME=no file" or even
> 'ANS_PROPERTY_FILENAME=NULL' would much much better.

Well, it does not work well for filename yet (no easy to parse answer
for failed property requests), but see if attached patch works out for
you.

Greetings,
Reimar Döffinger
-------------- next part --------------
Index: mplayer.c
===================================================================
--- mplayer.c	(revision 26272)
+++ mplayer.c	(working copy)
@@ -3011,6 +3019,11 @@
         case MP_CMD_QUIT:
             exit_player_with_rc(MSGTR_Exit_quit, (cmd->nargs > 0)? cmd->args[0].v.i : 0);
             break;
+        case MP_CMD_GET_PROPERTY:
+        case MP_CMD_SET_PROPERTY:
+        case MP_CMD_STEP_PROPERTY:
+            run_command(mpctx, cmd);
+            break;
     }
 
     mp_cmd_free(cmd);


More information about the MPlayer-users mailing list