2

I want to launch MPlayer via SSH and let it run (I’m a radio fan). For this I SSH to my remote machine (a Cubietruck running LUbuntu) and I issue the following command:

screen mplayer -playlist .path/to/the/playlist

Everything works as expected, but when I exit my SSH session the music stops altogether. After logging back in I cannot find my screen instance anymore (screen -ls says No Sockets Found in /var/run/screen/ )

I’ve used screen with another application (such as rTorrent) and everything worked ok. Is this a specific MPlayer issue?

Update: the reason I use screen and I'm not going the "nohup" way is that I want to re-gain access to the mplayer instance (change the station, change the playlist etc.)

Daniel Platon
  • 121

2 Answers2

2

Here is your command:

screen mplayer -playlist .path/to/the/playlist

Using screen seems like overkill. To run processed continually in the background on a Linux machine while logged out of a terminal session, I recommend using nohup and & like this:

nohup mplayer -playlist .path/to/the/playlist &

nohup stands for “no hang up” meaning you can log out of your terminal session and the command following nohup will continue to run. The & in shell command usage basically means “take the preceding command and run it as a background task”. So if you combine the two you are basically saying, “Run the following command even if I exit the terminal and run it as a background command so my session has access to the terminal again.”

Giacomo1968
  • 58,727
0

You should take a look at: http://www.tuxradar.com/content/command-line-tricks-smart-geeks

Interesting Bit:

Remote control MPlayer

There are two types of people in this world: those who think MPlayer is the best media player in the history of existence, and those who are wrong. One of MPlayer's lesser-known features is the ability to control it from a console, a shell script or even over the network. The secret to this trick is in MPlayer's -slave option, which tells the program to accept commands from the stdin stream instead of keystrokes. Combine this with the -input option, and commands are read from a file, or a FIFO. For instance, try this in one terminal:

mkfifo ~/mplayer-control mplayer -slave -input file=/home/user/mplayercontrol filetoplay

Then, in another terminal or from a script, enter:

echo "pause" >~/mplayer-control

This command will pause the currently running MPlayer, and issuing the command again will resume playback. Note that you have to give the full path of the control file to MPlayer, with /home/user and so forth, because ~/mplayer-control alone won't work. There are plenty of other commands you can send to MPlayer - indeed, any keyboard operation in the program triggers a command that you can use in your control script. You can even operate MPlayer from another computer on the network, using SSH or Netcat. See this example:

ssh user@host "echo pause >mplayer-control"

Here, we log in to a remote machine (host) with the username user, and run a command to send pause to the remote machine's MPlayer control file. Of course, this can be made much faster if you have SSH key authentication enabled, as you don't need to give the password each time.

If you run MPlayer in slave mode like they mention here it should not matter what the console does it should have MPlayer remain in background watching that input file for it's commands and not terminal window that called it.

Last Note: They say do blah from a different terminal just to show it works over a network really so long as you edit the listed file as they show it does not matter if the file is edited by the same machine or another all that matters is MPlayer is watching that file for any commands placed in to it and then acts on what the command is asking it to do.

Pariah
  • 152