minisatip8 not stable with VDR satip-plugin

[ecdlguy]

Hi,

it's close to impossible to use minisatip8 with the VDR satip-plugin. After rapid channel switching, the video looks like slow motion and there's no audio. A few channel switches later there's no video on any channel. Even stopping vdr and give the receiver some time to power down the frontends does not help.

See also #94

I've attached the minisatip debug output: out.txt

cheers, Thorsten

[CvH]

just for reference https://github.com/rofafor/vdr-plugin-satip/issues/47 https://github.com/catalinii/minisatip/issues/422

[meijkl]

Well, I simply can't confirm the issues. I'm using two Debian installations (unstable w/VDR 2.3.8, satip 2.3.0 + stable w/VDR 2.2.0, satip 2.2.4) on Kirkwood (arm) devices. No problems, stable operation!

I'd made one major change by radically increasing buffer sizes. Based on rofafor's hints my settings in sysctl.conf are:

net.core.rmem_max=8388608 net.core.rmem_default=1048576 net.core.wmem_max=8388608 net.core.wmem_default=1048576

net.ipv4.tcp_rmem= 16384 131072 8388608 net.ipv4.tcp_wmem= 16384 131072 8388608 net.ipv4.tcp_mem= 8388608 8388608 8388608

Best Klaus

P.S.: In addition to VDR I'm using Windows with DVBViewer/SAT>IP - again no issues!

[ecdlguy]

@CvH I'm not using rtp-over-tcp. With minisatip7 there are no issues due to rapid channel switching and with minisatip8 there are.

@meijkl Maybe I'll try those settings. I don't think the tcp-settings will change anything since I'm using "standard" rtp (over udp). If the settings network buffer settings enhance stability, should @perexg consider them as default?

I've also seen there exist a lot of different minisatip settings for various buffer sizes, e.g. @perexg recommended to use

-H 5:25 -b 4042752 -B 10000

I've read the minisatip7 help, but I don't know what the "app adapter buffer", the "app socket write buffer", and the "write time threshold" really mean and how they do affect the interplay with a satip client.

Could someone please explain the meaning and use cases of these settings to a minisatip novice?

Thanks! Thorsten

[ecdlguy]

@meijkl Are you sure you're unsing minisatip8? You have to enable this in /etc/sysconfig/config:

# MINISATIP7="yes"
MINISATIP8="yes"

I've did a lot of testing with mld 5.4 testing as well as mld 5.3 stable & testing, using an RPi2 and as well as the 64-Bit PC version. No matter what, minisatip7 is stable, whereas minisatip8 doesn't work after a few channel switches.

Here's the config I'm using for minisatip7/8 (I'm on Unicable): MINISATIP7_OPTS="-q *:150-54-15-15-15-0 -u 0:0-1210,1:1-1420,2:2-1680,3:3-2040" or MINISATIP8_OPTS="-q *:150-54-15-15-15-0 -u 0:0-1210,1:1-1420,2:2-1680,3:3-2040"

cheers, Thorsten

[meijkl]

@ecdlguy: yes, I'm sure (for sake of clarity my settings: MINISATIP8_OPTS="-D 1 -u 0:0-1210,1:1-1420,2:2-1680,3:3-2040")

I'm using two Debian-based installations (Debian Stable w/VDR 2.2.0 + SATIP 2.2.4 / Debian Testing w/VDR 2.3.8 + SATIP 2.3.1 compiled with latest changes from rofafor). Both installations are headless since I use them for recording purposes or in combination with Kodi).

I had issues but mine were obviously caused by my network. Now my VDR boxes are connected to my GSS400 (w/minisatip-axe) directly with one switch in between (before up to 4 switches). In combination with the network settings mentioned above the issues are gone.

I assume that my settings are a little bit radical and could be lower. But it works in contrast to the standard settings, no need to change anything!

Last point - fast channel switching! I've tried it and it worked for me without errors: User.log:

Feb 16 19:01:44 plug-VDR-2 vdr: [5288] switching to channel 2 S19.2E-1-1079-28006 (ZDF) Feb 16 19:01:48 plug-VDR-2 vdr: [5288] switching to channel 2 S19.2E-1-1079-28006 (ZDF) Feb 16 19:01:55 plug-VDR-2 vdr: [5288] switching to channel 2 S19.2E-1-1079-28006 (ZDF) Feb 16 19:01:57 plug-VDR-2 vdr: [5288] switching to channel 2 S19.2E-1-1079-28006 (ZDF) Feb 16 19:02:27 plug-VDR-2 vdr: [5293] SATIP: Idle timeout - releasing [device 0] Feb 16 19:02:31 plug-VDR-2 vdr: [5288] switching to channel 3 S19.2E-1-1079-28007 (3sat) Feb 16 19:02:32 plug-VDR-2 vdr: [5288] switching to channel 4 S19.2E-1-1051-28724 (arte) Feb 16 19:02:34 plug-VDR-2 vdr: [5288] switching to channel 5 S19.2E-1-1051-28722 (ONE) Feb 16 19:02:36 plug-VDR-2 vdr: [5295] changing pids of channel 1428 (Test-R) from 401+401=2:402=deu@3:0:0 to 501+501=2:502=deu@3:0:0 Feb 16 19:02:37 plug-VDR-2 vdr: [5288] switching to channel 6 S19.2E-1-1079-28008 (KiKA) Feb 16 19:02:39 plug-VDR-2 vdr: [5288] switching to channel 7 S19.2E-1-1051-28725 (PHOENIX) Feb 16 19:02:40 plug-VDR-2 vdr: [5288] switching to channel 14 S19.2E-1-1073-28206 (rbb Berlin) Feb 16 19:02:42 plug-VDR-2 vdr: [5288] switching to channel 13 S19.2E-1-1073-28225 (NDR FS HH) Feb 16 19:02:43 plug-VDR-2 vdr: [5295] changing pids of channel 13 (NDR FS HH) from 2501+2501=2:2502=deu@3,2503=mis@3:0:2604 to 2601+2601=2:2602=deu@3,2603=mis@3:0:2604 Feb 16 19:02:43 plug-VDR-2 vdr: [5288] switching to channel 12 S19.2E-1-1073-28227 (NDR FS SH) Feb 16 19:02:43 plug-VDR-2 vdr: [5295] changing pids of channel 12 (NDR FS SH) from 2701+2701=2:2702=deu@3,2703=mis@3:0:2604 to 2601+2601=2:2602=deu@3,2603=mis@3:0:2604 Feb 16 19:02:44 plug-VDR-2 vdr: [5295] changing pids of channel 242 (MDR Sachsen) from 2901+2901=2:2902=deu@3,2903=mis@3:2905=deu:2904 to 2801+2801=2:2802=deu@3,2803=mis@3:2805=deu:2804 Feb 16 19:02:45 plug-VDR-2 vdr: [5288] switching to channel 11 S19.2E-1-1079-28014 (zdf_neo) Feb 16 19:02:47 plug-VDR-2 vdr: [5288] switching to channel 10 S19.2E-1-1079-28011 (ZDFinfo) Feb 16 19:02:48 plug-VDR-2 vdr: [5288] switching to channel 9 S19.2E-1-1051-28721 (tagesschau24) Feb 16 19:02:50 plug-VDR-2 vdr: [5288] switching to channel 8 S19.2E-1-1093-28487 (ARD-alpha) Feb 16 19:02:52 plug-VDR-2 vdr: [5288] switching to channel 15 S19.2E-1-1073-28231 (SWR Fernsehen RP) Feb 16 19:02:54 plug-VDR-2 vdr: [5288] switching to channel 16 S19.2E-1-1101-28110 (BR Fernsehen Nord) Feb 16 19:02:55 plug-VDR-2 vdr: [5288] switching to channel 17 S19.2E-1-1101-28108 (hr-fernsehen) Feb 16 19:02:56 plug-VDR-2 vdr: [5288] switching to channel 18 S19.2E-1-1101-28111 (WDR Köln) Feb 16 19:02:59 plug-VDR-2 vdr: [5288] switching to channel 25 S19.2E-1-1089-12020 (RTL2) Feb 16 19:03:01 plug-VDR-2 vdr: [5288] switching to channel 24 S19.2E-1-1089-12003 (RTL Television) Feb 16 19:03:02 plug-VDR-2 vdr: [5288] switching to channel 23 S19.2E-1-1089-12006 (RTL FS) Feb 16 19:03:04 plug-VDR-2 vdr: [5288] switching to channel 22 S19.2E-1-1107-17505 (Pro7 MAXX) Feb 16 19:03:06 plug-VDR-2 vdr: [5288] switching to channel 26 S19.2E-1-1089-12061 (NITRO) Feb 16 19:03:08 plug-VDR-2 vdr: [5288] switching to channel 33 S19.2E-133-5-764 (ANIXE SD) Feb 16 19:03:10 plug-VDR-2 vdr: [5288] switching to channel 32 S19.2E-133-5-776 (SIXX) Feb 16 19:03:11 plug-VDR-2 vdr: [5288] switching to channel 31 S19.2E-1-1089-12060 (VOX) Feb 16 19:03:14 plug-VDR-2 vdr: [5288] switching to channel 30 S19.2E-1-1089-12040 (SUPER RTL) Feb 16 19:03:16 plug-VDR-2 vdr: [5288] switching to channel 29 S19.2E-1-1107-17504 (SAT.1 Gold) Feb 16 19:03:17 plug-VDR-2 vdr: [5288] switching to channel 36 S19.2E-1-1078-28680 (Nickelodeon) Feb 16 19:03:18 plug-VDR-2 vdr: [5288] switching to channel 37 S19.2E-1-1078-28676 (Comedy Central/VIVA)

Hope this helps! Klaus

[perexg]

Note that I increased net.core.wmem_max=12582912 in latest build 15, so it might resolve the UDP problem.

[ecdlguy]

Still not working for me. @meijkl Have you also tried HD channels?

[ecdlguy]

Hi again, I found time to do some logging After touching /tmp/nosatip and killing minisatip8 on the box, I've used

ssh -t root@192.168.2.30 minisatip8 -f -l http,pmt -q *:150-54-15-15-15-0 -u 0:0-1210,1:1-1420,2:2-1680,3:3-2040 | tee out3.txt

on my PC to capture the log: out3.txt

On another PC I've started MLD (mindvblinux) 5.4 and started switching channels.

The first problems came up around 23:31, there was no sound anymore. The picture vanished at ~23:32.

I really hope this helps to narrow down the problems between minisatip8 and the VDR satip-plugin. If I you need additional logs or with different logging modules enabled, please let me know.

cheers, Thorsten

[perexg]

I think that I see the problem. Please, retest with this binary (copy it using scp to /tmp on the box and run ssh command like in your previous comment again / replace minisatip8 with /tmp/minisatip): http://s000.tinyupload.com/?file_id=06132783687352173508

[perexg]

Fixing minisatip bugs: https://github.com/catalinii/minisatip/pull/455

[perexg]

rc2 is out with the fix in minisatip8: https://github.com/perexg/satip-axe/releases/tag/build15-rc2

[ecdlguy]

Wow man, I think you found the problem! I've been testing for about one hour now, I will report again in a few days but it looks very good! Thanks a lot, perexg!

[ClashC]

This is the first release that works here with VDR (2.4.0) and a raspberrypi3 with satip plugin. I had no problems here with build15-rc2. So far the firmware idl4k-1.25.0.157.bin worked stable on a Grundig GSS.BOX 400. I configured it under /etc/sysconfig/config as follows: ... MINISATIP8="yes" MINISATIP8_OPTS="-Q -H 5:25 -b 4042752 -B 10000" ... The sysctl.conf on the RaspberryPi3 is original from debian and is not changed. Great work. I continue testing and contact you if there are any problems.

ClashC

[perexg]

@ClashC : Thanks for the feedback.

[ecdlguy]

Ok now after running for four days I can report that unfortunately the bug is still present but it occurs very rare. The behavior is exactly the same as before the bug fixing of minisatip, but it's only once a day and not after five or ten minutes.

Maybe there's another position in the minisatip-code with the same race condition?

How can I help debugging further? Since it takes so long to reproduce the bug, a log file of one or two days would be way to large...

Thanks again, Thorsten

[perexg]

Unfortunately, I cannot do much without the log. You can cut the log before upload around the time where is the problem visible.

[ecdlguy]

Ok I try to do something like logrotate for the pipe of the minisatip output to file so it can run for days without producing gigabytes of text files. I am not quite sure how to do this, though.

Which of the logging options

general,http,socketworks,stream,adapter,satipc,pmt,tables,dvbapi,lock,netceiver,ca,axe,socket,utils,dmx,ssdp,dvb

are important for you in order to debug properly?

[perexg]

general,http,stream,adapter,dvb,axe should be enough.

[meijkl]

Hi perexg, after some months I started again using my satip-VDR-stuff and upgraded to build 15 rc6.

Unfortunately I have to confirm ecdlguy's findings. It just takes some channels switches combined with recording attempts to break minisatip8. An immediate effect is that recordings with VDR start but nothing is recorded. Recordings were started at 6:16:43 UTC, 6:28:56 UTC and 6:32:00 UTC. I've made a log (attached) with parameters "general,http,stream,adapter,dvb,axe" as mentioned above.

Please let me know if you need further information.

Thanks for your efforts! Klaus

minisatip8-build15-rc6-log-2018_10_17.tar.gz

[perexg]

@meijkl : Could you do a quick test with '-T' option (enable threads)?

[meijkl]

Done!

This time it took only one channel switch. I started a first recording, stopped it after some seconds and started a second on a different channel. First recording worked/started, second didn't. I've also added the relevant part of the VDR log. There you can see VDR's actions and error messages.

Thanks Klaus minisatip8-build15-rc6-log-2018_10_17-1400.tar.gz

[perexg]

I don't see much . Appearently, minisatip tuned to the Pro7 MAXX correctly:

[17/10 12:08:27.524 main]: PLAY rtsp://192.168.0.141/stream=2?src=1&freq=12544&pol=h&ro=0.35&msys=dvbs&mtype=qpsk&plts=off&sr=22000&fec=56 RTSP/1.0
[17/10 12:08:27.760 AD2]: Got the new transponder 0453 1107, position 376, 38 ms after tune
[17/10 12:08:27.761 AD2]: Start streaming for stream 1, len 1316 to handle 15 => 192.168.0.125:39190

[perexg]

Ohh, the old bug is back, I see it now:

[17/10 12:08:29.632 main]: maximum number of pids 10 out of 3 reached

[perexg]

17/10 12:07:24.008 main]: pid -1, fd 0, packets 0, d/c errs 0/0, flags 2, pmt -1, filter -1, sock -1, sids: 2 -1 -1 -1 -1 -1 -1 -1
[17/10 12:07:24.010 main]: failed setting filter on PID -1 for ADAPTER 2 (Device or resource busy)
[17/10 12:07:24.010 main]: Maximum pid filter reached, lowering the value to 3

[perexg]

Crazy VDR:

[17/10 12:07:23.999 main]: PLAY rtsp://192.168.0.141/stream=3?addpids=65535 RTSP/1.0

PID 65535 ? Uff, i don't believe..

[meijkl]

Yes, at least it seems to be strange ...

[perexg]

Basically, it explains this strange behaviour - I refuse to set PID -1 (taken from the 65535) value in the axe code in minisatip and the minisatip core code things that all PIDs are exhausted, thus it lowers the maximal PIDs limit to really wrong value (3) which causes that nothing can be send through wire.

[perexg]

Please, report this to VDR (but I will fix minisatip, too). It's really wrong when I have to fix everything ;-(

[meijkl]

Ok, so VDR gets PID 65535 resp. -1?

I'll post an issue for satip/rofafor referencing to this thread.

Again many thanks for your effort. Looks like things progress :-) Klaus

[perexg]

Could you test this minisatip binary: http://s000.tinyupload.com/?file_id=00901256933826718601 ? Remove '-T' (the threaded mode is turned on by default now).

[perexg]

Sorry, wrong binary. Here is new: http://s000.tinyupload.com/?file_id=66921194734577524481

[meijkl]

The first one was already better! Made three recordings on three different channels - it worked! Saw only one VDR-error after stopping a recording: Oct 17 15:40:41 plug-VDR-2 vdr: [30023] live timer 4 (130 1454-1616 'Auf Entdeckungsreise - durch Europa') deleted Oct 17 15:40:41 plug-VDR-2 vdr: [30196] EPGSearch: recdone thread ended (pid=30023, tid=30196) Oct 17 15:41:02 plug-VDR-2 vdr: [30028] SATIP-ERROR: Tuning timeout - retuning [device 0]

I'll try the other one in a moment.

[9000h]

btw did you see the "PID 65535 resp. -1?" also on FTA channels?

[meijkl]

The second version works too! Made again a short test with three channels switches and recordings (see VDR-Log).

Thanks Klaus

P.S.: Made a quick check & couldn't find a "65535" entry on FTA channels so far. I'll continue testing!

minisatip8-test2-log-2018_10_17-1408ÛTC.tar.gz

[perexg]

I released final build 15 with all those VDR related fixes #94 - https://github.com/perexg/satip-axe/releases/tag/build15 .

[meijkl]

During the night my VDR made several recordings on different channels - no issues! In parallel to my VDR I've also used DVBViewer with Windows and the Geniatech/formerly Elgato SAT>IP app on my iPhone - again no issues!

Having used many releases since 2016 and always having had some issues with stability after a while my impression is that this release is a big step forward and this issue is solved!

Thanks a lot! Klaus

P.S.: just an assumption - when using the former releases which led to the broken streaming issue my box became very warm. I didn't make precise measurements but when I touched the box this morning I got the impression that the temperature was significantly lower.

[perexg]

Thanks for the feedback.

[meijkl]

VDR minisatip now has an upper limit for the PID:

https://github.com/rofafor/vdr-plugin-satip/commit/6c74c10cbba912e67a6c72a93e1d8b8b2692d42e