[MPlayer-users] Mplayer playlist question

The Wanderer inverseparadox at comcast.net
Thu Oct 11 13:23:18 CEST 2007

P J P wrote:

> Hello Wanderer,
> On Wed, 10 Oct 2007, The Wanderer wrote:
>> Please do not, ever, crosspost a message between the -users and the
>>  -dev-eng mailing lists.
> Sorry, my fault! Please excuse me for doing that. I just thought that
>  developers should also know about it.

The only way I can see it could be appropriate for the development list 
is if it were a feature request - and the standard response to feature 
requests is "send a patch".

Regardless, virtually nothing belongs on *both* lists; the correct thing
to do would be to pick one and, if you found out you were wrong later,
repost to the other.

For the moment, however, no practical harm done.

>> 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.
> Well, thanks for the information; But I know that stuff. And
> secondly, `*.mp3' was just an example, one could very well replace it
> with a text playlist file(I do sometimes). In either case, my problem
> sustains.

If the command-line list of files is replaced by a playlist file, then 
the problem becomes a matter of refreshing the contents of the playlist 
file (which can easily be done by an external program rather than by 
MPlayer) and then telling MPlayer to use the new playlist instead of the 
old. My suggestion about a possible extension in functionality for the 
loadlist command would make this fairly easy; just have a shell script 
containing a loop, something along the lines of

mkfifo mplayer_slave_fifo

mplayer 0loop 0 -shuffle -playlist playlistfile < mplayer_slave_fifo > 
/dev/null &

while 1; do
   ls songs/ > playlist;
   echo loadlist playlist 2 > mplayer_slave_fifo;
   sleep 240;

As I said, extending the loadlist command to allow this sort of 
functionality seems like a reasonable request to me, where your original 
request does not.

>> 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?
> No, I never heard of moosic before.

You may want to look into it; it may allow you to obtain something like
the desired behaviour without needing specific support from MPlayer.

>> 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.
> Okay, fair enough.

...I'd just snip this out as a settled point, but from what you have
said below it does not seem that you have entirely understood what I was
trying to get at.

>> 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.
> No, it is not random. It is based on the file creation time. Mplayer
> should pick only those files which were created in last 5 minutes.
> OR pick those file which were created after the time when mplayer
> created its playlist.

...I think one of us is misunderstanding the other.

You originally requested the ability to have MPlayer "rescan" the
directory where the files are located, and add all of the new files in
it to the playlist.

What your most recently quoted paragraph above seems to be requesting is
the ability to have MPlayer "rescan" the directory and *replace* the
playlist with all of the files which are new enough. This would be even
more complicated to implement than the original suggestion, and seems
much less desirable.

The reason I said "random" is because you are using the '-shuffle'
option, which puts the playlist in random order. This can be somewhat,
if not perfectly, simulated by simply choosing a new file at random from
the complete list of available files every time. My paraphrase of your
request above involved having MPlayer automatically replace the entire
playlist after every played file and randomly select a new song from the
new playlist.

>> I do not think that the kind of functionality which would be
>> necessary to support that really belongs in MPlayer.
> Well it's a matter of refreshing mplayers playlist, and I don't see
> who else can do it, if not mplayer.

Anything which is capable of handling playlists and invoking an external
program, for one thing. moosic is designed for exactly that purpose.

For that matter, it could also be done with a wrapper script such as my
example one above, albeit in a cruder way given current functionality.

Given that you are constantly talking about "refreshing" a playlist, I
do not think that you are using the concept of "playlist" in the same
way that MPlayer understands it. I do not, however, presently have time
to hash the matter out in detail; I need to get ready for work.

>> Ew. If you want to send a command to MPlayer, you should do it not
>> with signals but with slave mode.
> Erm...I don't know about slave mode. What is it?

Read the man page on the '-slave' option, and read DOCS/tech/slave.txt.

>> 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 your need.
> Ah, how is it different than restarting the mplayer? I don't want to
> do that.

<shrug> In some senses it may not be, but it is a cleaner solution
overall. If the functionality of the loadlist command were to be
extended as I suggested in my previous mail, then it would accomplish
what you want except for not being automatic - and the automation can be
easily if not trivially accomplished with a shell script like the one I
gave at the top of this message.

I would support a request for such an extension to loadlist, but as a
possible alternative and/or stopgap, I would really suggest that you
look into moosic and see if its feature set is enough to satisfy you.

       The Wanderer

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 mailing list