Tvheadend

https://github.com/tvheadend/tvheadend

That’s as specific as it gets.

AFAIK, the latest stable point release is 4.2.8 from 2019. After that, no new point releases made.
If you need the latest version (4.3-xxxx), it probably means the latest commit from the git repo. If you are lucky your distribution provides as a package, if not you need to build from the source code.

Thanks! I always build from source. I was not even aware that there was a 4.2.8 as it is not listed here: https://tvheadend.org/projects/tvheadend/wiki/Releases

I will make a pull over the weekend and see how it goes. I tested 4.3 a while back and had issues, so I will try 4.2.8 first and see and then 4.3

The GitHub is your go to source for the latest commit. I wouldn’t bother with anything in your repo. Chances are it’s way behind anything available in the GitHub. Just pick the commit that works best for you and build it yourself for your own particular platform. That way you get to choose what’s included in your own build.

Yes. That is what I generally do. Create a new folder and:

4.2.8
dalton@tvburk:~/devel/tvh428>

git clone https://github.com/tvheadend/tvheadend.git
cd tvheadend
git checkout tags/v4.2.8

./configure --enable-bundle --disable-dvbscan
make

You have it so. That will give you the latest commit or whatever commit you prefer and will provide you with the most flexibility when building.

Great! FWIW the last build I did, also when I tested 4.3 (unsuccessfully, but reported the issues) was five years ago Time flies.

The issue then was: https://tvheadend.org/issues/4846

That’s why I prepared these simple copy/paste instructions to build on an x84_64 in Ubuntu 22.04. It gives those who are not particularly familiar with the GitHub process to build a current version for their own platform https://tvheadend.org/boards/4/topics/47932

Nice. Perhaps I should write something similar for OpenSuSe

And possibly contribute back to the project as you have the requisite skills to meaningfully edit the source code. Most who log into the forum here just want a working solution they can install.

Other than minor changes to the code as far as I can see very little has been added to project in the last five years.

I use TVH purely for DVBS and it is very complete as far as that side is concerned. I’m sure others may have different needs. So many different platforms available to install TVH on these days so it’s probably easier if users try and build for these platforms individually.

Sure, the thought has crossed my mind over the years. I have been running it since 4.0.x as the main hub for DVB-T2 and DVB-C. I do program for a living and once even tried to get an improvement I made to squid into the main repo, but was voted down I lack the detailed knowledge about the Linux TV stuff, sadly.

For my family, it does meet the needs we have and I like to do my own builds, mainly because I can take out stuff not needed. The fewer bits of code I do not need, the less risk of problems.

I also have the "wife acceptance factor" to consider Too much tinkering might lead to problems, but I have compiled 4.2.8 now and will test over the weekend. If it runs stable for a few days, then I will try 4.3. As I said did I try 4.3 a few years back so my notes on configuring and building should work.

My main problems have always been those tuners. Seemingly identical TV sticks may have different chipsets and/or require different firmwares. I am running 4 sticks right now, two for DVB-T2 and two for DVB-C. I pulled the "Astrometa" one a few days ago as I suspected it caused problems.

I’ve always found Hauppauge hybrid PCI/PCIe cards to be reliable for DVBS/T on Ubuntu. Not too sure about USB tuners though. Driver breakages on kernel upgrades seem to be quite common.

I’m using the latest commit v4.3-2050 on Ubuntu 22.94 lts and it’s rock solid so no complaints there. As you say try it and see.

Never got 4.2.8 to work. It ran, but never got any signal. I will revert to 4.2.4 and try 4.3 instead.

Box is running: Linux tvburk 5.3.18-lp152.63-default #1 SMP Mon Feb 1 17:31:55 UTC 2021 (98caa86) x86_64 x86_64 x86_64 GNU/Linux

( openSUSE Leap 15.2)

in /devel/tvh43:
git clone https://github.com/tvheadend/tvheadend.git

./configure --enable-bundle --disable-dvbscan --disable-hdhomerun_static --disable-libopus
make

Running manually:
...tvh43/tvheadend/build.linux # ./tvheadend -u dalton -g video

HTS Tvheadend 4.3-2058~g5543ce518.

Will leave it as this to check. Oh yes:
2022-11-23 19:51:45.827 [ ERROR] epgdb: corruption detected, some/all data lost

The format has possibly changed, but it did rebuild it.

DVB Inputs now shows adapter status correctly. Ie many adapters are both DVB-C and DVB-T to you need to disable the one you do not need.
Content icons - Cute.

"I’ve always found Hauppauge hybrid PCI/PCIe cards to be reliable"

I might give up on USB and get a Hauppauge QUADHD DVB. Four tuners and apparently supported by LinuxTV. The problem with multiple USB sticks is that they tend to reorder themselves at will

Might be worth looking at the TBS range. A lot of work gone into Linux driver support for both PCI/PCIe and USB range.
https://tbs-technology.de/shop/TV-Tuner-for-PC-internal-/-external

So which one, in your opinion, is better? Prices are similar. The install procedure for the TBS cards seems a bit convoluted? The vendor claim that they support Linux which is a good thing though.

TBS devices are good, however despite being open source drivers linuxtv developers don't pull them into mainline. So every kernel upgrade you have to compile and reinstall the drivers. Either manually or create some automated system.

We use TBS mostly in North America as others like Hauppauge or Digital Devices are difficult to obtain.

As for devices reordering there is normally a module parameter than can be given as an option to force dvb device number.

As Ron says, the problem with TBS is that TBS don't write drivers to the standard required to be mainlined into the kernel. So as he says, every kernel update is a real kerfuffle. I have a DVB-T2 one but I've recently bought the Hauppauge quad tuner board to replace it because of this problem. But installing that requires reconfiguring my hardware and then the possibility of some software SNAFU so I haven't done that yet either

As Jonas said I'm one of those who "just want a working solution they can install" and any change means hassle!

Dave H wrote:

As Ron says, the problem with TBS is that TBS don't write drivers to the standard required to be mainlined into the kernel. So as he says, every kernel update is a real kerfuffle. I have a DVB-T2 one but I've recently bought the Hauppauge quad tuner board to replace it because of this problem. But installing that requires reconfiguring my hardware and then the possibility of some software SNAFU so I haven't done that yet either

As Jonas said I'm one of those who "just want a working solution they can install" and any change means hassle!

Ron didn't say anything about the quality of TBS drivers. TBS devices work fine and the drivers are good. When Bugs are found the TBS developers are very engaging and the bugs get fixed.

I believe both Hauppauge and Digital Devices drivers are also developed in house, but for some reason they are pulled into mainline. It's not about quality of drivers it's about linuxtv politics.

I have one TBS DVB-S2 tuner. It works perfectly and runs in a system that is up 24/7.

I have two other devices that are supported by linuxtv drivers in mainline kernel. Both have buggy drivers that make the device unusable that are developed by someone who sends all bug reports to /dev/null. One still sits on the shelf unusable. The other I found a patch that fixes the device but was refused by mainline linuxtv. I've been patching that device myself for 10 years or more now as did everyone else I knew who owned one. Last time I tested unpatched mainline driver it now actually locks my machine up tight requiring a push of the reset button. Because I have both this device and TBS device I brought up the issue with TBSDTV opensource. Crazycat applied 10 year old patch finally fixing the device.

When I read someone say TBS drivers are not up to the standard required to be in mainline kernel I laugh out loud at you. TBS drivers are a pain to install because mainline won't pull them, but if you want a device that otherwise has excellent Linux support and has developers that actually read bug reports and actually work with you to fix bugs then TBS is probably the best choice.

Thanks all. I will see what I do. I also noted that I apparently have a regression in my SI 2168 driver. With the old kernel I had to build it myself, but after the update it occasionally seems to load the wrong FW. Need to investigate.

Was mucking around with the tuners yesterday and my knee hit the UPS off button which resulted in a lengthy RAID rebild

I need to revisit this when I am rested.

I also noted that many USB tuners fail to work when not connected directly to the USB port or hub, but via a 100mm pigtail, as you have to do to cram in multiple tuners.

I created a separate thread about the TBS-6281 SE tuner