Arch Linux User Repository

Still works for me. Did you patch VDR recently? This error usually happens if a plugin was not built with the right VDR version.

Plugin is broken:

# systemctl status --no-page -l vdr.service
× vdr.service - Video Disk Recorder
     Loaded: loaded (/usr/lib/systemd/system/vdr.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sat 2022-04-30 07:17:53 CEST; 1min 46s ago
    Process: 36259 ExecStart=/usr/bin/vdr (code=exited, status=2)
   Main PID: 36259 (code=exited, status=2)
     Status: "Startup failed, exiting"
        CPU: 28ms

Apr 30 07:17:53 vdr vdr[36259]: [36259] loading plugin: /usr/lib/vdr/plugins/libvdr-streamdev-server.so.2.6.1
Apr 30 07:17:53 vdr vdr[36259]: [36259] loading plugin: /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.6.1
Apr 30 07:17:53 vdr vdr[36259]: [36259] ERROR: /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.6.1: undefined symbol: _ZN6cTimerC1EPK6cEvent
Apr 30 07:17:53 vdr vdr[36259]: vdr: /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.6.1: undefined symbol: _ZN6cTimerC1EPK6cEvent
Apr 30 07:17:53 vdr vdr[36259]: [36259] deleting plugin: streamdev-server
Apr 30 07:17:53 vdr vdr[36259]: [36259] deleting plugin: satip
Apr 30 07:17:53 vdr vdr[36259]: [36259] exiting, exit code 2
Apr 30 07:17:53 vdr systemd[1]: vdr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 30 07:17:53 vdr systemd[1]: vdr.service: Failed with result 'exit-code'.
Apr 30 07:17:53 vdr systemd[1]: Failed to start Video Disk Recorder.
[root@vdr vdr-vnsiserver]# ldd /usr/lib/vdr/plugins/libvdr-vnsiserver.so.2.6.1
    linux-vdso.so.1 (0x00007ffe58d63000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f9684911000)
    libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f96848f6000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f96846ec000)
    libm.so.6 => /usr/lib/libm.so.6 (0x00007f9684604000)
    /usr/lib64/ld-linux-x86-64.so.2 (0x00007f9684bd7000)

Thanks for clarifying this. Then there's no need to change. Guess I will have to write down all installed plugins, uninstall them, upgrade vdr and then rebuild and install the plugins. I use yay to handle AUR packages. AFAIK yay handles multiple AUR packages one by one, e.g. build/install PKG1 then PKG2 then PKG3 and so on. It complained during vdr upgrade, that vdr-vnsiserver and vdr-ddci2 would break and cancelled installation (and vice versa).

If VDR is written in such a fail-safe yet user-unfriendly way then I'll have to deal with it.

There is a reason behind this, why it is done exactly this way.

The resulting package is meant to be built with the exact VDR-API version built in to be sure that installing a new VDR version which conflicts with existing plugins causes pacman to throw an error.

If you build a plugin against VDR 2.4.1, then it will only work with this version. It will not work with any lower version.

VDR 2.4.1 is what is provided here on AUR and also on our "binary repository": https://github.com/VDR4Arch/vdr4arch So that's what this plugin PKGBUILD is made to build for.

Nothing will change while upgrading packages and if the AUR helper, you use, is made well, it will actually build VDR first and then all plugins after that.

I any way you have to rebuild all plugins as for example VDR 2.4.1 will not even try to load plugin that was built against VDR 2.2.0. The API version number is coded into the plugin and VDR will refuse to load old plugins as the API used to interface to plugins changes between VDR versions in incomptabile ways.

Please stop using exact versions for vdr-api. Exact version checks make package upgras a nightmare. This plugin requires vdr 2.2.0 or newer, so please do it like this:

line 07: _vdrapi=2.2.0

line 14: depends=('gcc-libs' "vdr-api>=${_vdrapi}")