I've written an init script for mythfrontend, and thought I'd post it here in case it might be of use to anyone else. It isn't meant to cover all setups or situations, just to work well for my all-in-one setup, and be a little flexible.

I originally had startx (and thus mythfrontend) being started via an entry in /etc/inittab, but I didn't like that I would see the boot messages for a couple of seconds between the time that the gensplash image disappeared and when X started. I needed something to start startx earlier, and this did the trick. I no longer have to look at those boot messages, and this approach seems cleaner to me, too.

# X runs on the first VT available. At the point this script runs during
# system start-up, the gettys haven't started yet, so the first available VT is
# VT2. Then, when the getty on VT2 starts, it grabs the keyboard away from X.
# To avoid having to turn off gettys in /etc/inittab, tell X where to find an
# "unreserved" VT.
MYTH_VT="7"

# If there are any other X server options you want to use, set them here.
MYTH_XOPTS="-nolisten tcp -br"

# irexec, part of the lirc package, can be used to run commands in response to
# remote control button presses. If this variable is set, then irexec will be
# started and pointed to the appropriate config file. Leave this blank or null
# to not start irexec.
MYTH_IREXEC="yes"

# Name that irexec is configured to respond to in the lircrc file.
MYTH_IREXEC_NAME="mythirexec"

# Where irexec can find the lircrc file.
MYTH_LIRCRC="${HOME}/.mythtv/lircrc"

Very nice. This is the first one I've tried that's actually worked consistently. (other than an xterm).

one question. When I start from an xterm, I turn on logging using the "-v all -l /home/mythtv/mythfrontend.log" options.

Where would I set those up?_________________Anyone who puts a small gloss on a fundamental technology, calls it proprietary, and then tries to keep others from building on it, is a thief.
-Tim O'Reilly

Do you have to manually log in each time the mythtv box fires up? Or does it just automagically come up to the mythfrontend screen?_________________Anyone who puts a small gloss on a fundamental technology, calls it proprietary, and then tries to keep others from building on it, is a thief.
-Tim O'Reilly

When X is started ba user mythtv, X looks into that file for some commands to execute. Is basically like an autorun for X. First it turns off dpms (So that the screensaver isn't coming on while watching TV) and then it starts fvwm. After this it starts the frontend._________________Kopete OTR Plugin

When X is started ba user mythtv, X looks into that file for some commands to execute. Is basically like an autorun for X. First it turns off dpms (So that the screensaver isn't coming on while watching TV) and then it starts fvwm. After this it starts the frontend.

Ah ok but what is fvwm?
BTW there is no need for a window manager like fluxbox or kde or gnome?

When X is started ba user mythtv, X looks into that file for some commands to execute. Is basically like an autorun for X. First it turns off dpms (So that the screensaver isn't coming on while watching TV) and then it starts fvwm. After this it starts the frontend.

Ah ok but what is fvwm?
BTW there is no need for a window manager like fluxbox or kde or gnome?

AFAIK fvwm is a window manager. So I would assume that you need a window manager._________________Everything can be done. There's just a longer delivery time for impossible projects.

Yes. fvwm is a window manager. There is no need to use a windowmanager for mythfrontend but the devs say that it is only tested with a wm and you could run into window focusing problems. I had mythfe running without a wm and I have seen this problems. Sometimes when a warning message comes up (for example that the connection to the backend is lost) you cannot see it because it appears behind the frontend. Since I use a wm I haven't seen this problem any more.

Most people use fvwm because it would be senseless to compile kde or gnome for many hours while all the features they offer aren't used. fvwm is just a wm without any other tools._________________Kopete OTR Plugin

I've written an init script for mythfrontend, and thought I'd post it here in case it might be of use to anyone else. It isn't meant to cover all setups or situations, just to work well for my all-in-one setup, and be a little flexible.

I originally had startx (and thus mythfrontend) being started via an entry in /etc/inittab, but I didn't like that I would see the boot messages for a couple of seconds between the time that the gensplash image disappeared and when X started. I needed something to start startx earlier, and this did the trick. I no longer have to look at those boot messages, and this approach seems cleaner to me, too.

thatdude- This is exactly what I was dreading trying to make on my own, thank you very much for posting this and saving me a lot of research and work!

Yes. fvwm is a window manager. There is no need to use a windowmanager for mythfrontend but the devs say that it is only tested with a wm and you could run into window focusing problems. I had mythfe running without a wm and I have seen this problems. Sometimes when a warning message comes up (for example that the connection to the backend is lost) you cannot see it because it appears behind the frontend. Since I use a wm I haven't seen this problem any more.

Most people use fvwm because it would be senseless to compile kde or gnome for many hours while all the features they offer aren't used. fvwm is just a wm without any other tools.

That would be quite underestimating FVWM, but anyway. Why use FVWM and not twm? I think (I'm not sure though) that twm still comes with Xorg by default, so why compile FVWM if twm is already there?_________________Fvwm|Fvwm forum

That would be quite underestimating FVWM, but anyway. Why use FVWM and not twm? I think (I'm not sure though) that twm still comes with Xorg by default, so why compile FVWM if twm is already there?

IIRC there's been reports of window focus issues with twm, but only in certain cases- like when starting an external program when all the window decorations are disabled? Entirely hearsay of course, since there's all sorts of problems caused by user configuration...

THANK YOU! I've just figured out why my system was hanging just after udev... Damn ivtv / kernel-2.6.18 problem! So.. After spending 2 weeks trying to figure that out I'm happe I found this treasure :)

Thanks a lot.. Saved me some work :) Now to setup lirc for mythtv - and figure out why one of the cards in the machine only work 50% of the time.. :) But that's a completely different problem._________________-- Jakob L. O. Rosenlund

I just set up my mthtv box, and was looking for something to do exactly this... I have fluxbox autostart mythfrontend, but that didn't quite do it. I also wanted something that would not require either kdm or gdm, and this was spectacular!

Since I first posted, I discovered that irexec had its own init script (duh!), split my all-in-one box into physically separate frontend and backend machines, and stopped using a window manager with no ill effects.

Here is the simpler version currently running on my net-booting frontend...

# X runs on the first VT available. At the point this script runs during
# system start-up, the gettys haven't started yet, so the first available VT is
# VT2. Then, when the getty on VT2 starts, it grabs the keyboard away from X.
# To avoid having to turn off gettys in /etc/inittab, tell X where to find an
# "unreserved" VT.
MYTH_VT="7"

# If there are any other X server options you want to use, set them here.
MYTH_XOPTS="-nolisten tcp -br -dpi 100"

The loop in .xinitrc allows mythfrontend to automatically restart if it dies, or if I kill it using a button on my remote. The init script is still able to stop mythfrontend because it kills the script running the loop.

I may take the suggestion to submit this for inclusion in the mythtv ebuild, but I wouldn't count on it getting in since there is already a different "autostart" method that the ebuild sets up when that use flag is enabled.