Problem with SAT>IP when requesting 2 HD streams from the same mux

Günter Hensgen

Hello,
I have installed a SelfSat IP21 sat antenna with direct SAT>IP output. My setup is TVH 4.09 on Kodi/OpenELEC7 running on an RPi3. Everything works extremely fine. I am fully satisfied with this setup, as I can use up to 8 tuners from the antenna independently, so I can view/record several streams simultaneously.
But there is one remaining problem: Whenever I request more than one HD stream from one mux, after some few seconds (or even immediately) both streams freeze/crash. If I do the same with SD streams, everything works fine. If the streams are requested from different muxes/frequencies, also everything works.
I tried really much meanwhile, but cannot find a satisfying solution (the only possibility is to set up a second SAT>IP network for all channels and request the channels with same frequency from different networks; but this is not really satisfying).
The first question is, where the problem comes from. Maybe it comes even from the antenna itself - I don't know. In this case I could imagine, that a workaround in TVH could solve the problem: When there was a possibility to request a new tuner for each new channel, even if the mux/frequency is already used, my problem would be solved, as there are enough tuners available in the antenna. I even tried this by changing the code of TVH in several ways and load it as new addon into KODI - but all my changes failed. It seems that there is a strict releationship between mux and tuner, and there seems to be no way to assign more than one tuner to a mux. Maybe somebody knows more details about these data structures and can confirm or disprove these assumptions?
Another idea: Maybe there are any buffer sizes that are too small for two HD streams coming from one mux at the same time (SD streams are working!)? Or any other idea what could go wrong?
Any helpful hint is welcome. Thank you!

Joe User

Are they encrypted or FTA channels? If FTA, are you able to use mulitple VLCs to directly connect to SAT>IP server and watch multiple HD channels from the same mux?

If 2 SD channels work, what about 3,4,5,... ?

Can you provide a debug log of tvheadend? (If it doesn't show much, maybe a trace log will be necessary.)

Günter Hensgen

Only non-encrypted channels.
Watching on TV and via VLC from TVH webpage is absolutely the same. After requesting 2 HD streams on 2 VLC windows from the same mux, both VLC's stop playing.
I even managed to record 5 SD channels from the same mux at the same time - no problem.

Here is the debug log:

2017-04-12 12:46:53.336 http: 192.168.0.1: using ticket 1AA2923CEFABAA17FF19EC3DB52787253BA3AA47 for /stream/channel/9ae653f7c6c5c0d95b8bd1a3e1dbfccb 2017-04-12 12:46:53.338 mpegts: 11361.75H in SelfSat - tuning on SAT>IP DVB-S Tuner #1 (192.168.0.216) 2017-04-12 12:46:53.338 subscription: 0002: "HTTP" subscribing on channel "ZDF HD", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 (192.168.0.216)", network: "SelfSat", mux: "11361.75H", provider: "ZDFvision", service: "ZDF HD", profile="matroska", hostname="192.168.0.1", client="VLC/2.2.4 LibVLC/2.2.4" 2017-04-12 12:47:13.222 http: 192.168.0.1: using ticket 1815381F0AF4AFCBE57FED1622BDC307118E0D5C for /stream/channel/cae5fe43623fc987c92df3f6b0c64d86 2017-04-12 12:47:13.223 subscription: 0003: "HTTP" subscribing on channel "zdf_neo HD", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 (192.168.0.216)", network: "SelfSat", mux: "11361.75H", provider: "ZDFvision", service: "zdf_neo HD", profile="matroska", hostname="192.168.0.1", client="VLC/2.2.4 LibVLC/2.2.4"

Unfortunately there is not really much information in it. I enabled trace and the subsystem satips, but this didn't enlarge the output. Any hint to get more log info?

The above test is done with default stream profile matroska. When I do it with default profile pass, it is slightly better: The streams don't freeze immediatlely, but after 2-3 seconds of playing. Maybe this is helpful to know.

mpmc

Günter Hensgen wrote:
> Only non-encrypted channels.
> Watching on TV and via VLC from TVH webpage is absolutely the same. After requesting 2 HD streams on 2 VLC windows from the same mux, both VLC's stop playing.
> I even managed to record 5 SD channels from the same mux at the same time - no problem.
> Here is the debug log:
>
>

2017-04-12 12:46:53.336 http: 192.168.0.1: using ticket 1AA2923CEFABAA17FF19EC3DB52787253BA3AA47 for /stream/channel/9ae653f7c6c5c0d95b8bd1a3e1dbfccb
> 2017-04-12 12:46:53.338 mpegts: 11361.75H in SelfSat - tuning on SAT>IP DVB-S Tuner #1 (192.168.0.216)
> 2017-04-12 12:46:53.338 subscription: 0002: "HTTP" subscribing on channel "ZDF HD", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 (192.168.0.216)", network: "SelfSat", mux: "11361.75H", provider: "ZDFvision", service: "ZDF HD", profile="matroska", hostname="192.168.0.1", client="VLC/2.2.4 LibVLC/2.2.4"
> 2017-04-12 12:47:13.222 http: 192.168.0.1: using ticket 1815381F0AF4AFCBE57FED1622BDC307118E0D5C for /stream/channel/cae5fe43623fc987c92df3f6b0c64d86
> 2017-04-12 12:47:13.223 subscription: 0003: "HTTP" subscribing on channel "zdf_neo HD", weight: 100, adapter: "SAT>IP DVB-S Tuner #1 (192.168.0.216)", network: "SelfSat", mux: "11361.75H", provider: "ZDFvision", service: "zdf_neo HD", profile="matroska", hostname="192.168.0.1", client="VLC/2.2.4 LibVLC/2.2.4"

>Unfortunately there is not really much information in it. I enabled trace and the subsystem satips, but this didn't enlarge the output. Any hint to get more log info?

Tvheadend is the client not the server "satips" is for the server, you want "satip" for the client. You'll also have to set a temp log file in debugging & view that to see the debugging lines.

> The above test is done with default stream profile matroska. When I do it with default profile pass, it is slightly better: The streams don't freeze immediatlely, but after 2-3 seconds of playing. Maybe this is helpful to know.

You may want to consider giving 4.1 a try, if that also fails, open an issue on here with logs.
<<

Günter Hensgen

You are right, "satips" is the wrong subsystem to trace. Now I created a log file with "satip" and traced additionally the mpegts subsystem. It seems that the mpegts packets just vanish after some time, see attached log. Maybe there are further subsystems I should trace?

I tested already a rather new version of TVH (4.1.2490) on LibreELEC 8 - same result, see my German thread on kodinerds (https://www.kodinerds.net/index.php/Thread/56064-Sat-IP-Streams-vom-gleichen-Tuner-st%C3%B6ren-sich).

mpmc

Günter Hensgen wrote:
> You are right, "satips" is the wrong subsystem to trace. Now I created a log file with "satip" and traced additionally the mpegts subsystem. It seems that the mpegts packets just vanish after some time, see attached log. Maybe there are further subsystems I should trace?
>

> I tested already a rather new version of TVH (4.1.2490) on LibreELEC 8 - same result, see my German thread on kodinerds (https://www.kodinerds.net/index.php/Thread/56064-Sat-IP-Streams-vom-gleichen-Tuner-st%C3%B6ren-sich).

It looks like you're suffering from more than one issue, the selfsat can't send more than one stream per tuner. Not surprising really. And, the single usb bus on the Pi isn't helping.

With 4.1 have you tried turning off "Full mux RX mode supported"?
<<

Günter Hensgen

Mark Clarkstone wrote:
> It looks like you're suffering from more than one issue, the selfsat can't send more than one stream per tuner. Not surprising really. And, the single usb bus on the Pi isn't helping.
>

> With 4.1 have you tried turning off "Full mux RX mode supported"?

The selfsat can send more than one stream per tuner, but only SD streams work permanently. HD streams stop rather soon after requesting the 2nd stream (depends on the stream setting: profile 'pass' works for about 2 seconds, other profiles stop immediately).
I cant't imagine that the usb bus has anything to do with the issue; it is not involved at all in this context. The RPi3 is powerful enough to handle 2 HD streams, as when I request them from different muxes, everything works fine.
I again tested version 4.1 turning off "Full mux RX mode supported" - unfortunately no improvement.