Tvheadend

I've been investigating this further. I'm not a linux expert so this might be stupid, but is it normal to have 2 pids for tvheadend?

I see
Apr 11 14:14:12 raspberrypi tvheadend⁹³⁰: main: Log started
Apr 11 14:14:12 raspberrypi tvheadend⁹³⁰: http: Starting HTTP server 0.0.0.0:9981
Apr 11 14:14:12 raspberrypi tvheadend⁹³⁰: htsp: Starting HTSP server 0.0.0.0:9982
Apr 11 14:14:12 raspberrypi tvheadend⁶²¹: Starting Tvheadend: tvheadend.
Apr 11 14:14:12 raspberrypi systemd¹: Started tvheadend.service.

and

Apr 11 14:14:13 raspberrypi tvheadend¹¹²⁵: main: Log started
Apr 11 14:14:13 raspberrypi tvheadend¹¹²⁵: tcp: bind: *:9981: Adres is al in gebruik
Apr 11 14:14:13 raspberrypi tvheadend¹¹²⁵: tcp: bind: *:9982: Adres is al in gebruik
Apr 11 14:14:13 raspberrypi tvheadend¹¹²⁵: config: loaded
Apr 11 14:14:13 raspberrypi tvheadend¹¹²⁵: config: scanfile (re)initialization with path <none>
Apr 11 14:14:13 raspberrypi tvheadend³⁹⁴: Starting Tvheadend: tvheadend

That's why when recording, both processes try to record:
Apr 12 20:18:30 raspberrypi tvheadend⁹³⁰: dvr: "Ontvoerd" on "RTL 5 HD" recorder starting
Apr 12 20:18:30 raspberrypi tvheadend¹¹²⁵: dvr: "Ontvoerd" on "RTL 5 HD" recorder starting
Apr 12 20:18:30 raspberrypi tvheadend⁹³⁰: dvr: About to set stop timer for "Ontvoerd" on "RTL 5 HD" at start 1618252140 and original stop 1618255800 and overall stop at 1618257600
Apr 12 20:18:30 raspberrypi tvheadend⁹³⁰: mpegts: 458MHz in Ziggo - tuning on HDHomeRun DVB-C Tuner #0 (192.168.2.5)
Apr 12 20:18:30 raspberrypi tvheadend⁹³⁰: tvhdhomerun: tuning to a8qam256-6900:458000000
Apr 12 20:18:30 raspberrypi tvheadend¹¹²⁵: dvr: About to set stop timer for "Ontvoerd" on "RTL 5 HD" at start 1618252140 and original stop 1618255800 and overall stop at 1618257600
Apr 12 20:18:30 raspberrypi tvheadend¹¹²⁵: mpegts: 458MHz in Ziggo - tuning on HDHomeRun DVB-C Tuner #0 (192.168.2.5)
Apr 12 20:18:30 raspberrypi tvheadend¹¹²⁵: tvhdhomerun: tuning to a8qam256-6900:458000000
Apr 12 20:18:30 raspberrypi tvheadend¹¹²⁵: tvhdhomerun: failed to acquire lockkey: ERROR: resource locked by 192.168.2.9

I just don't understand why they would both try to use Tuner #0 causing the issue.

And if so, might this be the cause of both issues, happening right after reboot:
Apr 11 14:14:10 raspberrypi systemd¹: tvheadend.service: Found left-over process 508 (tvheadend) in control group while starting unit. Ignoring.
Apr 11 14:14:10 raspberrypi systemd¹: This usually indicates unclean termination of a previous run, or service implementation deficiencies?

I guess this is a systemd shortcoming.
Added to my list of things to check with logcheck.

The resource locked error occurs when more than one application is trying to use the same HDHomeRun tuner. Lets say you have HDHR with 2 tuners and have tvheadend setup to use both. Then someone decides to use an HDHR app to also use the tuner. When tvheadend needs both tuners, you will get the error. It looks like you have connections to your tuner from IP 192.168.2.9 and 192.168.2.5. Sound like something you should be able to debug and find out who or what is using the tuners. Unless you have two IPs on one system, it has nothing to do with tvheadend. Find out where the IPs are and that will be your starting point.

Also note that you can hit the HDHR webpage on your tuner and take a look at your tuners to see if they are in use or not and who is currently using them.

Good luck.

Hi G,

Thanks for the response. But 192.168.2.5 is the HDHR and 192.168.2.9 is the RPI on which TVH is connecting to the HDHR.
In the logs I see 2 instances of TVH recording the same program on the same tuner. That's why the lock error occurred.
Seems like after a reboot TVH hasn't shut down properly. Systemd is not able to deal with that properly, so 2 TVH runned twice.

Wim

I believe I know what is going on. First, let us just agree that you do not have two instances of tvheadend running. It is very hard to set it up and run on different ports, so just for me, let us start with that assumption. Next, I have written many HDHR simulators and understand how they work. The error message "ERROR: resource locked by 192.168.2.9" indicates that IP 9 has the tuner requested locked and that is your RPI. This does indicate that you are defeating yourself and the same device has all the tuners locked. This error message also occurs when using the UDP protocol on HDHR instead of the TCP protocol. In layman terms, you are using the TV adapters tab on tvheadend to the HDHR device know as a dvb interface. Now for some bad news. I found that the dvb interface can forget to unlock the tuner when the channel stops playing. I have reviewed using the DVB interface versus the IPTV interface and found that dvb does provide some nice features like signal quality, but also has a tendency to close the channel, but not unlock it. This leads to only one conclusion. The dvb interface should not be used and the recommendation is to use the IPTV interface.

Now for the hard part. You will need to clear out the mux list, remove the network and start a new network using IPTV Automatic. It can be easy to use, but will need a M3U file to start. HDHR tuners do not provide M3U files directly, but a python script will take the data from your tuner and create one. I have attached the python script I use. You will need to edit the file and change the HDHR-xxxxxxxx to your tuner address. Run and pipe the output to a file (python ./hdhr-listing-to-m3u.py > HD.m3u) and you will have a m3u file of your tuner. Create a network and enter the file path to your m3u file. Run a force scan to generate the muxes. It should then gen the services.

Hi G,

I really appreciate you hanging in there but could you please have a look at the attachment? I'm a linux newbie, but I really do think there were 2 instances of tvheadend running.

Wim