Jump to content

"Sender nicht verfügbar vom Server" bei Verwendung von min. 2 DVBViewer Clients am DMS (Non-Basic)


h0ly0ne

Recommended Posts

h0ly0ne

Hallo zusammen,

 

habe seit Neuestem (jetzt aktuell bei 7.0.0.0+3.0.0.0 - kann jetzt auch schon einige Versionen her sein) das Verhalten das sich bei

min. 2 gleichzeitigen RTSP Connections von DVBViewer Clients aus nur immer einer (der vier verfügbaren) Tuner ansprechen lässt.

 

Die Aufrufkette (bei der maximal ein Client funktioniert): DVBViewer -> DMS Server -> Octopus V2 NET 4xDVB-CT2

Die Aufrufkette (bei der alle vier Clients funktionieren): DVBViewer -> Octopus V2 NET 4xDVB-CT2

 

Sobald sich also ein Client den ersten verfügbaren Tuner schnappt bekomme ich bei allen anderen Clients "Sender nicht verfügbar

vom Server" - außer der Sender befindet sich im selben Transponder/Segment - dann funktioniert es natürlich (da kein ReTune

erforderlich sein soltle).

 

Folgendes Verhalten konnte im svcdebug.log beobachten:

 

13.01.21 08:01:49.253 SetStandbyBlock      RTSP-Client <Client1>
13.01.21 08:01:49.253 TServiceMain         AddReference     RTSP-Client <Client1>: 1
13.01.21 08:01:49.253 TRTSPUDPClient       SendBufSizeUDP   13280000
13.01.21 08:01:49.254 TRTSPUDPClient       SetTuner         TType: 0, Freq: 434000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 771, VPID: 767, PMT: 3398, SID: 127, TID: 13, NID: 133, SatMod: 0, DiseqCVal: 0, Flags: 25, Group: 0
13.01.21 08:01:49.256 TRTSPUDPClient       AllocateHardware OCTONETDVBC#1
13.01.21 08:01:49.256 TRTSPUDPClient       SetTuner         Got new hardware
13.01.21 08:01:49.256 TRTSPNetworkStream   SetTuner         TType: 0, Freq: 434000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 771, VPID: 767, PMT: 3398, SID: 127, TID: 13, NID: 133, SatMod: 0, DiseqCVal: 0, Flags: 25, Group: 0
13.01.21 08:01:49.275 Plugin 014EEBD8      SetTuner SID=127
13.01.21 08:01:49.278 TRTSPUDPClient       SetTuner         Tuner set
13.01.21 08:01:49.278 SETUP                200              freq=434&msys=dvbc&sr=6900&mtype=256qam&pids=0&tnr=0,434000,6900,0,0,5,0,0,771,767,3398,127,0,0,25,0,13,133,-1,4000,767&prio=50
13.01.21 08:01:49.278 Add TSCall           
13.01.21 08:01:49.278 AddPID               0
13.01.21 08:01:49.279 AddPID               3398
13.01.21 08:01:49.279 PLAY                 200              addpids=3398&delpids=0
13.01.21 08:01:49.280 PLAY                 200              addpids=18
13.01.21 08:01:49.281 PLAY                 200              addpids=767,771,0,17
13.01.21 08:01:49.553 AddPID               7911
13.01.21 08:01:49.576 DelPID               0
13.01.21 08:01:54.934 AddPID               17
13.01.21 08:01:55.042 TRTSPUDPClient       SendBufSizeUDP   13280000
13.01.21 08:01:55.042 TRTSPUDPClient       SetTuner         TType: 0, Freq: 586000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 217, VPID: 216, PMT: 1004, SID: 13014, TID: 11118, NID: 1, SatMod: 0, DiseqCVal: 0, Flags: 24, Group: 0
13.01.21 08:01:55.044 TRTSPUDPClient       AllocateHardware OCTONETDVBC#2
13.01.21 08:01:55.044 TRTSPUDPClient       SetTuner         Got new hardware
13.01.21 08:01:55.044 TRTSPNetworkStream   SetTuner         TType: 0, Freq: 586000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 217, VPID: 216, PMT: 1004, SID: 13014, TID: 11118, NID: 1, SatMod: 0, DiseqCVal: 0, Flags: 24, Group: 0
13.01.21 08:01:55.048 TRTSPNetworkStream   SETUP ?fe=2&freq=586&msys=dvbc&sr=6900&mtype=256qam&pids=0&x_ci=2
RTSP/1.0 455 Method Not Valid in This State
CSeq: 2

 

Was habe ich schon probiert?

* Die RTSP Clients am DMS sowie bei den DVBViewer Clients neu konfiguriert (4 Stück am DMS sowie bei den Clients)

* Frontend-Property 1-4 bei den RTSP Clients eingestellt (hatte aber keinerlei Effekt)

 

Im Moment bin ich etwas ratlos - es sieht hier so aus als würde beim Weg über den DMS immer die erste RTSP Connection zum OCTONET verwendet werden

(obwohl 4 Stück davon verfügbar sind) - anders kann ich mir dieses Verhalten irgendwie nicht erklären.

 

Grüße,

Oliver

 

 

 

Link to post
waldi801

Hast du denn schon einmal probiert ob der DMS alle 4 Tuner gleichzeitig ansprechen kann? Eventuell mal 4 gleichzeitige Aufnahmen starten.

Link to post
h0ly0ne

Danke für die schnelle Antwort zu meinem Thema @waldi801,

 

also ich habe es nur wirklich testen können, indem ich den DMS aus der Aufrufkette entferne - dann waren

alle 4 gleichzeitige Verbindungen auf verschiedenste Transponder möglich - also möchte ich einmal ein

reines "Empfangsproblem" auf der Seite des OCTONET ausschließen.

 

Wenn der DMS in der Kette ist, bekomme ich maximal einen Stream/einen Tuner, vom OCTONET aus gesehen, verbunden.

 

Grüße,

Oliver

Link to post
Griga

Die Fehlermeldung von OCTONET hast du gesehen?

 

vor 52 Minuten schrieb h0ly0ne:

13.01.21 08:01:55.048 TRTSPNetworkStream   SETUP ?fe=2&freq=586&msys=dvbc&sr=6900&mtype=256qam&pids=0&x_ci=2

RTSP/1.0 455 Method Not Valid in This State

 

Man könnte vermuten, dass die Anforderung eines CI durch die Setup Request den Fehler auslöst. Das hast du vermutlich in den DMS-Optionen -> Hardware -> Einstellungen für das RTSP Device konfiguriert.

 

Den Frontend-Parameter sollte man nur verwenden, wenn er zwingend notwendig ist und man weiß, was man damit tut, nicht "einfach so". Der Schuss kann leicht nach hinten losgehen.

 

Das Posten von Log-Ausschnitten (und diese womöglich auch noch bearbeitet) ist meistens schlecht. Es sollte immer eine komplette support.zip sein, um den Fall im Kontext beurteilen zu können. Hier fehlt insbesondere die svchardware.xml für weitere Einblicke.

 

Link to post
h0ly0ne

Zwischenzeitlich hatte es jetzt einen Tag komischerweise problemlos mit zwei Clients funktioniert - nach einem Reboot jedoch sieht es heute wieder

genauso düster aus wie ich vermeldet habe - als würde der Media Server zwingend immer den gleichen RSTP Tuner verwenden - obwohl vier Stück

vorhanden wären. Anbei die Support.zip vom Testfall.

support.zip

Link to post
Griga

Deine Konfiguration:

  • Ein MegaSat Sat>IP Server, vertreten durch ein RTSP Network Device für DVB-S(2) in der Hardwareliste des Mediaservers.
  • Ein OctopusNet Sat>IP Server, vertreten durch vier RTSP Network Devices für DVB-C in der Hardwareliste des Mediaservers. Dies setzt voraus, dass in OctopusNet mindestens vier unabhängige DVB-C-Tuner verfügbar sind, sonst sind es zu viele.
  • Der DVBViewer Media Server versorgt den DVBViewer via Sat>IP, vertreten durch vier RTSP Network Devices in der Hardwareliste des DVBViewers, alle vier für DVB-C, keiner für DVB-S(2). Absicht? Wenn der DMS die Aufnahmen durchführt, reichen im DVBViewer zwei RTSP-Network Devices für DVB-C (für Wiedergabe im Hauptfenster und Bild-in Bild), aber es sollte noch eines für DVB-S(2) dabei sein.

Zwei Konfigurationsfehler, auf die ich bereits hingewiesen habe:

  • Alle vier RTSP Network Devices für OctopusNet sind unnötigerweise mit dem FrontEnd-Parameter fest an einen physikalischen Tuner im Server gebunden. Damit erreichst du gar nichts, außer die flexible Zuordnung von Tunern an Clients in OctopusNet zu sabotieren.
  • Alle vier RTSP Network Devices für OctopusNet sind so konfiguriert, dass sie beim Session-Setup die Verwendung eines CI-Moduls anfordern. Und wie viele CI-Module hast du in OctopusNet? Vier Stück mit vier Smartcards? Glaube ich kaum. Es sollten nur so viele RTSP Network Devices ein CI anfordern, wie tatsächlich vorhanden sind. Nur bei diesen sollte in den Hardware-Optionen des Media Servers "Hat CI Modul" angehakt sein, bei den anderen nicht.

Wahrscheinlich tritt OctopusNet beim Start der zweiten Session, mit der der Media Server ein zweites CI-Modul anfordert, in den Streik, weil das nicht umsetzbar ist.

 

Wissen muss man dazu, dass OctopusNet CI-Module fest an eine Session bindet, d.h. sie sind dann nicht mehr für weitere Sessions verfügbar, selbst wenn innerhalb der Session nur unverschlüsselte Sender empfangen werden. Dieses ziemlich unflexible Konzept hat Gründe. In dem von Astra in die Welt gesetzten Sat>IP-Standard ist keine serverseitige Entschlüsselung vorgesehen. Pay TV-Kunden von Astra würden es nicht hinnehmen, wenn ein Server mit nur einer Smartcard entschlüsselt, aber den Stream in sämtliche Zimmer einer Wohngemeinschaft sendet. Jedes Empfangsgerät soll gefälligst eine eigene Smartcard benötigen! Als Digital Devices eine serverseitige Entschlüsselung eigener Machart spezifiziert und eingeführt hat, musste die Firma deshalb vorsichtig sein, um keine Schwierigkeiten zu provozieren, und konnte das von den PCIe-Karten der Firma bekannte wesentlich flexiblere CI-Konzept nicht in OctopusNet übertragen.

 

Link to post
h0ly0ne

Hallo Griga,

 

danke für das Feedback - bezüglich der Konfigurationsfehler:

 

* Frontend-Konfiguration: Diese habe ich nur aus Verzweiflung (und Test) eingeführt - um vielleicht das von mir beschriebene Problem zu umschiffen

bzw. zu beheben - werde ich also jetzt wieder rausnehmen.

* Alle vier RTSP Devices (also 4xDVB-C Tuner im Octopus-Net besitzen einen (virtuellen) CI Slot und die dementsprechende SmartCard) kann ich entweder

auf "Beliebige CI", "xte CI" oder "keine CI" konfigurieren - derzeit sind sie auf "Beliebige CI" konfiguriert. Es sind somit alle vier DVB-C Tuner empfangsbereit

und stehen auch gleichzeitig zur Verfügung (wenn ich z.b. die Sat>IP Clients direkt über den Octopus.NET verbinde, ohne den Umweg über den DMS).

 

Zusätzliche Dinge:

 

Der DVBS Sat>IP Server ist nur eine Teststellung - und eigentlich nicht in Verwendung (Hausanlage ist vorhanden, wird aber nicht wirklich benötigt) - darum

ist auch dementsprechend nur die RTSP Verbindung vorhanden und nicht mehr diesbezüglich.

 

Es sieht fast so aus, wenn ich quasi den Hop über den DMS mache hier irgendwie die Verbindungen als "eine" vom Octopus.NET aus gesehen werden

(aber irgendwie dann nicht immer bzw. nur neuerdings) - baue ich von die RTSP Connections direkt von den Sat>IP Clients auf, werden die vier Tuner nach

der Reihe belegt und ein gleichzeitiger Betrieb ist gewährleistet. Mir ist durchaus bewusst das ich maximal vier Clients damit betreiben kann (wenn ich davon

ausgehen das bei vier Tuner jeder andere Transponderbereiche nutzen wil) - aber derzeit spiegelt es sich so wieder, als wäre maximal "1" Tuner maximal

belegbar - und das sieht mir hier irgendwie unlogisch aus.

 

Grüße,

Oliver

Link to post
Griga
vor 11 Minuten schrieb h0ly0ne:

aber derzeit spiegelt es sich so wieder, als wäre maximal "1" Tuner maximal belegbar - und das sieht mir hier irgendwie unlogisch aus.

 

Laut svcdebug.log werden zwei Sessions gestartet, aber bei der zweiten reagiert OctopusNet auf das Setup mit einem Fehlercode. Das hatte ich bereits gepostet. D.h. OctopusNet hält das, was der Media Server will, aus irgendeinem Grund für nicht realisierbar. Die anderen Clients, mit denen es klappt, fordern wahrscheinlich kein CI an. Nimm das raus und versuche es dann noch mal.

 

Grundlegender Irrtum: Der Media Server als Sat>IP Client belegt keine Tuner in OctopusNet. Er startet Sessions, überträgt Empfangsparameter und fordert Daten an. Die Zuweisung von Tunern zu Setup-Requests obliegt normalerweise allein OctopusNet, außer wenn du du mit dem FrontEnd-Parameter dazwischenpfuschst.

 

Link to post
h0ly0ne

Hallo nochmal,

 

ich konnte zwischenzeitlich mit deinem Ansatzpunkt zumindest temporär etwas Stabiles konfigurieren.

Leider konnte ich in den Unterlagen keine genaue Definiton der Parameter in der "svchardware.xml" finden,

jedoch konnte ich folgenden Paramter isolieren der anscheinend bei mir das Fehlverhalten auslöst:

 

<entry name="isRS">2</entry>

 

Wenn ich diesen auf 1 stelle, scheinen alle vier Tuner zu funktionieren - jedoch nur zwei mit Inhalten die

eine CI benötigen.

 

Wenn ich diesen jetzt auf 2 stelle, kann ich mit allen vier Tuner Inhalt darstellen der eine CI benötigt

(mal davon abgesehen das zwingend bei der Hardwarekonfiguration im DMS bei jeder RTSP Verbindung

"Beliebige CI" ausgewählt sein muss - bei einer Bindung auf eine CI habe ich bei keiner Verbindung

Inhalt der eine CI benötigt)

 

Mir ist noch aufgefallen das in der "svchardware.xml" folgender Paramter geändert wird, je nachdem

was ich bei dem CI Feld in der RTSP Verbindung z.b. auf CI1, CI2 bzw. auf "Keine CI", "Beliebige CI" einstellen,

obwohl seine Namensgebung ein anderes Verhalten vermuten lässt?!:

 

<entry name="RTPUseTCP">0</entry>

 

0 = Keine CI

1 = Beliebige CI

2 = CI#1

3 = CI#2

 

Aber danke auf jeden Fall mal für die Aufklärung und den Denkanstoß in die richtige Richtung.

 

Grüße,
Oliver

Link to post
Griga
vor 5 Stunden schrieb h0ly0ne:

<entry name="isRS">2</entry>

 

Der Eintrag mit dem Wert 2 besagt, dass ein OctopusNet Server erkannt wurde. Der Wert 1 würde besagen, dass der Media Server Client eines anderen DVBViewer Media Servers im Netzwerk ist. 0 steht für einen unbekannten Server. Die Anforderung eines CI findet nur mit dem Wert 2 statt, weil die Methode spezifisch für OctopusNet ist.

 

Die Feldbezeichnungen isRS und RTPUseTCP bezogen sich ursprünglich allein auf den DVBViewer Media Server als Client eines anderen DVBViewer Media Servers (früher Recording Service, RS). Später, als eine spezielle Kommunikation mit OctopusNet wegen der CI-Unterstützung nötig wurde, wurde die Bedeutung der Felder erweitert, aber die Bezeichnungen aus Kompatibiltätsgründen beibehalten. Es ist nicht vorgesehen, dass ein Anwender damit herummurkst.

 

vor 6 Stunden schrieb h0ly0ne:

Wenn ich diesen auf 1 stelle, scheinen alle vier Tuner zu funktionieren - jedoch nur zwei mit Inhalten die eine CI benötigen.

 

Mit der Manipulation hast du praktisch die Anforderung eines CI bei OctopusNet außer Kraft gesetzt (wenn auch unsachgemäß), mit dem von mir vorhergesagten Erfolg. Du hättest jedoch einfach für alle mit OctopusNet verbundenen RTSP Network Devices "Kein CI" einstellen sollen. Das hätte meiner Empfehlung (bereits im vierten Post!) entsprochen und die gleiche Wirkung gehabt. 

 

Wenn du trotzdem CI-Funktionalität erhälst, könnte das an gewissen Plugins liegen, die du verwendest. Dies hat jedoch nichts mit OctopusNet zu tun und wird in diesem Forum weder diskutiert noch unterstützt. Damit musst du selbst zurechtkommen oder an anderen Stellen Rat suchen.

 

Auf krummen und nicht für Anwender vorgesehenen Wegen am Media Server herumzubasteln, anstatt die hier gegebenen Hinweise zu befolgen, kann weitere Probleme mit sich bringen, deren Ursache du dann nicht durchschaust. Also lasse es besser. Alles, was du brauchst, kannst du auch in den Media Server-Optionen -> Hardware einstellen.

 

  • Thanks 1
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...