Tvheadend

https://tvheadend.org/projects/tvheadend/wiki/Debugging#Dead-or-Live-Lock

Does that still apply if all other parts of Tvheadend are still working fine? HTSP Clients are still able to connect and the Webinterface is also working fine.

Each subsystems have own locks, so only SAT>IP server may be affected.

Compile/use tvh binary with debug symbols...

Looks like the gdb is the same, at least to me. I did under debian apt install tvheadend-dbg and restartet tvheadend afterwards.

Now it's not even starting anymore. I receive the following StackTrace:

Jul 27 23:07:58 TV tvheadend²⁷²⁹²: CRASH: Signal: 11 in PRG: /usr/bin/tvheadend (4.2.3-19~g490b6f2) [78b52fc7474ceb249133a0b531bc871be9a2416e] CWD: /
Jul 27 23:07:58 TV tvheadend²⁷²⁹²: CRASH: Fault address 0x7f7d0000004a (Address not mapped)
Jul 27 23:07:58 TV tvheadend²⁷²⁹²: CRASH: Loaded libraries: /usr/lib/libdvben50221.so /usr/lib/libdvbapi.so /usr/lib/libucsi.so /lib/x86_64-linux-gnu/libssl.so.1.0.0 /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 /lib/x86_64-linux-gnu/libz.so.1 /usr/lib/x86_64-linux-gnu/liburiparser.so.1 /usr/lib/x86_64-linux-gnu/libavahi-common.so.3 /usr/lib/x86_64-linux-gnu/libavahi-client.so.3 /lib/x86_64-linux-gnu/libdbus-1.so.3 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libpthread.so.0 /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/librt.so.1 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libsystemd.so.0 /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/x86_64-linux-gnu/libselinux.so.1 /lib/x86_64-linux-gnu/liblzma.so.5 /usr/lib/x86_64-linux-gnu/liblz4.so.1 /lib/x86_64-linux-gnu/libgcrypt.so.20 /lib/x86_64-linux-gnu/libpcre.so.3 /lib/x86_64-linux-gnu/libgpg-error.so.0 /lib/x86_64-linux-gnu/libnss_compat.so.2 /lib/x86_64-linux-gnu/libnsl.so.1 /lib/x86_64-linux-gnu/libnss_nis.s
Jul 27 23:07:58 TV tvheadend²⁷²⁹²: CRASH: Register dump [23]: 000000000000001e00007f7df4015e6000007f7df4000078000000000000000100007f7df402b8e820c49ba5e353f7cf00007f7dec00335000007f7e0e1f3700000000000000007800007f7df4015ed800007f7df401446000007f7dc800186000007f7df4015ed800007f7d00000002000000000000001e00007f7e0e1f292000005626b0157f800000000000010202002b0000000000330000000000000004000000000000000efffffffe7ffbba1100007f7d0000004a
Jul 27 23:07:58 TV tvheadend²⁷²⁹²: CRASH: STACKTRACE
Jul 27 23:07:59 TV tvheadend²⁷²⁹²: CRASH: /project/repo/checkout/src/trap.c:148 0x5626b00afe3d 0x5626afeb4000
Jul 27 23:07:59 TV tvheadend²⁷²⁹²: CRASH: ??:0 0x7f7e20544670 0x7f7e20533000
Jul 27 23:07:59 TV tvheadend²⁷²⁹²: CRASH: /project/repo/checkout/src/input/mpegts/satip/satip_frontend.c:698 0x5626b0157f80 0x5626afeb4000
Jul 27 23:07:59 TV tvheadend²⁷²⁹²: CRASH: /project/repo/checkout/src/input/mpegts/mpegts_mux.c:910 0x5626b0124609 0x5626afeb4000
Jul 27 23:08:00 TV tvheadend²⁷²⁹²: CRASH: /project/repo/checkout/src/main.c:634 (discriminator 3) 0x5626b006b24d 0x5626afeb4000
Jul 27 23:08:00 TV tvheadend²⁷²⁹²: CRASH: /project/repo/checkout/src/wrappers.c:159 0x5626b0076155 0x5626afeb4000
Jul 27 23:08:00 TV tvheadend²⁷²⁹²: CRASH: ??:0 0x7f7e2053a6da 0x7f7e20533000
Jul 27 23:08:00 TV tvheadend²⁷²⁹²: CRASH: clone+0x5f (/lib/x86_64-linux-gnu/libc.so.6)
Jul 27 23:08:00 TV kernel: [4262170.222701] tvh:mtimer²⁷³⁷⁵: segfault at 7f7d0000004a ip 00005626b0157f80 sp 00007f7e0e1f2920 error 4 in tvheadend[5626afeb4000+11a6000]

Uninstalled dbg and reinstalled normal version --> no problems with above mentioned Problem.

It looks like a memory corruption then: https://tvheadend.org/projects/tvheadend/wiki/Debugging#Memory-leaks-or-corruption

The issue is probably with UPNP. Turning off the TV Power completely and turning it back on fixes it. Restarting the TVHeadend Server fixes it aswell. Is there a kind of "initial broadcast" that we can send periodically (interval configurable in settings) so even broken clients like this TV can work?

Flole Systems wrote:

The issue is probably with UPNP. Turning off the TV Power completely and turning it back on fixes it. Restarting the TVHeadend Server fixes it aswell. Is there a kind of "initial broadcast" that we can send periodically (interval configurable in settings) so even broken clients like this TV can work?

Hi,

SSDP is a pain several times. The autodiscovering based on this protocol has several limiations. For example, your network infrastructure can be the origin of your problem, as it's based on multicast.

I suggest you enable trace log of UPNP (SATIPS) in TVH and try to debug if the server inside the TVH has some trouble. For trigger SSDP messages from the TVH is quite simple: boot any Windows machine. When it boots it asks to all devices in the network for identify. Another option is to start the free SATIP DVDViewer client.

Please, do it more tests. I feel the problem is in your physical network.

Using DVBViewer it doesn't find TVHeadend. I have done more investigation including a packet capture on the TVHeadend host. It receives the M-SEARCH request and several other services are responding. An Option to periodically send the Announce would fix this. It seems like the other software is causing issues, unfortunately it's closed source and can not be modified. It seems like TVHeadend doesn't get the t and therefor won't answer it. Periodically calling static void
satips_upnp_send_announce(void)
would fix this as then the announce would be sent without receiving the request. This would also solve problems with people in "broken" networks.

Just to confirm: If you enable traces (--trace upnp), you don't see the M-SEARCH packet in the tvh's log file?

Flole Systems wrote:

Using DVBViewer it doesn't find TVHeadend.

Add manually ip it work tested

Manual IP works. I have written a small python script that periodically broadcasts the notify now. So far no issues with that. I have moved Tvheadend behind a firewall today, I will try tomorrow if i have time whether Tvheadend gets the search or not.

Flole Systems wrote:

Manual IP works. I have written a small python script that periodically broadcasts the notify now. So far no issues with that. I have moved Tvheadend behind a firewall today, I will try tomorrow if i have time whether Tvheadend gets the search or not.

Behing a firewall? If the TVH is behind a firewall, then you can't broadcast the SSDP messages! You need to open then the multicast traffic.

As I commented: SSDP is a pain in complex networks and networks without multicast support!

I have done that yesterday, before that it was on the same network.

Whatever this was, it is fixed now. This can be closed.