Bug #4445
closed
Sat-IP Server stops working after some time
Added by Flole Systems almost 8 years ago. Updated over 6 years ago.
0%
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.
Files
Updated by Flole Systems almost 8 years 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.
Updated by Jaroslav Kysela almost 8 years ago
Each subsystems have own locks, so only SAT>IP server may be affected.
Updated by Flole Systems almost 8 years 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.
Updated by Jaroslav Kysela almost 8 years ago
Compile/use tvh binary with debug symbols...
Updated by Flole Systems almost 8 years ago
This should be with debug symbols.
Updated by Flole Systems almost 8 years ago
Looks like the gdb is the same, at least to me. I did under debian apt install tvheadend-dbg and restartet tvheadend afterwards.
Updated by Flole Systems almost 8 years 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.
Updated by Jaroslav Kysela almost 8 years ago
It looks like a memory corruption then: https://tvheadend.org/projects/tvheadend/wiki/Debugging#Memory-leaks-or-corruption
Updated by Flole Systems over 7 years 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?
Updated by Mono Polimorph over 7 years 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.
Updated by Flole Systems over 7 years 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.
Updated by Jaroslav Kysela over 7 years ago
Just to confirm: If you enable traces (--trace upnp), you don't see the M-SEARCH packet in the tvh's log file?
Updated by saen acro over 7 years ago
Flole Systems wrote:
Using DVBViewer it doesn't find TVHeadend.
Add manually ip it work tested
Updated by Flole Systems over 7 years 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.
Updated by Mono Polimorph over 7 years 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!
Updated by Flole Systems over 7 years ago
I have done that yesterday, before that it was on the same network.
Updated by Flole Systems over 6 years ago
Whatever this was, it is fixed now. This can be closed.