Why do we use upstart for our jobs ?

With Karmic, Ubuntu started the transition to upstart. With Lucid most of the important jobs have been migrated. Since yavdr 0.2.0 we base our distro on Ubuntu Lucid Lynx. To benefit from this new technology we decided early to go this road. The downside is obviuosly that its not that well known and documented as System-V init scripts.

So what jobs do exist in yavdr and whats ther task ?

Lets first start how we get the display ...

displaydevice

This is checking if there is any nvidia hardware and load the nvidia propritary driver. If there is a nvidia card, our default xorg.conf is put into the right place, otherwise a fallback will be used. On completion of this ...

openbox

will be started. The job openbox will start the windowmanager and with that obviously Xorg. With this job and a fairly new version of Openbox we get informed once Xorg/Openbox has been started. The signal which get send here is "openbox-started"

openbox-started

On this event, several jobs are waiting.

openbox-tools

This loads nvidia-settings which have been saved before - to make these settings persistent (i.e. overscan compensation).

launcher

This is starting the "yaVDR launcher". You will see this if you have a mouse connected to your HTPC

logo-start

If vdr is not completed at this stage and until vdr is started up and the TV output can happen, a little boot animation is shown.

vdr-frontend

Once vdr is started up the actual output device (vdr-frontend) is started. What is started here, depends on the frontend you have choosen in the web frontend. At boot, we are also waiting for sound-card-added which gets send by udev once the soundcard is initialized.

graphtft-fe

If you have configured the second screen and enabled graphtft in the web frontend, this job is started as well.

The VDR start

udev rule and dvbmon_helper

At boot the devices get initialized by udev. As soon as a device /dev/dvb/adapter?/frontend* becomes available, an udev rule is capturing that for us. At this time we check how many devices are available. If the number of devices is the same as the saved value, an event will be send to upstart. On this event the vdr will be started. There are 2 upstart jobs working as fallback to this.

dvb-first

In case anything gets lost, since the udev script can not work properly, or the udev event will never come (no dvb devices in use) this is the fallback, to check if the number of devices matches the saved one. This executes the same script as udev.

dvb-last

this upstart job is started 30s after all hardware initialisation is finished. It has more then one purpose. First it checks if there is anything not completed yet (/etc/yavdr/dvbmon.d/..) and will wait for everything to complete first. if that is the case it saves the current number of expected devices. As a fallback it send the signal that vdr can finally start (if that has not happened yet). Until now several information have been saved, and this information will now be send to system log (vdr started by udev, dvb-first or dvb-last, what is the number of devices).

vdr

This upstart job is heavily based on the runvdr script created by Tobias Grimm and Tomas Günther . It features the usual debian features like plugin order, plugin blacklist (order.conf) , it loads any plugin options (/etc/vdr/plugins/plugin.*.conf), loads the default settings from /etc/default/vdr and generates in the end the command line to start the vdr. Those looking in detail into the scripts, will discover that there are some scripts duplicated (/usr/lib/vdr/config-loader{.sh}). Since our packages can be installed also on plain ubuntu, and to ensure all is working as expected there too, the scripts with ending .sh is the one which will be used by ubuntu scripts, the one without is used by yavdr.

vdr-exit-1

Upstart features the possibility to start upstart jobs if another job failed with a defined exit status. We make use of this, to handle different exit states. For exit status 1, the dvb drivers gets reloaded (also based on runvdr script of Tobias) - this does not cover all dvb drivers as some do not have dependency as expected on dvb-core or dvb-usb module, but it should be able to reload a big amount of drivers available. Once the drivers have been reloaded vdr will start again.

vdr-exit-other

This is the second job covering all exit states except 0 (normal exit), 1 (see above) and 2 (fatal error). Those if vdr is crashing or any other not expected exit, the exit status will be logged and vdr will be started immediatly again.

remoted

We cover 3 possibilities to handle remote controls. This is Lircd , inputlircd and irserver. Based on what has been choosen in the webfrontend, this job will be filled with the required script for each of the cases. The event this is starting on is vdr itself, but defining that it needs to be started before vdr. In case inputlirc is choosen, it will be waited for the configured input device first, and only then start inputlirc and thus vdr.

This should give some insight into the "magic" of the startup of yaVDR.