[MPlayer-users] playlist file syntax

[Reimar =?UTF8?Q?D=F6ffinger?=]

Hi,
[...]
> >>>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.

I forgot to say: This is a hint to a way it could be accepted. E.g. with a -extplaylist option. But also keep in mind that a complex playlist format
can easily have security issues...

> >>>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...
> 
> However, without the playtree construct you can't break out of the loop 
> as no loop as such is defined.

Is that currently possible with MPlayer (I mean in reality, not just if most of the code is there ;-) )

> >>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)
> 
> I only use mplayer for playing movies and television programmes. The one 
> useful piece of continuity I want is for it to keep the TV output on and 
> not re-initialise it between files. However it does not do this (yet), 
> so a script does just as well for me.
> 
> >>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 do agree with not changing things for the sake of it, however I 
> haven't yet seen what I would call a good reason for keeping the 

Which was my point: You are asking for a good reason to keep the current format, whereas I (and probably some others) have not yet seen the reason for
a new format. This seems the wrong order to me.

> existing one, so if someone has good ideas for some features it wouldn't 
> do any harm to listen rather than just say: "it won't be accepted, 
> because it makes it impossible to play a playlist with a file named '{ 
> "song1.mp3" "song2.mp3" }' in it!". (Which in itself looks like an even 
> more ridiculous argument than I think was intended, unless the sarcasm 
> was deliberate.)

Well, that's how some people are ;-). But actually there was very little to listen to in your first mail (as far as I can tell nothing except that you
want a playlist format that can represent a playtree - a feature I up to now haven't really found useful and afaik very few other players have).

> >>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...
> 
> I don't see your point. I see comments that appear to me to be innocent 

that "appear to me" is what was missing in your first post IMHO.

> and valid, and people get flamed for writing them, like they are "lower" 
> beings than the "developers". That's out of order. I know it can get a 
> little bit frustrating when someone hasn't read and understood the right 
> section of the manual, but in that case the right thing to do is either 
> help them or shut up. I no way is it the right thing to be hostile, and 
> I've seen that on this list recently. I am not going to cite examples 
> because I don't want this to become personal.

I can understand that, but I'm not sure if people would prefer being ignored - something I personally find worse... 

> >>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.
> 
> If a fork occurred and several people decided they were interested in 
> improving the "other" version, then these people are a resource you have 
> lost access to. It won't make the original mplayer any worse, but it 
> won't help it improve either.

Yes, but if they are good they will try other aproaches and make some things better (but I'm certain that there will be lots of things we will do
better ;-) ). And if they aren't good it won't exist for long.

> A patch that will be difficult to maintain is not usually the best way 
> of solving the problem the patch was written for. However, quite a lot 
> of the mplayer code has clearly evolved much since it was originally 
> architected, and this alone can make for difficult maintenance.

It does for sure! We are quite busy with fixing old bugs and bugs that show up because other bugs were fixed etc. That was one of the reasons why G2
was started afaik. And it also is another reason for being reluctant to accept patches unless they are really convincing, we sure have more than enough bugs and ugly code.

[...]
> >>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...
> 
> I probably didn't express that very well. Right now I feel that mplayer 
> is much more "closed" than other projects I have experienced. I don't 
> know how many "bad" patches the mplayer developers get from people, but 
> the code itself is not clean and definitely looks like a work in 
> progress. I am not knocking it - I take it as I see it, and if it suits 
> my purpose then I use it.

I can't agree. I was amazed at how fast I became maintainer. So I just can't help but think that either I'm excpetionally lucky or that other people
do something wrong...

> I don't like power-hungry empire builders, especially in open-source 
> projects. I understand the need for people assigned responsibility for a 
> piece of code to be able to vet what goes into it, of course they have 
> to do that. Every time I hear of a patch being refused I wonder "was it 
> really bad?". I get the feeling that any patch I offer would be refused 
> for some or other (probably very petty to me) reason - there seems to be 
> a strong culture of preserving the status quo rather than moving on. 
> That's just the feeling I have gained from reading the mplayer lists for 
> the past few months. I hope I am wrong.

There aren't that many patches that are rejected - most just don't get any comment. And that actually is caused by the fact that there is no
maintainer for the code or at least the maintainer is quite inactive.

> It is directed much more generally than to one person. I was just 
> reading once more the words to describe "your idea won't be accepted by 
> the gods because I've thought of a problem with it", rather than 
> something perhaps a little more constructive, like a suggestion of how 
> to solve both the need for improvement and backward compatibility. To be 

As I mentioned above, rich actually suggested a solution... Anyway, there are so much more users than (active) developers at the moment that I don't
think it is asked too much if you try to solve those problems with it. An answer that goes above a hint to problems (which I find helpful even if it
isn't formulated nicely) takes a lot more time.

> this negative to someone who's only offering to improve mplayer does not 
> encourage me to want to put myself in that position. That is what made 
> me write my original reply - the message is simple: If you are that 
> negative, you will put people off, and sometimes it doesn't take much.

The other solution would of course be to see the answers not so negative but take the good side of it: Rich told you about a problem with your idea
and gave a hint on how it may be fixed.

> To all mplayer developers: I hope I have not offended anyone - that is 
> not my intention. I am trying to be constructive in saying "be careful 
> how you treat the people who want to help you".

At least I am not offended. But I am not really convinced either I have to admit. And also some people have a very high dislike against people who
"want to help" (in the negative sense of "talk a lot") but never really help (this is not directed at anyone at all, just another attempt to inspire a
bit more understanding, and nitpicking a detail in your formulation ;-) ).

Greetings,
Reimar Döffinger