HDTV and Kodi in your living room - based on Nvidia VDPAU, VDR and Ubuntu Linux

October 15, 2010
08:44 PM CEST

New features in upcoming yaVDR 0.3: Upstart

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



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


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"


On this event, several jobs are waiting.


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


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


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.


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.


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.


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.


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


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.


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.


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.


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.

  • 0 Comment(s)

Your comment


« October 2010»
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Latest Comments

will there be more recent releases?
January 22, 2016 08:43 PM CET
They did it :-)
September 17, 2014 01:51 AM CEST
Happy anniversary!
January 15, 2014 05:37 PM CET
January 15, 2014 01:30 PM CET


Copy and paste this link into your RSS news reader

RSS 0.91Posts
RSS 2.0Posts

This is hot

It's time to talk about upcoming yaVDR 0.4
670555 times viewed
May 10, 2011
Finally: Announcing yaVDR 0.4
160823 times viewed
October 25, 2011
Installation from a USB stick: Now smoother with hybrid ISO...
157846 times viewed
July 15, 2013
New features in upcoming yaVDR 0.3: Gyration and Inputlircd
153268 times viewed
October 15, 2010

Copyright © 2010 yaVDR. This page was last updated on 2016-03-03.