[MPlayer-users] playlist file syntax

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Wed Dec 8 19:40:43 CET 2004


Hi,
> > > The docs say that the playlist format is one file per line. So it doesn't
> > > seem to be possible to make a playlist file that includes a playtree.
> > > (Correct me if I'm wrong here.)  It would be useful to be able to specify,
> > > say
> > >
> > > { "song1.mp3" "song2.mp3" }
> > > { "song3.mp3" }
> > >
> > > in a playlist file.
> > >
> > > I've been thinking of modifying the source to expand the accepted syntax of
> > > a playlist file.  Is this something other people would be interested in?
> > > Any core developers want to comment on the likelihood of this patch being
> > > accepted?
> >
> > it won't be accepted, because it makes it impossible to play a
> > playlist with a file named '{ "song1.mp3" "song2.mp3" }' in it!
> 
> How is that useful? Do you know anyone who puts double quotes in filenames? I
> know you *can*, but... After all, is there a way to put filenames containing
> linefeeds into playlists? If not then there are already restrictions in the
> filenames allowed by the playlist format over and above those of the file
> system.
> 
> > there'd at least have to be an alternate format that you specify
> > somehow.
> >
> > btw how is this useful? the only point of playtree is for assigning
> > options to groups of files, right? otherwise a playlist is just as
> > good...
> 
> Particularly looping. It would be good to be able to specify options like
> looping in playlists as well. Right now the playlist support is so basic that I

looping can also be done by adding a file multiple times...

> don't think it offers anything more than can be achieved using a shell script
> and just calling mplayer for each file to be played. To this end is it really

You can always achieve things with a script unless things that depend on
the internal state of the program (e.g. crossfading or making the
window stay in the same place, but those aren't possible with MPlayer
anyway - well, with -fixed-vo a bit but not really)

> worth defending the current playlist format against features offered by
> non-core members?

Where comes the point to point out that you didn't answer the question
what the feature you offer is. At least I didn't see it, only a proposal
of a different playlist format.
And by defending the current format is a way to make sure a new one isn't
just a different piece of crap, but something really better. I guess we've had
enough of that "let's replace that bug with another one" :-(.

> I am having this rant because I've seen a lot of derogatory comments made to
> people asking innocent and often valid questions on this list. It is foolish

Some people might see it as derogatory that you decide what is innocent
or valid...

> for the core mplayer team to believe that everyone else is incapable of coming
> up with useful ideas and writing good code for them. If it is made too hard for
> people to submit patches that are accepted, then mplayer development will simply
> fork.

I fail to see a fork as a threat.
Anyway, quite a few people are active a few months
and then aren't reachable by email forever, meaning that we are stuck with
maintaining their patches. I have little motivation for applying a
patch when I think that it will be a pain in the a** to maintain it, no
matter how well it may work at the moment.

> I have some patches that fix issues and crashes I have come across in mplayer. I
> have not submitted them because I feel in the current climate they might not be
> welcome. This doesn't hurt *me*, as my version of mplayer no longer suffers

They are never not welcome. Of course if it does something that seems
really stupid to someone you might get a flame. So what? I promise, you
won't even feel the heat physically, not to mention really get hurt.
Btw.: I never got into something that I consider a flame myself. So I
also tend to think that those who do aren't really innocent...
Much more probable is that you get ignored - I'm sure that can happen to
you in the case of other projects just as well. MPlayer code is tricky
in many places and people often don't feel motivated to try to
understand what exactly a patch changes...

> from these problems, but it hurts all other mplayer users who suffer from these
> problems and don't know how to fix them - unless / until someone else fixes them
> and submits a patch that will be accepted. Until the attitude on the mplayer
> lists changes a *lot* to the better and more welcoming, this will not change.

I don't know how you wanted it to sound but here is what this sounds
like to me:
You expect others to change the way you want them to be
before you share your improvements to their code with them?
I certainly hope this is a misunderstanding...

> (This is not aimed at any one person by the way - It's certainly not aimed
> directly to Mr. Felker's post to which I have responded.)

I'm undecided whether that is a good or a bad thing, but I tend to the
latter - it's hard to defend against something that is directed at
nothing.

Greetings,
Reimar Döffinger




More information about the MPlayer-users mailing list