Multiple OctopusNet servers with source-filtering - wrong server selection for devices about vdr-plugin-satip HOT 12 CLOSED

When starting a recording just now, satip decided to assign a 19.2E channel to the 28.2E server/frontend. I don't have any logs for why this has happened. I assume it is related to the above observations.

from vdr-plugin-satip.

Could you provide some (well, quite a lot) debugging data?

svdrpsend plug satip trac 0x102

or

--trace=0x102

Afterwards grep SATIP from your syslog.

from vdr-plugin-satip.

Voila.

debug-github-28.txt.gz

from vdr-plugin-satip.

Thanks. Could you add channels.conf entries from these channel numbers: 18, 795, 2012, 738, 1707, 2118, 1782 ?

At a first glance, the problem seems to be in frontend attaching. It's done after RTSP handover, that's too late for massive concurrent SetChannelDevice calls.

from vdr-plugin-satip.

18   Einsfestival;ARD:10743:HC56M2S0:S19.2E:22000:201=2:202=deu@3,203=mis@3;206=deu@106:204:0:28722:1:1051:0
795  NICKELODEON HD;MTV Networks:10773:HC34M5O20P0S1:S19.2E:22000:511=27:0;515=deu@106,516=eng@106:0:1830,1843,9C4,98C,64
2012 Disney Channel HD;BetaDigital:10802:HC34M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32:1830,1843,9C4,98C,1860,186A:5
738  RTL HD;CBC:10832:HC23M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32;48=deu:1830,1843,1860,98C,9C4,186A:61200:1:1057:
1707 rbb Brandenburg HD;ARD:10891:HC23M5O35P0S1:S19.2E:22000:5311=27:5312=deu@3,5313=mis@3;5316=deu@106:5314;5315=deu:0:1
2118 .;BetaDigital:10920:HC78M2S0:S19.2E:22000:1791=2:1792=deu@3,1793=eng@3:0:1702,1833,9C4,98C:56:133:15:0
1782 TLC HD;BetaDigital:10964:HC23M5O35P0S1:S19.2E:22000:255=27:0;259=deu@106:32:1830,1843,9C4,98C,1860,186A:10100:1:1033

from vdr-plugin-satip.

Sorry for the delay, but I haven't had time (or motivation) fixing the bug. The issue here is the state machine of tuner: in order to make the system as quick and responsible, the channel switch just sends a tuning event for the state machine, that's run in a separate thread. EPG scan utilizes all free devices and therefore there will be as many instant channel switches. The channel switch contains a check for free frontends, but unfortunately the frontend reservation is done inside the event pump of the tuner thread. To fix this situation the frontend reservation should be done asap, but I don't know what would be the cleanest way (read: to minimize refactoring) to achieve this without adding annoying blocking.

from vdr-plugin-satip.

Same here (lack of time and motivation).

At some point I will see what I can do, for the moment I'm using another hack. I'm hardcoding my configuration into device.c as a proof-of-concept-test:

--- a/device.c
+++ b/device.c
@@ -235,8 +235,28 @@ int cSatipDevice::SignalQuality(void) const

 bool cSatipDevice::ProvidesSource(int sourceP) const
 {
-  cSource *s = Sources.Get(sourceP);
-  debug9("%s (%c) desc='%s' [device %u]", __PRETTY_FUNCTION__, cSource::ToChar(sourceP), s ? s->Description() : "", deviceIndexM);
+       cSource *s = Sources.Get(sourceP);
+       info("%s (%c) desc='%s' [device %u]", __PRETTY_FUNCTION__, cSource::ToChar(sourceP), s ? s->Description() : "", deviceIndexM);
+       switch (deviceIndexM) {
+       case 0:
+       case 1:
+       case 2:
+       case 3:
+               return sourceP == cSource::FromString("S19.2E");
+
+       case 4:
+       case 5:
+               return sourceP == cSource::FromString("S28.2E");
+
+       case 6:
+       case 7:
+               return sourceP == cSource::FromString("T");
+       }
+
+       return false;
+
+
+
   if (SatipConfig.GetDetachedMode())
      return false;
   // source descriptions starting with '0' are disabled

This works now with 8 devices set but creates two more problems:

1. From locally started vdr-sxfes and from a vdr which is connected via streamdev I'm getting randomly "Cannot switch channel - transfer mode is running"-error (when EPG scan is running and a recording is running).

2. Sometimes the "server" on my Octopusses dies and I need to manually restart it. (I'm using the latest beta.) I assume that vdr-satip is flooding it with requests, but I have no proof and did not investigate.

from vdr-plugin-satip.

This might help with the issue:
72c3247

from vdr-plugin-satip.

Closing the issue due to a possible fix in the master branch. If it doesn't work after all, please, re-open this issue.

from vdr-plugin-satip.

Thanks for checking back. My VDR configuration has changed since I reported the problem. I'm now using one Octopus Net with 4 DVB-S2 (Astra 19.2) and a PCIe-express card for DVB-T and S2 (Astra 28.8).

I'm getting "Transfer mode cannot be started"-messages all the time. Should I report another issue or will this issue be fixed with your your fix?

from vdr-plugin-satip.

How about changing cSatipDevice::SetChannelDevice() to return always true as the cDvbDevice implementation does?

from vdr-plugin-satip.

Closing due to inactivity

from vdr-plugin-satip.