[MPlayer-users] playlist file syntax

[The Wanderer]

James Gatt wrote:

> D Richard Felker III wrote:
> 
>> On Wed, Dec 08, 2004 at 01:04:36PM +0000, James Gatt wrote:
>> 
>>> Quoting D Richard Felker III <dalias at aerifal.cx>:
>>> 
>>>> On Tue, Dec 07, 2004 at 06:20:39PM -0800, Jessica Johnson
>>>> wrote:

>>>>> 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
>> 
>> YES, I DO!!! IF IT'S PART OF THE NAME OF THE SONG!! pretty much
>> anyone who names their mp3s with the full titles rather than just
>> short_name.mp3 runs into this problem.
> 
> 1. I didn't think mplayer was intended to be used as an mp3 player -
> there are much better programs around for doing this, even the
> mplayer documentation suggests this somewhere.

Well, you were the one who used MP3 files in your "this would be useful"
sample (not snipped above, far back though it is). The same reason can
apply just as well to non-MP3 files, as I noted in a previous mail.

> 2. "pretty much anyone" is a grossly inaccurate generalisation. Most
> people either use Windows or like to keep their filenames sane so
> they can be used on Windows. They use two ' characters instead, which
> in most proportional fonts looks identical to ".

...for one thing, that might count as "running into this problem", since
they have encountered the need to represent a double-quote in a
filename. For another thing, *very* far from everyone uses proportional
fonts for filename display - almost all of my own file-naming /
file-listing interaction is done via the command line, specifically an
xterm, and I don't think there even *is* a way to use a non-fixed-width
font there. (I don't think I'd want to, either - it probably wouldn't
look as good.)

I note that you did not snip, but also did not respond to, the
(admittedly less than ideally coherent) comments I made on the notion of
"retaining Windows FS compatibility" - while I recognize that some/many
people do in fact need to do that, I find at-least-almost offensive the
idea that programs which do not specifically need to do so should
*require* people to adhere to Windows filename standards. If people want
to break FS compatibility in their filenames, that's *their* problem
(and their prerogative).

(I also rather object to the notion that "filenames which are not
compatible with Windows' naming restrictions are not sane", but that may
be another argument.)

>>> 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.
>> 
>> putting linefeeds in filenames is idiotic. putting natural
>> characters like " and { and } is not. i want to be able to generate
>> a basic playlist from the output of the "ls" command without
>> needing to do all kinds of additional processing to escape
>> characters...
> 
> Putting double quote characters in filenames is every bit as idiotic
> as linefeeds - I have not yet seen a shell script written to tolerate
> either, as both are simply bad practice.

...no comment, I don't think I have the background (or, at present, the
stamina) to convince you on this.

Well, maybe one comment: your own standard of "usefulness", above.
Double-quote characters in filenames can be useful, but as I said
before, I don't see how line-break characters could do the same.

>>> 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 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
>>> worth defending the current playlist format against features
>>> offered by non-core members?
>> 
>> yes! people use it and don't want it broken for the sake of some
>> silly obscure feature. i use "mplayer -shuffle -playlist foo.list"
>> all the time, and i expect many others do too.
> 
> I generally use mplayer for playing movies, as I expect most other
> users of mplayer do also. It is what it does best. Playlists feature
> little in this mode of operation.

...that *really* depends on your context, doesn't it? There are in fact
potential video-playing-related uses for which playlists could be *very*
useful; I believe I've seen questions on this mailing list which refer
to them, albeit certainly not recently.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.