VDR failing again ...

12 views
Skip to first unread message

Rudi

unread,
Apr 15, 2013, 4:09:42 AM4/15/13
to openbric...@googlegroups.com
Hi Tom,

with the recent build I noticed that the VDR service is failing again at startup. The
reason for this seems to be that vdr-plugin-vnsiserver (built as part of
xbmc-pvr-addons) is incompatible with our version of vdr. Currently, the shared object
even has a name different from what is expected by vdr.

BTW, do we need VDR at all ?


--

Ruediger "Rudi" Ihle


Thomas Genty

unread,
Apr 15, 2013, 9:38:45 AM4/15/13
to openbric...@googlegroups.com
Le 15/04/2013 10:09, Rudi a �crit :
> Hi Tom,
Hello Rudi,
> with the recent build I noticed that the VDR service is failing again at startup. The
> reason for this seems to be that vdr-plugin-vnsiserver (built as part of
> xbmc-pvr-addons) is incompatible with our version of vdr. Currently, the shared object
> even has a name different from what is expected by vdr.
Not really the problem, i have updated more vdr* package and can by-pass
this but vdr segfaults on startup even without plugins.
>
> BTW, do we need VDR at all ?
Not me. I use only tvheadend.
>
>
Tom

Rudi

unread,
Apr 15, 2013, 10:43:49 AM4/15/13
to openbric...@googlegroups.com
Hi,

>> BTW, do we need VDR at all ?
> Not me. I use only tvheadend.

Correct me if I'm wrong, but from my understanding the "vdr" package is the server side
of a TV streaming/recording solution. Thus, "vdr" would only be needed if someone wants
to run a TV server on the same machine on which Geexbox/XBMC runs. In this case a -
probably USB-attached - TV receiver would be "owned" by vdr and controlled from XBMC via
a localhost connection. To be able to do so, "xbmc-pvr-addons" contains both, a client
addon (for XBMC) and a server plugin (for VDR). The latter is the one that fails and the
more I look at it the more I think that this could be a build config issue...

The other thing is: At the moment we unconditionally start an instance of vdr at bootup.
Even though most users will not need it and it's most likely not configured correctly.
Somehow I don't like this approach ;-).

You said that you use tvheadend. Does this work the same way as vdr or does it require
the receiver to be located in another computer on the network ?



--

Ruediger "Rudi" Ihle


Thomas Genty

unread,
Apr 15, 2013, 12:35:28 PM4/15/13
to openbric...@googlegroups.com
Le 15/04/2013 16:43, Rudi a �crit :
> Hi,
>
>>> BTW, do we need VDR at all ?
>> Not me. I use only tvheadend.
> Correct me if I'm wrong, but from my understanding the "vdr" package is the server side
> of a TV streaming/recording solution. Thus, "vdr" would only be needed if someone wants
> to run a TV server on the same machine on which Geexbox/XBMC runs.
True
> In this case a -
> probably USB-attached - TV receiver would be "owned" by vdr and controlled from XBMC via
> a localhost connection. To be able to do so, "xbmc-pvr-addons" contains both, a client
> addon (for XBMC) and a server plugin (for VDR). The latter is the one that fails and the
> more I look at it the more I think that this could be a build config issue...
xbmc-addon-xvdr is for the client and vdr-plugin-xvdr for the server
xbmc-pvr-addons contains others pvr client for xbmc
No, creating a symlink , it works (with a more recent versions of plugins)
but vdr segfaults later, note that with previous version, it works fine
(client and server). Right now the problem is with vdr himself, maybe
there is a problem with the dynamite patch.
>
> The other thing is: At the moment we unconditionally start an instance of vdr at bootup.
> Even though most users will not need it and it's most likely not configured correctly.
> Somehow I don't like this approach ;-).
yes, to configure it, you should use wscan to generate a working config
file or use wirbelscan from xvdr-addons, but I have never tested this one.
Same problem with tvheadend server, you must configure it.
>
> You said that you use tvheadend. Does this work the same way as vdr or does it require
> the receiver to be located in another computer on the network ?
Both can be used without a server hosted on geexbox , that's the way I
use tvheadend,
from a remote server. and it works fine from me since 3.0
I have successfully tested it under cubox and panda (devel) too using my
own tvheadend server
Cheers

Tom

Milan Babel

unread,
Apr 15, 2013, 2:57:55 PM4/15/13
to openbric...@googlegroups.com, openbric...@googlegroups.com
Hi,

As active vdr user i would like to contribute something.

Am 15.04.2013 um 18:35 schrieb Thomas Genty <toml...@gmail.com>:

> Le 15/04/2013 16:43, Rudi a écrit :
>> Hi,
>>
>>>> BTW, do we need VDR at all ?
>>> Not me. I use only tvheadend.
>> Correct me if I'm wrong, but from my understanding the "vdr" package is the server side
>> of a TV streaming/recording solution. Thus, "vdr" would only be needed if someone wants
>> to run a TV server on the same machine on which Geexbox/XBMC runs.
> True
Partly true. You can also use a vdr as a kind of proxy.
>> In this case a -
>> probably USB-attached - TV receiver would be "owned" by vdr and controlled from XBMC via
>> a localhost connection.
Not in everycase, vdr supports vdr to vdr streaming. In my case I've hacked an old dvb-t mips settobbox not able to run anything newer than 1.6. This does not work with current xvdr clients.
>> To be able to do so, "xbmc-pvr-addons" contains both, a client
>> addon (for XBMC) and a server plugin (for VDR). The latter is the one that fails and the
>> more I look at it the more I think that this could be a build config issue...
> xbmc-addon-xvdr is for the client and vdr-plugin-xvdr for the server
> xbmc-pvr-addons contains others pvr client for xbmc
> No, creating a symlink , it works (with a more recent versions of plugins)
> but vdr segfaults later, note that with previous version, it works fine
> (client and server). Right now the problem is with vdr himself, maybe there is a problem with the dynamite patch.
>>
>> The other thing is: At the moment we unconditionally start an instance of vdr at bootup.
>> Even though most users will not need it and it's most likely not configured correctly.
>> Somehow I don't like this approach ;-).
> yes, to configure it, you should use wscan to generate a working config file or use wirbelscan from xvdr-addons, but I have never tested this one.
No if you only do vdr to vdr streaming.
But you need to configure this anyway.
If you need to configure it anyway we could also disable vdr by default, as well as the tvheadend server?
> Same problem with tvheadend server, you must configure it.
>>
>> You said that you use tvheadend. Does this work the same way as vdr or does it require
>> the receiver to be located in another computer on the network ?
> Both can be used without a server hosted on geexbox , that's the way I use tvheadend,
> from a remote server. and it works fine from me since 3.0
> I have successfully tested it under cubox and panda (devel) too using my own tvheadend server
> Cheers
>
> Tom

Regards,
Milan

Rudi

unread,
Apr 15, 2013, 3:24:48 PM4/15/13
to openbric...@googlegroups.com
On 15.04.2013 18:35, Thomas Genty wrote:

>> probably USB-attached - TV receiver would be "owned" by vdr and controlled from XBMC via
>> a localhost connection. To be able to do so, "xbmc-pvr-addons" contains both, a client
>> addon (for XBMC) and a server plugin (for VDR). The latter is the one that fails and the
>> more I look at it the more I think that this could be a build config issue...
> xbmc-addon-xvdr is for the client and vdr-plugin-xvdr for the server
> xbmc-pvr-addons contains others pvr client for xbmc

It appears that there are two sets of plugins can be used to connect XBMC and VDR:
xvdr and vnsi.

The last one is part of the xbmc-pvr-addons package found here:
https://github.com/opdenkamp/xbmc-pvr-addons/tree/master/addons/pvr.vdr.vnsi

while the first one is standalone:
https://github.com/pipelka/xbmc-addon-xvdr
https://github.com/pipelka/vdr-plugin-xvdr

No idea about advantages/disadvantages of these two and why they exist at all.


The version of xvdr we currently have in the repo (0.9.6+) is most likely too old for the
version of vdr (1.7.39).

vnsiserver has been renamed to vnsiserver3 in a recent update. Maybe to avoid a version
conflict as well.


vdr crashes here right after start. Probably triggered by a missing configuration.

I would vote for disabling vdr at boot...




--

Ruediger "Rudi" Ihle


Rudi

unread,
Apr 16, 2013, 2:44:58 AM4/16/13
to openbric...@googlegroups.com
Hi,

> Partly true. You can also use a vdr as a kind of proxy.
> ...
> In my case I've hacked an old dvb-t mips settobbox not able to run
> anything newer than 1.6. This does not work with current xvdr clients.

So you are streaming VDR1 -> VDR2 -> XBMC ? Weird ;-)


> If you need to configure it anyway we could also disable vdr by
> default, as well as the tvheadend server?

Before starting these servers, systemd is instructed to check for the
existence of /run/geexbox/pvr/vdr and /run/geexbox/pvr/tvheadend,
respectively. On the first run from a fresh SD card /run/geexbox/pvr/vdr
does not exist and vdr is not started. However, someone (not yet figured
out who) creates this file later so that it is present on the second boot
of this installation. Then we see, that systemd tries hard (6 times) to
launch vdr before it finally gives up with an error message.


The question is now: Is the /run/geexbox/pvr/xxx mechanism the intended
way to disable the start of these server or is there to delay the startup
of the servers until some other event in the system has acooured ?

Maybe we could use systemd's mask feature to deactivate these units by
default ?



--

Ruediger "Rudi" Ihle


Thomas Genty

unread,
Apr 16, 2013, 3:00:01 AM4/16/13
to openbric...@googlegroups.com
Le 16/04/2013 08:44, Rudi a �crit :
> Hi,
Hello,
>> Partly true. You can also use a vdr as a kind of proxy.
>> ...
>> In my case I've hacked an old dvb-t mips settobbox not able to run
>> anything newer than 1.6. This does not work with current xvdr clients.
> So you are streaming VDR1 -> VDR2 -> XBMC ? Weird ;-)
>
>
>> If you need to configure it anyway we could also disable vdr by
>> default, as well as the tvheadend server?
> Before starting these servers, systemd is instructed to check for the
> existence of /run/geexbox/pvr/vdr and /run/geexbox/pvr/tvheadend,
> respectively. On the first run from a fresh SD card /run/geexbox/pvr/vdr
> does not exist and vdr is not started.
funny, same case for me but it's started on first boot on i386
> However, someone (not yet figured
> out who) creates this file later so that it is present on the second boot
> of this installation. Then we see, that systemd tries hard (6 times) to
> launch vdr before it finally gives up with an error message.
pvr.service ?

Unit]
Description=pvr backend

[Service]
Type=oneshot
EnvironmentFile=/etc/pvr.conf
ExecStartPre=/bin/mkdir -p /run/geexbox/pvr
ExecStart=/bin/touch /run/geexbox/pvr/${BACKEND}
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

in /etc/pvr.conf, comment or change value of BACKEND, then no server is
started.

Rudi

unread,
Apr 16, 2013, 3:14:52 AM4/16/13
to openbric...@googlegroups.com
Am 16.04.2013 09:00, schrieb Thomas Genty:

> funny, same case for me but it's started on first boot on i386

Maybe my statement was incorrect. I have to check again tonight...


> pvr.service ?

Ahhh ! Now I see !


> in /etc/pvr.conf, comment or change value of BACKEND, then no server is started.

Then we might want to do this by default.



--

Ruediger "Rudi" Ihle


Thomas Genty

unread,
Apr 16, 2013, 3:40:09 AM4/16/13
to openbric...@googlegroups.com
Le 16/04/2013 09:14, Rudi a �crit :
done
Reply all
Reply to author
Forward
0 new messages