[seArs]

Hey guys,

I managed to bring up a working setup with a vdr-backend with vnsi-server and some clients using the kodi vnsi plugin.

Server:
PC Engines APU1D, 2x DD Duoflex S2 V4A (4 Tuners), DD DuoFlex CI, Alphacrypt light, HD+ subscription (ger)

VDR 2.3.8 headless on ubuntu server 18.04 (4.15.0-39-generic)
plugins:
conflictcheckonly
ddci2
epgsearch
epgsearchonly
quickepgsearch
streamdev-server
vnsiserver

Clients:
RasPi 3 B+ with Libreelec 8.2.5 (Krypton 17.6)
VDR VNSI Client

When it comes to Live TV everything is working as intended, including MTD via the DD CI and Alphacrypt CAM.
I have a channellist with ~50 SES Astra 19.2E channels, both SD and HD, scrambled and FTA.
Nearly all scrambled channels are processed as expected, except four of them. Those are "RTL HD", "RTLII HD", "VOX HD", and "n-tv HD". A quick look at the sattelites channellist shows that they're all on the same transponder (#57 10832MHz).
When switching to one of those channels, they obviously get descrambled (I get distorted parts of the pictures on the screen), but it's only single frames or short (<1s) videos of the stream.

As seen in the log https://pastebin.com/Xgf6ArYX switching to a scrambled channel and stopping (line 1-23) works like a charm.
Switching to one of the four other channels (from line 24) results in a recuring event from "CAM error / re-tune / close input / close dummy receiver and starting all over".
I tried to replace the entries in the channels conf for those channels with those mentioned in the yaVDR channelpedia and other web-sources, but to no success.

from channels conf:
RTL HD;CBC:10832:hC23M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32;48=deu:1830,1843,1860,98C,9C4,500,6CB,186A,186D,98D:61200:1:1057:0
RTLII HD;CBC:10832:hC23M5O35P0S1:S19.2E:22000:1535=27:0;1539=deu@106:37;54=deu:1830,1843,1860,98C,9C4,500,6CB,186A,186D,98D:61205:1:1057:0
VOX HD;CBC:10832:HC23M5O35P0S1:S19.2E:22000:511=27:0;515=deu@106:33;49=deu:1830,1843,1860,98C,9C4,500,6CB,186A,186D,98D:61201:1:1057:0
n-tv HD;CBC:10832:HC23M5O35P0S1:S19.2E:22000:1279=27:0;1283=deu@106,1284=mul@106:36:1830,1843,1860,98C,9C4,648,650,186A,500,6CB,186D,6E2:61204:1:1057:0

Earlier entries here were at least missing the "P0" parameter (DVB-S2 multicast parameter?!).

Streaming one of those channels via VDRadmin/VLC works. Also recording via EPG in Kodi and opening the recorded file does. So I guess the backend is not the problem in this case...

I'm running out of ideas (and skills) to get this fixed. So if somebody has a clue what this is related to, please let me know.

Best Regards

[FernetMenta]

You don't run latest version of vnsiserver, which is 1.8.0. I suggest that you try this. Maybe the issue is resolved already.

[seArs]

Actually updating the vnsiserver did the trick! Thank you!

Nevertheless switching to one of the mentioned channels now takes signifcantly longer than switching to any other channel.
The log shows buffer overruns. Following lines come up about 10-20 times in a row when switching to the channel:

Dez 05 16:37:22 tvh vdr[6124]: [6581] VNSI-Error: cParser::AddPESPacket - max buffer size reached, pid: 1535

It's not a serious problem as it only increases the switching time.


While looking for another solution I found the thread on vdr-portal.de which @Spirou mentioned in this thread https://forum.kodi.tv/showthread.php?tid=329301

Obviously there is (was) a problem with not descrambled packages causing the vnsi client to initiate a cam-reset/re-tune.
Was this issue solved or is there just a workaround implemented in the new server version?

[FernetMenta]

The root cause is that vnsiserver gets scrambled ts packets from vdr. This could be a dvd driver issue, vdr, cam, etc. I don't know. I don't have any issues here on the channels you named. The issue was mentioned on vdr portal in relation to dvb cards from digital devices and their cam system. I tried to alleviate the issue by being more tolerant in terms of ignoring up to 1000 scrambled packets.

EDIT: maybe it was CineTV and not Digital Devices. Yes, the link you posted points the the issue I referred to.

[FernetMenta]

@seArs do you know how to compile and test this little change?

Code:

diff --git a/parser.c b/parser.c
index 6639f06..36138ab 100644
--- a/parser.c
+++ b/parser.c
@@ -180,10 +180,15 @@ int cParser::ParsePacketHeader(uint8_t *data)
   if (TsIsScrambled(data))
   {
     if (m_scrambleCounter > 100)
+    {
       m_Error = ERROR_TS_SCRAMBLE;
+      return -1;
+    }
     else
+    {
       m_scrambleCounter++;
-    return -1;
+      return 0;
+    }

[seArs]

It's been a while since the last time I did something (useful) in C, but that should be no problem.
Unfortunately I won't be able to do it before the weekend. Looks like the 6th of december is somehow a reason to meet with your relatives...

btw: what is the expected outcome of the changes?

[FernetMenta]

  
I hope a faster channel switching times for the channels you named.

[seArs]

I just tried the patch you provided.
The "max buffer size reached" log entries are reduced. Till now I haven't had more than 10 per channel switch with an avergae of ~3. The switching times are reduced, but not that significantly.
On the other hand now on all initially scrambled channels audio and video are a little async. It's not much, but you can see it (at least my wife does...). A/V are re-synced after 5 to 60 seconds through a short video stutter.

For now I reverted to the unpatched version. 

You don't need to waste more time on this issue as the problem is obviously scrambled packages reaching the vnsi server and not the vnsi itself.

Thank you very much for solving this so fast!