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.
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().
> 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:
On Mon, Feb 28, 2011 at 10:29 AM, Oliver Seitz <i...@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.
2011/2/28 Phil Rhodes <phil_rho...@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.
On Mon, Feb 28, 2011 at 11:17:56AM +0000, Edd Barrett wrote: > 2011/2/28 Phil Rhodes <phil_rho...@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:
On Mon, Feb 28, 2011 at 01:25:30PM +0000, Edd Barrett wrote: > On Mon, Feb 28, 2011 at 11:17:56AM +0000, Edd Barrett wrote: > > 2011/2/28 Phil Rhodes <phil_rho...@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. _______________________________________________ MPlayer-users mailing list MPlayer-us...@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
On Mon, Feb 28, 2011 at 9:28 AM, Edd Barrett <vex...@gmail.com> wrote: > Hi there,
> 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.
> 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().
