Dear VDR folks,
looking around for systemd service files I found three examples. One from OpenBricks [1],
[Unit] Description=Video Disk Recorder After=lircd.service pvr.service ConditionPathExists=/run/geexbox/pvr/vdr
[Service] ExecStart=/usr/bin/runvdr Restart=always
[Install] WantedBy=multi-user.target
one from a VDR-Portal forum post [2]
[Unit] Description=Video Disk Recorder After=lircd.service
[Service] ExecStart=/usr/local/src/VDR/vdr --lirc=/run/lirc/lircd -s /usr/local/bin/vdr-shutdown.sh -v /var/lib/vdr/video -w 90 -Plive -Pstreamdev-server -P 'epgsearch --config=/etc/vdr/plugins/epgsearch' -P 'xineliboutput --local=none --remote=37890' ExecStartPost=/usr/local/bin/svdrpsend.pl remo off Restart=on-failure
[Install] WantedBy=multi-user.target
and the one shipped by openSUSE [2].
[Unit] Descritpion=VDR After=lirc.service
[Service] Type=once ExecStart=/usr/local/bin/runvdr TimeoutSec=0
[Install] WantedBy=multi-user.target
As the comments in the VDR-Portal thread [2] suggest, it would be great to do without any shell/Bash script and more or less execute plain VDR and let systemd do everything else.
heise open published an article about Upstart and as an example converted the VDR init.d script to an Upstart script [3].
Looking at that example I disagree with only starting VDR when an USB DVB device medium is plugged in, since there are use cases like IPTV or a VDR client.
So how could such a generic set up look like. Do output plugins need to ship there own service files? Like xineliboutput which can also be run as a local frontend and for example sxfe needs a X server running. The current init.d script (in Debian) does not handle that either I think.
So I guess it will not be possible to find a generic solution but let all plugins ship their own service files as needed or document what is needed.
For the core VDR I guess we can assume it is run as a daemon and the above sample service files can be adapted and be included.
Any thoughts?
Thanks,
Paul
[1] http://hg.openbricks.org/openbricks/file/tip/packages/vdr/unit/vdr.service [2] http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/1... [3] http://www.heise.de/open/artikel/Init-Skripte-migrieren-844830.html
Paul Menzel wrote:
[...] and the one shipped by openSUSE [2].
[Unit] Descritpion=VDR After=lirc.service [Service] Type=once ExecStart=/usr/local/bin/runvdr TimeoutSec=0
The reference to /usr/local makes it pretty obvious that this isn't part of any distro.
As the comments in the VDR-Portal thread [2] suggest, it would be great to do without any shell/Bash script and more or less execute plain VDR and let systemd do everything else.
Yes. Not only for better systemd integration but in general it would be better if vdr could work without requiring any external scripting or configuration.
cu Ludwig
Ludwig Nussel wrote:
Yes. Not only for better systemd integration but in general it would be better if vdr could work without requiring any external scripting or configuration.
You need some external script to call VDR as somewhere it is required to configure plugins and plugin parameters and many more stuff, VDR gets via command line options.
Every distribution handles this thing a bit different. For example, I prefer to use "runvdr-extreme" and configure my stuff in the "runvdr.conf" file.
BTW: "systemd" is one of many init systems. I don't know why this system is that special, that it deserves upstream integration. Especially as this would just reflect the defaults of *one* distribution. Another distribution most probably has other ways to configure plugins and settings.
Yours
Manuel
Manuel Reimer wrote:
Ludwig Nussel wrote:
Yes. Not only for better systemd integration but in general it would be better if vdr could work without requiring any external scripting or configuration.
You need some external script to call VDR as somewhere it is required to configure plugins and plugin parameters and many more stuff, VDR gets via command line options.
That's the current state. I can't think of a good reason why it has to stay that way though. VDR itself could have a menu that allows to enable, disable and configure plugins.
cu Ludwig
On Thu, Jun 28, 2012 at 12:01 AM, Ludwig Nussel ludwig.nussel@suse.de wrote:
You need some external script to call VDR as somewhere it is required to configure plugins and plugin parameters and many more stuff, VDR gets via command line options.
That's the current state. I can't think of a good reason why it has to stay that way though. VDR itself could have a menu that allows to enable, disable and configure plugins.
That would be a nice feature -- worth suggesting for the big `after 2.0 is released` redesign(?). But, there may be plugins which need to be initialized with certain values. Although, maybe it's possible to have those be reinitialized within vdr?
On 06/28/2012 08:02 PM, VDR User wrote:
On Thu, Jun 28, 2012 at 12:01 AM, Ludwig Nussel ludwig.nussel@suse.de wrote: That would be a nice feature -- worth suggesting for the big `after 2.0 is released` redesign(?). But, there may be plugins which need to be initialized with certain values. Although, maybe it's possible to have those be reinitialized within vdr?
Yeah, I would like to have option to pass path to plugin config file for vdr-executable. Then somebody could write simple ui app for configuting it via ui based on to plugins it finds from the PLUGINS dir.
In the case of systemd, it's no need to have this vdr has died, unload and load kernel module loop in the runvdr script, as those can be specified also as a pre and post commands in systemd.
Mika
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am 28.06.2012 09:01, schrieb Ludwig Nussel:
Manuel Reimer wrote:
Ludwig Nussel wrote:
Yes. Not only for better systemd integration but in general it would be better if vdr could work without requiring any external scripting or configuration.
You need some external script to call VDR as somewhere it is required to configure plugins and plugin parameters and many more stuff, VDR gets via command line options.
That's the current state. I can't think of a good reason why it has to stay that way though. VDR itself could have a menu that allows to enable, disable and configure plugins.
I can't see a benefit of this approach. At least for distributors it would get more complicated to install plugins with a specific default configuration, because that would mean all configuration informations would go into the setup.conf and it is no good idea to manipulate this file from outside.
I would like to see the first user of this idea to try to disable a plugin that prevents the start of the vdr because of binary incompatibility. Must be funny.
Gerald
Gerald Dachs wrote:
That's the current state. I can't think of a good reason why it has to stay that way though. VDR itself could have a menu that allows to enable, disable and configure plugins.
I can't see a benefit of this approach. At least for distributors it would get more complicated to install plugins with a specific default configuration, because that would mean all configuration informations would go into the setup.conf and it is no good idea to manipulate this file from outside.
Exactly!
Again: systemd ist *one of many* init solutions and I guess, that Klaus doesn't use a distribution with systemd.
IMHO the "systemd people" will have to create some kind of "adapter script" (and maybe just call it "runvdr" ;) ).
"runvdr-extreme" comes with a solution to enable/disable plugins from the VDR GUI. Maybe that would fit as a base for systemd startup.
Yours
Manuel
On 02.07.2012, at 10:39, Manuel Reimer manuel.reimer@gmx.de wrote:
Gerald Dachs wrote:
That's the current state. I can't think of a good reason why it has to stay that way though. VDR itself could have a menu that allows to enable, disable and configure plugins.
I can't see a benefit of this approach. At least for distributors it would get more complicated to install plugins with a specific default configuration, because that would mean all configuration informations would go into the setup.conf and it is no good idea to manipulate this file from outside.
Exactly!
Again: systemd ist *one of many* init solutions and I guess, that Klaus doesn't use a distribution with systemd.
No, I don't.
VDR (and me, too ;-) doesn't care in what way a particular system boots or starts its services. The 'runvdr' script that comes with the VDR source is merely a suggestion of how to create an environment in which VDR can be (re-)started.
Klaus
On 3 July 2012 07:51, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
VDR (and me, too ;-) doesn't care in what way a particular system boots or starts its services.
It would be handy though, if VDR proper came default with a way to toggle plugins on and off in the user interface.
On 3 July 2012 07:51, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
VDR (and me, too ;-) doesn't care in what way a particular system boots or starts its services.
It would be handy though, if VDR proper came default with a way to toggle plugins on and off in the user interface.
It is nice, but as an additional option. But you absolutely need a way to enable/disable/configure plugins from the outside of VDR, in case that a plugin crashes on startup, an output plugin does not output in default configuration, remote is not working, or similar.
runvdr-extreme for example can enable/disable plugins via menu, but you can also do it via a command line tool, or by setting/deleting rc?.d-like symbolic links.
Cheers,
Udo
On 2012-06-27 12:48, Paul Menzel wrote:
looking around for systemd service files I found three examples.
The Fedora one and other related files are at http://pkgs.fedoraproject.org/gitweb/?p=vdr.git;a=tree
-
Gerald Dachs -
Klaus Schmidinger -
Ludwig Nussel -
Manuel Reimer -
Mika Laitio -
Paul Menzel -
Torgeir Veimo -
Udo Richter -
VDR User -
Ville Skyttä