[MPlayer-users] playlist file syntax

[James Gatt]

Quoting Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:

> 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...

Agreed.

> > >>>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 ;-) )

Ok, I've never actually *done* that... One of the reasons is that I generally
only use mplayer from the command line when something has gone wrong. Otherwise
it's started by a script that I run from irexec.

> > >>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.

Because the current format uses every available character other than linefeed as
a part of the filename, there is no room for any kind of extension. If every
suggestion will be refused if it breaks the current format then mplayer
playlists can never improve. I was questioning this reasoning, not suggesting a
new format. (The original suggestion was not mine.)

> > 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).

It was not my suggestion; I can't comment on it.

> > >>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.

I think I am capable of having a reasonable opinion of what is innocent and / or
valid. People might not always agree with me, I don't expect them to. If I
believe something is valid then I will say it is valid, just as I will say
grass is green, rather than grass appears to me to be green. Fortunately most
people don't take offense to this level of brevity; else the english language
would be even more verbose than it already is.

> > 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...

I guess not wanting to choose between being ignored or being flamed is one
reason I haven't posted any patches yet.

> > >>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.

If they are good then they will develop features or fix bugs that you would wish
you had the resources to have done. As the forked code progresses it becomes
harder to integrate changes from the "other" version.

> > 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.

Sounds like you need some more maintainers to share the workload. I know too
many can lead to communication problems though. How many are there at the
moment?

> [...]
> > >>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 guess I can't really comment until I have submitted some patches. I just see
so many patches ignored, and people complaining of problems that other people
have patches for that they are still using but that have been ignored / refused
/ whatever by the maintainers.

> > 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.

See above regarding more maintainers.

> > 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.

Agreed.

> > 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.

Again, it was not my idea; but I take your point.

> > 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 ;-) ).

Thanks, every bit of nit-picking appreciated. ;) I consider providing a patch
that actually fixes a problem to be constructive helping. If the person writing
the patch has not understood or taken into account how a relevant part of the
software works (or should work) then the patch might be more of a hack than a
real fix. Even so, if it does not break anything else then it is still an
improvement over the unpatched software for the users it helps. This can then
be flagged for future removal when (if) the real issue is fixed properly. To
refuse a patch like this makes mplayer no better to the affected users (who
don't know how to fix it themselves) than proprietary software that the vendor
refuses to fix.

Regards,
James.