Project

General

Profile

Bug #5496

Only after a reboot all sat>ip tuners are accessible again

Added by Thilo Gebers 9 months ago. Updated 22 days ago.

Status:
New
Priority:
Normal
Category:
SAT>IP
Target version:
-
Start date:
2019-01-14
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3
Affected Versions:

Description

Currently I'm using tvh in version 4.3-1718~g8e0dd2b.
My SAT>IP Server is a Kathrein EXIP 414.

First of all the problem I will describe did not appear in this version the first time, it has been around for quite some time.

A couple of days after I restart tvh it "lost" the tuners. Tuner #1 and sometimes tuner #2 doesn't work anymore. It doesn't matter if the idle scan starts or if a client tries to get a tv stream. Tuner #1 and tuner #2 are dead. As you can see below the idle scan on tuner #1 ends up in a "no data received" / "scan no data, failed" and the same procedure starts 10 seconds later over and over again.

2019-01-14 18:10:29.854 mpegts: 12480V in DVB-S Network - tuning on SAT>IP DVB-S Tuner #1 ([email protected])
2019-01-14 18:10:29.854 subscription: 7E95: "scan" subscribing to mux "12480V", weight: 2, adapter: "SAT>IP DVB-S Tuner #1 ([email protected])", network: "DVB-S Network", service: "Raw PID Subscription" 
2019-01-14 18:10:35.035 satip: SAT>IP DVB-S Tuner #1 ([email protected]) - no data received, restarting RTSP
2019-01-14 18:10:39.854 mpegts: 12480V in DVB-S Network - scan no data, failed
2019-01-14 18:10:39.854 subscription: 7E95: "scan" unsubscribing
2019-01-14 18:10:49.854 mpegts: 12480V in DVB-S Network - tuning on SAT>IP DVB-S Tuner #1 ([email protected])
2019-01-14 18:10:49.854 subscription: 7E97: "scan" subscribing to mux "12480V", weight: 2, adapter: "SAT>IP DVB-S Tuner #1 ([email protected])", network: "DVB-S Network", service: "Raw PID Subscription" 
2019-01-14 18:10:55.005 satip: SAT>IP DVB-S Tuner #1 ([email protected]) - no data received, restarting RTSP
2019-01-14 18:10:59.854 mpegts: 12480V in DVB-S Network - scan no data, failed
2019-01-14 18:10:59.854 subscription: 7E97: "scan" unsubscribing

The same issue on tuner #1 and tuner #2 with a client trying to stream a tv channel but it only works on tuner #4.
(It skips tuner #3 because it's currently in use by another client)

2019-01-14 18:58:14.154 mpegts: 12421.5H in DVB-S Network - tuning on SAT>IP DVB-S Tuner #1 ([email protected])
2019-01-14 18:58:14.154 subscription: 7FB4: "HTTP" subscribing on channel "WDR HD Essen", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 ([email protected])", network: "DVB-S Network", mux: "12421.5H", provider: "ARD", service: "WDR HD Essen", profile="pass", hostname="10.0.13.1", client="VLC/3.0.4 LibVLC/3.0.4" 
2019-01-14 18:58:19.398 satip: SAT>IP DVB-S Tuner #1 ([email protected]) - no data received, restarting RTSP
2019-01-14 18:58:20.155 subscription: 7FB4: service instance is bad, reason: Tuning failed
2019-01-14 18:58:20.155 mpegts: 12421.5H in DVB-S Network - tuning on SAT>IP DVB-S Tuner #2 ([email protected])
2019-01-14 18:58:20.155 subscription: 7FB4: "HTTP" subscribing on channel "WDR HD Essen", weight: 100, adapter: "SAT>IP DVB-S Tuner #2 ([email protected])", network: "DVB-S Network", mux: "12421.5H", provider: "ARD", service: "WDR HD Essen", profile="pass", hostname="10.0.13.1", client="VLC/3.0.4 LibVLC/3.0.4" 
2019-01-14 18:58:30.155 mpegts: 12421.5H in DVB-S Network - scan no data, failed
2019-01-14 18:58:30.155 subscription: 7FB4: service instance is bad, reason: No input detected
2019-01-14 18:58:30.155 mpegts: 12421.5H in DVB-S Network - tuning on SAT>IP DVB-S Tuner #4 ([email protected])
2019-01-14 18:58:30.155 subscription: 7FB4: "HTTP" subscribing on channel "WDR HD Essen", weight: 100, adapter: "SAT>IP DVB-S Tuner #4 ([email protected])", network: "DVB-S Network", mux: "12421.5H", provider: "ARD", service: "WDR HD Essen", profile="pass", hostname="10.0.13.1", client="VLC/3.0.4 LibVLC/3.0.4" 
2019-01-14 18:58:34.775 mpegts: 12421.5H in DVB-S Network scan complete

If I restart tvh everything works as expected.

2019-01-14 19:01:19.085 mpegts: 11361.75H in DVB-S Network - tuning on SAT>IP DVB-S Tuner #1 ([email protected])
2019-01-14 19:01:19.085 subscription: 7C62: "10.0.11.39 [ Kodi Media Center ]" subscribing on channel "ZDF HD", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 ([email protected])", network: "DVB-S Network", mux: "11361.75H", provider: "ZDFvision", service: "ZDF HD", profile="htsp", hostname="10.0.11.39", username="10.0.11.39", client="Kodi Media Center" 
2019-01-14 19:04:02.592 mpegts: 12421.5H in DVB-S Network - tuning on SAT>IP DVB-S Tuner #2 ([email protected])
2019-01-14 19:04:02.592 subscription: 7FCD: "HTTP" subscribing on channel "WDR HD Essen", weight: 100, adapter: "SAT>IP DVB-S Tuner #2 ([email protected])", network: "DVB-S Network", mux: "12421.5H", provider: "ARD", service: "WDR HD Essen", profile="pass", hostname="10.0.13.1", client="VLC/3.0.4 LibVLC/3.0.4" 
2019-01-14 19:04:03.842 mpegts: 12421.5H in DVB-S Network scan complete

History

#1

Updated by Jaroslav Kysela 9 months ago

Try to play with 'Fast input switch' and forced UDP RTP port settings. The best debugging method is to capture the network communication, if the satip server does the right job.

#2

Updated by Thilo Gebers 9 months ago

Jaroslav Kysela wrote:

Try to play with 'Fast input switch' and forced UDP RTP port settings.

'Fast input switch' was already activated.
I've assigned an UDP port to each tuner, in increments of ten, tuner #1 50010, tuner #2 50020, and so on.

Now I will leave tvh untouched for a week. No setting adjustment, no restart. After that, I'll give you feedback whether the port customizations have resolved the issues.

#3

Updated by Jaroslav Kysela 9 months ago

Thilo Gebers wrote:

Jaroslav Kysela wrote:

Try to play with 'Fast input switch' and forced UDP RTP port settings.

'Fast input switch' was already activated.

It's the default. Try to turn this off, too.

#4

Updated by Thilo Gebers 9 months ago

Jaroslav Kysela wrote:

Thilo Gebers wrote:

Jaroslav Kysela wrote:

Try to play with 'Fast input switch' and forced UDP RTP port settings.

'Fast input switch' was already activated.

It's the default. Try to turn this off, too.

All right ... It is turned off now.

#5

Updated by Thilo Gebers 9 months ago

For over a week, Tvheadend runs perfectly with the two changed settings. The two tuners are still found and used by Tvheadend. Many thanks to Jaroslav for his support.
In order to find out which setting was responsible for the problems, I will reactivate "Fast input switch" and observe how this affects tuner #1 and #2.

#6

Updated by Thilo Gebers 8 months ago

After a good month, TvHeadend is very stable. All tuners are still available. In the meantime version 4.3-1768 is in use. Even so, there are no problems.
I set the following settings: an UDP port was assigned to each tuner. I deactivated "Fast input switch". In addition, I have disabled the "idle scan" on all tuners.

Now we can set the topic to "solved".

Jaroslav, thanks again for your support!

#7

Updated by Flole Systems 27 days ago

I'm having the exact same issue, even without "Fast input switch" and a static UDP Port assigned. Tvheadend does in this case not receive any UDP Packets (while wireshark shows that they are there). There's also no "ICMP Port unreachable" until shortly after the teardown (I think this should not happen, we should first wait for the response of the server and then close the port), so I assume the port is indeed open the entire time.

Also I think that the last Tuner Status (SNR and Signal Level) is not cleared, if the tuner doesn't send those information the last one will stay in there. Maybe there is something wrong somewhere with the (de)initialization?

@Jaroslav: Any assumption what might be going on here? I'm more than happy to dive into the debugging but I have no idea what could cause a behaviour like this.

#8

Updated by Flole Systems 27 days ago

Actually after waiting a little they seem to start working again.....

#9

Updated by Pablo R. 27 days ago

The same happens here, I think I've solved it by incresing the kernel udp buffer. Although I am still not clear at all.
What I have noticed is that the adapters are hung when many frequencies are closed together, for example closing 9 at the same time. Some of them remains at 0 until tvheadend restart.

#10

Updated by Flole Systems 25 days ago

Today I noticed that sometimes tvheadend doesnt even do the RTP connection to start the Stream. I will need to do some GDB Debugging but first I need to figure out the points that I want to stop and look at (probably right before the RTP is attempting to connect and right before the UDP Socket is prepared and opened).

#11

Updated by Flole Systems 22 days ago

I've done a little more investigation now: Usually we should have satip_frontend.c:2081 receiving the UDP Data, for some reason this is not happening though, the code never reaches 2081 when the tuner is in this unusable state. The problem must be somewhere in the lines above....

@Jaroslav: Is this thread started for every new tuning or is it setup once when the input source is setup and then re-used? Any idea what I should look for when trying to find the cause of the issue?

#12

Updated by saen acro 22 days ago

Flole Systems graphviz show connection flow and some dead code

#13

Updated by Jaroslav Kysela 22 days ago

Flole Systems wrote:

I've done a little more investigation now: Usually we should have satip_frontend.c:2081 receiving the UDP Data, for some reason this is not happening though, the code never reaches 2081 when the tuner is in this unusable state. The problem must be somewhere in the lines above....

@Jaroslav: Is this thread started for every new tuning or is it setup once when the input source is setup and then re-used? Any idea what I should look for when trying to find the cause of the issue?

It's reused for the fast switch. You may try to analyze '--trace satip' log and eventually add more traces to see where the code gets stuck.

Also available in: Atom PDF