Bug #4445

Sat-IP Server stops working after some time

Added by Flole Systems 2 months ago. Updated 11 days ago.

Status:NewStart date:2017-06-19
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Found in version:4.2.2-49 Affected Versions:

Description

I am using a Panasonic TV as a SAT IP Client for the integrated server. After some time (like a day) when i turn on the TV, I get a server unavailable message. A restart of Tvheadend seems to fix it. Port 554 is still open, i can telnet into it. In the logs there are no information about a tuner trying to tune to the requested channel. In fact the connection attempt causes no log messages.

gdb.txt Magnifier (47.3 KB) Flole Systems, 2017-07-13 20:14

gdb.txt Magnifier (47.9 KB) Flole Systems, 2017-07-27 23:05

History

#2 Updated by Flole Systems 2 months ago

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.

#3 Updated by Jaroslav Kysela 2 months ago

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

#4 Updated by Flole Systems about 1 month ago

Attached is a "thread apply all bt full" of a hung Sat-IP Server. The TV reports "Server unavailable". After a restart it is working without any issues again.

#5 Updated by Jaroslav Kysela 24 days ago

Compile/use tvh binary with debug symbols...

#6 Updated by Flole Systems 23 days ago

This should be with debug symbols.

#7 Updated by Flole Systems 23 days ago

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

#8 Updated by Flole Systems 23 days ago

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

Jul 27 23:07:58 TV tvheadend27292: CRASH: Signal: 11 in PRG: /usr/bin/tvheadend (4.2.3-19~g490b6f2) [78b52fc7474ceb249133a0b531bc871be9a2416e] CWD: /
Jul 27 23:07:58 TV tvheadend27292: CRASH: Fault address 0x7f7d0000004a (Address not mapped)
Jul 27 23:07:58 TV tvheadend27292: 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 tvheadend27292: CRASH: Register dump [23]: 000000000000001e00007f7df4015e6000007f7df4000078000000000000000100007f7df402b8e820c49ba5e353f7cf00007f7dec00335000007f7e0e1f3700000000000000007800007f7df4015ed800007f7df401446000007f7dc800186000007f7df4015ed800007f7d00000002000000000000001e00007f7e0e1f292000005626b0157f800000000000010202002b0000000000330000000000000004000000000000000efffffffe7ffbba1100007f7d0000004a
Jul 27 23:07:58 TV tvheadend27292: CRASH: STACKTRACE
Jul 27 23:07:59 TV tvheadend27292: CRASH: /project/repo/checkout/src/trap.c:148 0x5626b00afe3d 0x5626afeb4000
Jul 27 23:07:59 TV tvheadend27292: CRASH: ??:0 0x7f7e20544670 0x7f7e20533000
Jul 27 23:07:59 TV tvheadend27292: CRASH: /project/repo/checkout/src/input/mpegts/satip/satip_frontend.c:698 0x5626b0157f80 0x5626afeb4000
Jul 27 23:07:59 TV tvheadend27292: CRASH: /project/repo/checkout/src/input/mpegts/mpegts_mux.c:910 0x5626b0124609 0x5626afeb4000
Jul 27 23:08:00 TV tvheadend27292: CRASH: /project/repo/checkout/src/main.c:634 (discriminator 3) 0x5626b006b24d 0x5626afeb4000
Jul 27 23:08:00 TV tvheadend27292: CRASH: /project/repo/checkout/src/wrappers.c:159 0x5626b0076155 0x5626afeb4000
Jul 27 23:08:00 TV tvheadend27292: CRASH: ??:0 0x7f7e2053a6da 0x7f7e20533000
Jul 27 23:08:00 TV tvheadend27292: CRASH: clone+0x5f (/lib/x86_64-linux-gnu/libc.so.6)
Jul 27 23:08:00 TV kernel: [4262170.222701] tvh:mtimer27375: 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.

#10 Updated by Flole Systems 14 days ago

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?

#11 Updated by Mono Polimorph 13 days ago

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.

#12 Updated by Flole Systems 12 days ago

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.

#13 Updated by Jaroslav Kysela 12 days ago

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

#14 Updated by saen acro 12 days ago

Flole Systems wrote:

Using DVBViewer it doesn't find TVHeadend.

Add manually ip it work tested

#15 Updated by Flole Systems 11 days ago

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.

#16 Updated by Mono Polimorph 11 days ago

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!

#17 Updated by Flole Systems 11 days ago

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

Also available in: Atom PDF