[MPlayer-users] Slave mode - detecting end of file.
Edd Barrett
I have been googling around for a while trying to figure out how I can
detect when a song has finished playing on an instance of mplayer in
(idle) slave mode. My application is unable to queue multiple songs in
an mplayer slave because the playlist ordering is subject to change,
so it is vital I find a way to know when a song has ended.
I found an almost identical question here:
http://lists.mplayerhq.hu/pipermail/mplayer-users/2005-December/057060.html
If you follow up the thread you eventually find reference to a patch
which did more or less this, but was abandoned.
So my question is, has anything changed since then? If not, can i
suggest that an idle mplayer slave should still repond to commands
even if nothing is playing?
So perhaps "get_file_name" might respond "FILE_NAME: <null>", which
can then be picked up by the master application. As it stands, mplayer
says nothing if nothing is playing, so read()s on a named pipe will
just block; this encourages people to write time sensitive code, which
I am dismissing on the grounds that it is too difficult to avoid race
conditions.
Another idea: Perhaps, you can pass a PID to an mplayer slave so that
mplayer can send a SIGUSR1 to the master, indicating the end of a
track?
For now my application will just fork a new mplayer for each track, as
i can easily detect the end of a track using a wait() or waitpid().
Any thoughts?
Cheers.
--
Best Regards
Edd Barrett
http://www.theunixzoo.co.uk
_______________________________________________
MPlayer-users mailing list
MPlaye...@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
Oliver Seitz
> I have been googling around for a while trying to figure out how I can
> detect when a song has finished playing on an instance of mplayer in
> (idle) slave mode.
How about checking stdout? While playing, you'll get an output every 0.1
seconds or so, if there is no data for more than 0.2 seconds, the file
has ended.
Or, in the output is both the position and the duration:
A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
If both is the same, the file should be over.
Greets,
Kiste
Edd Barrett
On Mon, Feb 28, 2011 at 10:29 AM, Oliver Seitz <in...@vtnd.de> wrote:
>
>> I have been googling around for a while trying to figure out how I can
>> detect when a song has finished playing on an instance of mplayer in
>> (idle) slave mode.
>
> How about checking stdout? While playing, you'll get an output every 0.1
> seconds or so, if there is no data for more than 0.2 seconds, the file has
> ended.
>
> Or, in the output is both the position and the duration:
>
> A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
We thought of solutions like this, however I think we could sill
exploir race conditions if we put the system under substantial load.
A more robust solution is needed.
Thanks
--
Best Regards
Edd Barrett
Phil Rhodes
>> A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
There are certainly situations where this never actually appears.
P
Edd Barrett
>
>>> A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
>
> There are certainly situations where this never actually appears.
Yup.
If you look at mplayer.c (trunk) line 3082, we see that when nothing
is playing, mplayer will only respond to:
MP_CMD_LOADFILE, MP_CMD_LOADLIST, MP_CMD_QUIT, MP_CMD_VO_FULLSCREEN,
MP_CMD_GET_PROPERTY, MP_CMD_SET_PROPERTY, MP_CMD_STEP_PROPERTY.
I am going to reccommend it responds to MP_CMD_GET_FILENAME too.
Will have a diff soon (if it works), but I am snowed under with real
work, so bear with me.
--
Best Regards
Edd Barrett
Oliver Seitz
>
>>> A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
>
> There are certainly situations where this never actually appears.
Or far before the end is reached. It was at most the second best approach...
Greets,
Kiste
Edd Barrett
> 2011/2/28 Phil Rhodes <phil_...@rocketmail.com>:
> >
> >>> A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
> >
> > There are certainly situations where this never actually appears.
>
> Yup.
>
> If you look at mplayer.c (trunk) line 3082, we see that when nothing
> is playing, mplayer will only respond to:
> MP_CMD_LOADFILE, MP_CMD_LOADLIST, MP_CMD_QUIT, MP_CMD_VO_FULLSCREEN,
> MP_CMD_GET_PROPERTY, MP_CMD_SET_PROPERTY, MP_CMD_STEP_PROPERTY.
>
> I am going to reccommend it responds to MP_CMD_GET_FILENAME too.
>
> Will have a diff soon (if it works), but I am snowed under with real
> work, so bear with me.
Something like this. Note the lack of single quotes indicating that this is not
a literal filename.
Index: mplayer.c
===================================================================
--- mplayer.c (revision 32981)
+++ mplayer.c (working copy)
@@ -3101,6 +3101,9 @@
case MP_CMD_QUIT:
exit_player_with_rc(EXIT_QUIT, (cmd->nargs > 0)? cmd->args[0].v.i : 0);
break;
+ case MP_CMD_GET_FILENAME:
+ mp_msg(MSGT_GLOBAL, MSGL_INFO, "ANS_FILENAME=(none)\n");
+ break;
case MP_CMD_VO_FULLSCREEN:
case MP_CMD_GET_PROPERTY:
case MP_CMD_SET_PROPERTY:
Reimar Döffinger
> On Mon, Feb 28, 2011 at 11:17:56AM +0000, Edd Barrett wrote:
> > 2011/2/28 Phil Rhodes <phil_...@rocketmail.com>:
> > >
> > >>> A: 299.2 (04:59.2) of 299.0 (04:59.0) 1.5%
> > >
> > > There are certainly situations where this never actually appears.
> >
> > Yup.
> >
> > If you look at mplayer.c (trunk) line 3082, we see that when nothing
> > is playing, mplayer will only respond to:
> > MP_CMD_LOADFILE, MP_CMD_LOADLIST, MP_CMD_QUIT, MP_CMD_VO_FULLSCREEN,
> > MP_CMD_GET_PROPERTY, MP_CMD_SET_PROPERTY, MP_CMD_STEP_PROPERTY.
> >
> > I am going to reccommend it responds to MP_CMD_GET_FILENAME too.
> >
> > Will have a diff soon (if it works), but I am snowed under with real
> > work, so bear with me.
>
> Something like this. Note the lack of single quotes indicating that this is not
> a literal filename.
You should just use get_property filename, the direct cmd stuff really
should be considered deprecated where a coresponding property exists.
Tom Evans
You don't need a patch to do this:
really-quiet=1
msglevel=statusline=6
msglevel=global=6
When mplayer reaches the end of the file, it will emit a message like so:
EOF code: 0
Cheers
Tom