Arch Linux User Repository

Warning: if you have previously used this package, you need to reinstall! Sorry for introducing breaking changes, but hopefully the introduced changes will provide a better experience for most users. :)

Backup your configs (if needed) before performing the upgrade!

Changes:

• TVHeadend will be installed to /var/lib/tvheadend instead of /usr/share/tvheadend
• Package will create the system user tvheadend (member of group video) with config files stored in /etc/tvheadend, it will not use a home directory anymore.
• By using sysusers.d and tmpfiles.d permissions should be easier to manage.
• tvheadend.service now includes -C by default.
• Added some missing deps

If you have any questions or suggestions, please let me know. :)

I started up a wiki page for Tvheadend. Input and help is welcome.

https://wiki.archlinux.org/index.php/Tvheadend

Is there a way to migrate my current settings (from previous version)? Please provide details, thank you.

@cgirard How do you build with a clean chroot? Are you using any AUR helper?

@bedouin I don't think ffmpeg-headless works as it's missing deps, could you try ffmpeg.4.4 instead?

I'm using ffmpeg-headless (https://aur.archlinux.org/packages/ffmpeg-headless) instead of ffmpeg4.4, so makepkg fails with missing dependencies. Does tvheadend not compile with the latest ffmpeg (headless is still on 4.4)?

@francoism90 yes it does, but only on a live system were a previous version of tvheadend-git is already installed. It is still failing for me in a clean chroot but I cannot explain why either.

It seems to compile now using the patch from @Wild_Penguin. :)

apologies @wild_penguin -- i did not have the ffmpeg4.4 installed. once installed, i manually changed the configure file and package built correctly use makepkg -o, making change and then makepkg -e. thank you.

@cgirard,

Only thing I can think of is that the package could be missing some dependencies. Does it build if you don't build inside a chroot?

I'm not the maintainer of this package nor tvheadend. However it does compile with current ffmpeg4.4 here. Just to make sure you have made all changes correctly, here is the complete patch with the changes I'm using currently (note whitespace might not be preserved, so you might need to apply some parts by hand and update the checksums - I noticed there is at least one trailing space in the ffmpeg4.4 moving patch):

diff --git a/PKGBUILD b/PKGBUILD
index 66b3c8c..559bdcb 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -4,7 +4,7 @@

 _gitname='tvheadend-git'
 pkgname=tvheadend-git
-pkgver=4.3.r1947.gdbaa0f850
+pkgver=4.3.r2009.g1295dd2be
 pkgrel=1
 pkgdesc="TV streaming server for Linux"
 arch=('i686' 'x86_64' 'arm' 'armv6h' 'armv7h' 'aarch64')
@@ -44,17 +44,26 @@ source=(
   tvheadend.service
   tmpfile.conf
   user.conf
+  configffmpeg.patch
 )
 sha512sums=('SKIP'
             'd29662ee47f2d0da98d444819f730a8c487999454d60d7397b0f67068300ab5111ffce18befc9fdef5ff8fa1925213716837ea44808fb934197e4a56f98de8a7'
             '1080c8a2530d1f16ab5304cdd81c9c9da23b281e44a4874f4921905c843d876831214af481f9be91a74291ed4a6a10684dbdfb8f926b51bbb6895b92d493b201'
-            '5e0475cfe1f915bd3269ba3e9e0ca6cc7e492988bfd4f1feafcbbd3e8b0276c228f0b08a4116f3213d12c0ea940eff0dc71601a6e6ddcda934964cf51a665539')
+            '5e0475cfe1f915bd3269ba3e9e0ca6cc7e492988bfd4f1feafcbbd3e8b0276c228f0b08a4116f3213d12c0ea940eff0dc71601a6e6ddcda934964cf51a665539'
+            'ff61d594db210fc8413edd900fc9e01705a01a35ac0c225b2bb3bdf5beca088b13c021ade08d61dee58ff2e5a8e73fc8eb042033ccdd55f3a8573f64e5eec6d4')

 pkgver() {
   cd "${srcdir}/${_gitname}"
   git describe --long | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g'
 }

+prepare() {
+  # cd "$pkgname-$pkgver"
+  cd "${srcdir}/${_gitname}"
+  patch --forward --input="${srcdir}/configffmpeg.patch"
+
+}
+
 build() {
   cd "${srcdir}/${_gitname}"

diff --git a/configffmpeg.patch b/configffmpeg.patch
new file mode 100644
index 0000000..03c2b14
--- /dev/null
+++ b/configffmpeg.patch
@@ -0,0 +1,10 @@
+--- configure.old      2022-02-21 01:18:56.172209777 +0200
++++ configure  2022-02-21 01:19:37.482835172 +0200
+@@ -639,6 +639,7 @@
+   if enabled_or_auto libav; then
+     has_libav=true
+     has_resample=false
++      export PKG_CONFIG_PATH=/usr/lib/ffmpeg4.4/pkgconfig/
+ 
+     check_pkg libavfilter   ">=6.47.100"  || has_libav=false
+     check_pkg libswresample ">=2.1.100"   && has_resample=true

@Wild_Penguin: even with the patch (and the dep switch from ffmpeg to ffmpeg4.4) build fails for me in a clean chroot. It goes a little further but fails on the linking phase with errors like this:

src/transcoding/codec/codec.c:66:17: error: type of _tvh_codec_vaapi_vp9_ does not match original declaration [-Werror=lto-type-mismatch] 
   66 | extern TVHCodec tvh_codec_vaapi_vp9; 
      |                 ^                           
src/transcoding/codec/codecs/libs/vaapi.c:351:15: note: type _struct TVHVideoCodec_ should match type _struct TVHCodec_ 
  351 | TVHVideoCodec tvh_codec_vaapi_vp9 = {           
      |               ^                                     
src/transcoding/codec/codecs/libs/vaapi.c:351:15: note: _tvh_codec_vaapi_vp9_ was previously declared here  
src/transcoding/codec/codecs/libs/vaapi.c:351:15: note: code may be misoptimized unless _-fno-strict-aliasing_ is used 

Any idea?

Indeed there is no /usr/include/ffmpeg4.4 if only ffmpeg is installed, but note that there is another package named ffmpeg4.4 in extra (to which I linked previously, trying to make the point clear).

Indeed using static ffmpeg also works, but I believe most distributions don't recommend using static libraries and I believe I understand why (but, this being AUR, I don't think it really matters what users do or what is in the PKGBUILD)...

I don't know the people behind tvheadend (and programming only superficially), but the fact being their build system uses static libraries per default, is probably exactly because they don't want to be updating the code base to support the latest stuff. As such I don't believe any plans to use ffmpeg5 are yet there - but I could be totally wrong. What you (/we) could do is make an issue on the upstream git.