mplayer and screen, in a fight to the death

10 Replies

Edit, 2011-01-01: I should probably apologize at this point, because a clean and default reinstall made this problem disappear. Apparently it was a problem with my system configuration, somewhere. Sorry for the false alarm. 😳

It took me long enough, but I finally ran aground on that quirk between screen, mplayer and the framebuffer in Arch Linux.

I’ve had people e-mail me or leave questions here asking how to get around screen’s stranglehold on the framebuffer.

For the uninitiated, you can duplicate this … behavior … by building an Arch system, forcing it into a non-default framebuffer dimension, starting screen, then starting mplayer.

Just be prepared to cut the power on your machine, because mine locks completely each time.

Outside of screen though, mplayer seems to be working fine. It will even seek out the framebuffer on its own, without the -vo fbdev flag, and play a movie normally.

But as for fixing that lockup … ?

To be honest, I don’t know. I need to experiment a little more. Right now the only way I know to get both screen and mplayer working well together is to include Xorg.

I know what you’re thinking: You’re thinking, “What … ?” It’s nutty, but if I start screen in a terminal emulator from within X, then start mplayer from there, I can force mplayer to the tty1 on the framebuffer.

Which is so completely bizarre as to be absolutely unuseful. I’ve heard of some wacky solutions to weird problems, but that is not a solution. Heck, that’s not even an option. But what can I say: It works.

And when I think about it, it does lend itself to a few interesting permutations. … 😈 Stay tuned. … 😀

10 thoughts on “mplayer and screen, in a fight to the death”

  1. x33a

    Well, i don’t watch videos in the framebuffer. But, after reading your post i tried to play an hd video inside screen in the framebuffer, and it played fine.

    Though, i had to explicitly pass the -vo fbdev option. It played fine with both fbdev and fbdev2.

    My system: archlinux i686 with latest nvidia binary drivers.

    Reply ↓
  2. Kaleb Elwert

    It’s worth pointing out that screen when started from a terminal, the $TERM variable is screen and when started from a tty, it ends up being screen.linux. Perhaps there’s some difference there. Maybe messing around with the term variable would help – just guessing.

    I use gentoo so I really can’t check what happens with arch, but this is the first thing I thought of. Good luck!

    Reply ↓
  3. ErSandro

    I don’t think it’s an arch problem because mplayer works fine for me if I launch it from screen in an “X-free/framebuffer” installation.

    I still prefer X for video playback because reproducing the same file uses less CPU.

    Reply ↓
  5. cthulhu

    I have a similar problem in tmux, where fbi wont work, meaning tmux+elinks+fbi is not working, so i cant look at pictures while using elinks from a tmux-session.

    Reply ↓
    1. agentlandmine

      Dito to that, except I’m in dvtm. running Debian. Perhaps someone will post a fix?

      Reply ↓

  6. Pingback: Just for fun: A three-part home media system « Motho ke motho ka botho

  7. nothingspecial

    Well as far as mplayer playing videos within screen or dvtm…….

    …it suddenly works. Shrug.

    However fbi does not.

    I have tried changing the $TERM variable.

    Reply ↓

  8. Pingback: Links 3/1/2011: KOffice 2.3.0 Released, New View for Activity Journal | Techrights

  9. nothingspecial

    I`ve been searching everywhere for a solution. When I first started using the console without X I was informed that you can`t use the framebuffer within a terminal muliplexer (screen, dvtm, tmux etc). Ok, fair enough, if it can`t be done it can`t be done, I`ll use another tty.

    However, now mplayer suddenly works, surely any framebuffer app such as fbi can be made to work. The question is, how?

    Reply ↓

Leave a comment