[MPlayer-users] Mplayer playlist question
inverseparadox at comcast.net
Wed Oct 10 13:16:10 CEST 2007
P J P wrote:
> Hello all,
Please do not, ever, crosspost a message between the -users and the
-dev-eng mailing lists. The only thing I can think of which might belong
in both places is an announcement from the developers or the server
admins, and those tend not to be made via the mailing lists.
This is a question about using MPlayer, not about developing it, and as
such it belongs on the -users list.
> I use mplayer everyday, non-stop, in quite a peculiar(for some) way.
> $ mplayer -loop 0 -shuffle $HOME/sng/*.mp3 < /tmp/mplayer.in > /dev/null &
That path specification expands to
$HOME/sng/file1.mp3 $HOME/sng/file2.mp3 $HOME/sng/file3.mp3 ...
The expansion is done by the shell before MPlayer is run; MPlayer never
sees the wildcard; it just sees the list of songs. It does not really
know that you are attempting to pass it "all the songs in this
directory"; it only knows that you are passing it "all of the songs I
have explicitly named".
Once the number of files in that directory gets to be too large, you
will start to see "command line too long" errors from your shell. That
doesn't really relate to your current problem, but it is a weakness in
your described approach, which you will eventually have to deal with if
you keep adding files.
> + sng: is the directory where I keep all my music files.
> + mplayer.in: is a pipe I use to send commands to mplayer.
> This way, once started, I safely(and literaly) forget about mplayer,
> and it seems to go on for ever. I rally like mplayer for that. :)
Sounds like a variant on the functionality you can get from moosic. I
don't use it quite that way, but it certainly can be done if I'm not
mistaken. Have you seen that program?
> Now, lately what is happening is, during the course of days browsing
> I download music files to $HOME/sng directory; And then I have to
> restart mplayer to include those new files into it's playlist.
> Question: Is there any way by which mplayer can take care of those
> new files without my restarting it?
Since MPlayer knows only that you passed it a list of specific
filenames, and does not know or care that all of those files are in the
same directory, it naturally cannot rescan the directory.
> My solution(s) go something like this
> 1. I would like myplayer to check - after every song(ie. after every
> 4/5 minutes) - if there were any new addtions to the `$HOME/sng'
> directory, and include those files to its playlist. That sounds quite
> promising, doesn't it?
Not as far as I can tell at first glance, no. What you are essentially
asking for is the ability to pass MPlayer a list of directories and have
it rescan the directories and randomly choose a file from them every
time it finishes playing one. I do not think that the kind of
functionality which would be necessary to support that really belongs in
> 2. Or by using SIGHUP signal. Whenever I want to refresh its
> playlist, I would send SIGHUP signal to mplayer.
Ew. If you want to send a command to MPlayer, you should do it not with
signals but with slave mode.
At the moment there is no slave-mode command for doing this kind of
thing, though one could potentially be added.
> Is this possible in any way?
What I would suggest as a first (untested) possibility:
Build an actual playlist of the files you want - that is, a text file,
with one filename per line.
Pass that playlist to MPlayer on the command line in place of your
current list of files. (This has the advantage of avoiding the eventual
"line too long" failure.)
When you add a new file to the directory, add it to the text file.
When you want to refresh the playlist, send the slave command 'loadlist
<file> 0'; this should load the specified playlist file in place of the
current playlist. It will stop playback of the current song and start on
the first of the new playlist, but other than that I think it should fit
I am not 100% certain whether '-shuffle' will be respected with the
newly loaded playlist or not, but I am fairly sure that if not the
developers would be willing to fix that.
The 'loadlist' command currently supports two behaviors: stop playback
of the current song and replace the current playlist with the new one,
or continue playback of the current song and append the new playlist to
the current one. What you actually want is the ability to continue
playback of the current song and replace the current playlist with the
new one. This is not presently supported, but I see no strong reason why
it should not be.
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the MPlayer-users