[MPlayer-users] Mplayer usage as digital signage

[Marcin Gałczyński]

W dniu 2013-09-15 12:41, Reimar Döffinger napisał(a):
> 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.

Right, thanks. I need to fix this. The reason for such approach was
originally that it was not really clear from slave mode documentation
which playlist entry the loop command will affect.

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

Indeed, they are long enough (few minutes at least) and the schedule
of jobs that run the whole thing was carefully designed.

>> and also using lsof to
>> get current file is not staight either.
> 
> Using some tricks like piping for this specific message with
> ...
> The disadvantage is that if either of MPlayer or your script
> crashes the other one will hang as well.

Ok. While lsof just does the job, it also allows that if mplayer crashes
my script will hang. Anyhow - it is being run from systemd, which has
a timeout and will kill the "reload" task if it takes way too long.

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

There are 2 movie changes per hour and player is reset overnight,
that does not pose a threat. (max 48 playlist entries should not
take all of the memory ;)

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

I'll check the docs again and suggest an update there if it makes
sense. This one was not really clear for me.

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

Agree! I will look deper in the options you mentioned. So far i like
the one to run slave mode commands via command-line processing function
most.

It would be probably quite cool to have complete external
playlist control with some obvious "read current playlist and status"
functionality available, that would be on demand instead of greeping
the output pipe. I'd see that would allow mplayer to be more of
use for folks creating their own guis/players/etc. But that sounds like
a big change and contradicts the aforemention release strategy.

Thank You very much for your answers and comments.

--best rgds
Marcin