Playing m3u from comandline

Submitted by saa on Fri, 2007-03-30 18:59

Forums:

Short question:

Is there some 'official' way to start playing a playlist from a command line?

Long question (actually the same):

I think I am not very familiar with whole moc functionalities, so I am not sure if this message is a question-on-usage, a feature request or a patch. So, please let me take a little of your time to explain my needs.

My needs are somehow specific. I need the following command-line player features:
1. start playing a file;
2. start playing files from an m3u;
3. next/prev/stop/pause/resume (when playing m3u);
4. tell what is playing now.

The player must not require X, and desirably should play as a background server. Also, player should not be limited to playing mp3 only.

This is required to provide IR-controlled music, somewhat like a radio-station with feedback. I use LIRC and my own perl script.

So, after some searches, I recognized that MOC fits my purposes best. I took moc, it was 2.3.3.

To play file, I used `mocp -l filename.mp3`. But I couldn't find how can I start an m3u file. So, I applies a little patch to moc:

--- begin ---

--- moc-2.3.3/interface.c 2005-12-29 17:06:55.000000000 +0300
+++ moc-2.3.3.my/interface.c 2006-02-05 03:58:53.000000000 +0300
@@ -4295,9 +4295,16 @@

plist_init (&plist);

- for (i = 0; i < arg_num; i++)
+ for (i = 0; i < arg_num; i++) {
if (is_url(args) || is_sound_file(args))
plist_add (&plist, args);
+ if (is_plist_file(args)) {
+ struct plist tmp;
+ plist_init(&tmp);
+ plist_load(&tmp, args, NULL);
+ plist_cat(&plist, &tmp);
+ }
+ }

if (plist_count(&plist)) {
int serial;

--- end ---

After that, I could start m3u's with `moc -l playlist.m3u`

Thank you for reading so much :) My questions are:

1. Is there some 'official' way to start playing a playlist?
2. If no, would that feature fit well with mainstream MOC ideas?

daper

Mon, 2007-04-02 16:07

If you want to load a playlist and start playing from it, the solution is:
mocp -a playlist.m3u -p

You can only request playing from the first file on the playlist.
next/prev/stop/pause/resume commands are available, use mocp --help
Use mocp -i to see what is playing now.

--
Damian Pietras - MOC developer

saa

Sat, 2007-04-07 19:39

Thank your for the solution.
The thing that I missed is just 'mocp -c -a playlist.m3u -p'.

I did not think of trying '-a -p' or '-c -a -p' because some time before I tried 'mocp -i -f' and learned that that does not work the way I expected. I have to issue 'mocp -i; mocp -p' pair instead. So, I was thinking that groups of commands are not supported.

If some new version of MOC would also treat 'mocp -i -f' as "print file info and go to next file", I would be even more thankful :) This is useful when I dislike a song and want to remove it and skip immediately. '-i' is needed here to let my script know which song I dislike.

As for next/prev/etc, yes, I know of them, they are just why I chosed MOC player. Sorry for vaguely written first message and for a delay in reply.

I think MOC is a great thing. Targeted at being controlled directly by a human (and working this way perfectly), it also meets specific needs like mine. I think this is a sign of an excellent design.

Thank you for MOC player!

daper

Mon, 2007-04-09 08:56

I've looked at the issue with many command line arguments. The reason why it sometimes works, sometimes not is that all commands are grouped in two groups, only one group is executed when you use mocp -a -b -c -d so if you use commands from both groups, only commands belonging to one of them are executed. It's not logical and seems to me like legacy or bad design code. It don't think the mocp -i -f case is worth redesigning this part of code.

--
Damian Pietras - MOC developer

saa

Sat, 2007-04-28 20:45

Hello again!

When I use mocp -c -a -p playlist.m3u, all playlist entries gets sorted according to their filenames.
This is not what I expect when playing a playlist. I wish playlist entries were not sorted.

I've tried to get what I want by patching moc-2.4.1/interface.c.

Now, plist_sort_fname() is called from add_recursively(), not from interface_cmdline_append(), and only if there is at least one directory entry among of args[] given to add_recursively().

If all args are non-directories, sorting is not invoked.

That is not perfect (a better solution would be to sort directories separately), but I suppose that might fit the major of needs.

(I did not test sorting of directories after this patch, so I am not sure if that is correct).

daper

Sat, 2007-05-05 06:47

Good point. I'll try this and probably fix it in the next release.

--
Damian Pietras - MOC developer