[MPlayer-users] Mplayer usage as digital signage

[Reimar Döffinger]

On Sat, Sep 14, 2013 at 05:14:50PM +0200, Marcin Gałczyński wrote:
> # stop current loop
> /bin/echo "loop -1 1" >/tmp/mpfc1
> # add new file
> /bin/echo "loadfile $NEWESTMOVIE 1" >/tmp/mpfc1

This order looks wrong, you should have a race condition
here where the first movie might finish in-between those two commands.
(in theory there are other race conditions, but those can be avoided
by ensuring that the movie files are long enough, this one can't)

> Getting the latter done felt like hacking, including getting thru
> player code to understand the loop controls,

Using "set_property loop" instead of the "loop" command it might be a bit more obvious.
Either way the slave interface only allows modifying the
currently playing file.
I don't think anyone is working on changing this.

> and also using lsof to
> get current file is not staight either.

That's not really the intended way admittedly.
You're rather supposed to watch MPlayer's output, e.g.
enabling identify mode and looking for ID_FILENAME=
(note: I am not sure which messages exactly will be printed
while looping)
Using some tricks like piping for this specific message with
grep you could then wait for the switch with a simple "read"
from the fifo you direct MPlayer's output to.
The disadvantage is that if either of MPlayer or your script
crashes the other one will hang as well.
Also a general comment: your approach will cause the playtree
to grow infinitely (you append new files over and over).
Maybe this will take too long to matter for you, but at some
point you will run out of memory like this...

> Now I do have also some questions
> - will this keep on working - maybe there are upcoming developments
> that would be breaking (fixing? ;-) the looping control and slave
> mode?

As I mentioned: no plans.

> - is this the only way to make this work - or being less general -
> is there a way to avoid waiting for the movie to start playing
> before setting the infinite loop (without the wait it did not really
> work)?

Also as mentioned: there is no way to affect anything but the currently
playing file.

> - (not this list maybe) would code contributions in the area of
> slave control be useful? i would be happy to contribute :)

Yes, though as a warning: I prefer small, simple changes vastly
over complex and invasive changes. Mostly because I think code
review is really important. Or to put it differently:
I think "release early, release often" is a good strategy even
for contributors IMHO.
If you wonder what might be good things to do:
It might be possible to extend the code loading a file to e.g. accept
command-line arguments or similar which might address some of your
annoyances (see the play_tree_set_param function).
ASX playlists actually used to have this option to allow specifying
arbitrary command-line options (see asxparser.c:409), but unfortunately
this is a huge security issue if users would play untrusted playlists,
so it was disabled.
Maybe even more powerful would be a command that just pushes the
whole string through m_config_parse_mp_command_line, but that might
involve some tricky cases since it wasn't designed to be called in the
middle of playback (but it would address a feature request of another
user: allowing to add two files and loop over both of them via slave
mode, like the command-line {a.avi b.avi} -loop 2).
Alternatively it would be possible to extend set_property to also
applied to queued playlist entries, but this would probably be a
lot more messy, since today set_property works by modifying the playback
state.