SAT>IP server des media Servers antwortet zu langsam auf RTSP SETUP, anscheinend wenn dies erster Request ist -> Client timeout

[wulf 21]

Hallo,

ich möchte gerne einen Client mit dem Mediaserver per SAT>IP (RTSP) verbinden. Bei dem Client handelt es sich um einen VU+ SOLO SE receiver mit OpenATV 7.3 image. Dieses enthält ein (extra herunterladbares) SAT>IP Client plugin. Es findet den DVBViewer Media Server ohne Problem, aber das Streamen des Signals funktioniert nicht. (weder Sender, noch im "Signalfinder", welcher die Signalstärke eines Transponders anzeigt)

 

Nach Fehlersuche und Reproduktion komme ich zu dem Schluss, dass es sich hier höchstwahrscheinlich um ein Problem mit der Mediaserver Software handelt.

 

Ein Wireshark trace, welcher lokal auf dem gleichen Rechner wie der Mediaserver läuft (wireshark_trace.zip -> wireshark_net_dump.pcapng) zeigt, dass der verwendete Client nach dem Verbindungsaufbau direkt SETUP sendet (was nach meinem Verständnis der Spezifikation des SAT>IP Protokolls erlaubt ist). Jedoch kommt die Antwort 200 OK erst nachdem der Client bereits das Schließen der Netzwerkverbindung angefordert hat (wahrscheinlich nach Timeout nach 4 Sekunden). Die falsche Reihenfolge der Pakete (noch Daten nach Ende der Verbingung) führt zu connection reset durch client.

Dieser Trace wurde entsprechend Anleitung während der Erstellung der support.zip reproduziert. svcdebug.log zeigt, dass das eigentliche tunen nur 2 sekunden dauert und die Antwort eigentlich dann schon bereitseht. Trotzdem wird die Antwort erst weitere 2 Sekunden später tatsächlich als Paket rausgeschickt und der Client schließt die Verbindung.

06.02.24 21:03:24.274 TRTSPWebserver       ClientConnect    04440740
06.02.24 21:03:24.322 SetStandbyBlock      RTSP-Client 192.168.178.22
06.02.24 21:03:24.322 TServiceMain         AddReference     RTSP-Client 192.168.178.22: 1
06.02.24 21:03:24.322 TRTSPUDPClient       SendBufSizeUDP   13280000
06.02.24 21:03:24.322 TRTSPUDPClient       SetTuner         TType: 0, Freq: 314000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 0, VPID: 0, PMT: 0, SID: 0, TID: 0, NID: 0, SatMod: 0, DiseqCVal: 0, Flags: 0, Group: 0
06.02.24 21:03:24.388 TBDATwinhan          OpenDevice       bvTwinhan
06.02.24 21:03:24.388 TRTSPUDPClient       AllocateHardware TechniSat Mantis DVBC BDA Receiver
06.02.24 21:03:24.388 TRTSPUDPClient       SetTuner         Got new hardware
06.02.24 21:03:24.388 TBDATwinhan          SetTuner         TType: 0, Freq: 314000, Symrate: 6900, LOF: 0, Tone: 0, Pol: 5, DiseqC: 0, FEC: 0, APID: 0, VPID: 0, PMT: 0, SID: 0, TID: 0, NID: 0, SatMod: 0, DiseqCVal: 0, Flags: 0, Group: 0
06.02.24 21:03:26.324 TRTSPUDPClient       SetTuner         Tuner set
06.02.24 21:03:26.325 SETUP                200              freq=314&msys=dvbc&mtype=256qam&sr=6900&pids=none
06.02.24 21:03:28.270 TRTSPWebserver       ClientDisconnect 04440740

Ich habe hier verschiedene Möglichkeiten bedacht, woran es liegen könnte, folgendes konnte ich ausschließen:

- langsames Netzwerk -> Netzwerk is Ethernet-kabelverbindung an gleichem Switch (in Fritzbox integriert), PC mit media server mit 1 GB, die Box mit dem client mit 100 MB. Ping zeigt <1ms. Es war während des Tests kein größerer Traffic im Netzwerk

- Problem mit Firewall -> deaktivieren von allen Software-Firewall (windows defender und Bitdefender, sonst normalerweise nur Bitdefender eingeschaltet) macht keinen Unterschied.

- tuner selbst langsam -> mit DVBViewer als client funktioniert das Kanalumschalten schnell

 

Ich habe dann noch etwas experimentiert und folgendes gefunden: Egal wie oft ich es (mit dem "Signalfinder") reproduziere, es ist immer exakt der gleiche Ablauf: nach Verbindungsaufbau kommt zuerst SETUP request. Dann schließt der Client 4 Sekunden später die Verbindung. Direkt im Anschluss an diese Anforderung wird die Antwort rausgeschickt (wireshark_trace.zip -> wireshark_net_dump2.pcapng) - hier beim ersten mal 200 OK, und dann 2mal 503 Service unavailable - wahrscheinlich, weil es zu oft nacheinander war und der Tuner noch als beschäftigt galt, da wegen geschlossener Verbindung kein Teardown erfolgt:

 

Das scheint kein Zufall zu sein.

 

Ich habe dann nachgeschaut, wass DVBViewer als Client anders macht (über Loopback verbunden wireshark_trace.zip -> wireshark_loopback_dump.pcapng) und sehe, dass dieser zunächst nach OPTIONS fragt und erst dann SETUP ausführt (was in dem Fall sogar nur nach 1s beantwortet wurde):

Das ein ähnliches Verhalten zeigt auch VLC media player (wireshark_trace.zip -> wireshark_loopback_dump_vlc.pcapng) - dieser schiebt auch noch ein DESCRIBE dazwischen:

Dieser Test zeigt auch, dass die URL in Ordnung ist (ich habe im VLC Media Player die gleiche URL eingegeben, wie vom "Signalfinder" der VU Solo SE box verwendet)

 

Es scheint also wohl ein reproduzierbarer Bug zu sein - wenn nach Aufbau der TCP Verbindung zum RTSP Port als erstes Sofort SETUP gechickt wird, wartet der MediaServer aus irgendeinem Grund auf die nächte Aktivität vom Client, bevor die Antwort rausgeschickt werden kann. Die Aktivität ist hier dann leider das Schließen der Verbindung nach Timeout. Nur wenn es vorher irgendwelche andere Kommunikation auf der gleichen TCP-Verbindung gab, funktioniert alles.

 

Edit: Achso, die Angaben hatte ich noch vergessen:

TVKarte: TechniSat CableStart HD2 mit CI slot (kein Modul gesteckt), Treiber 1.1.1.502

Grafikkarte: Nvidia GeForce RTX 2080 Ti, Treiber 27.21.14.5206 (sollte aber wohl nicht relevant sein)

support.zip wireshark_trace.zip

Edited February 6, 2024 by wulf 21
Angaben zu Hardware ergänzt

[Griga]

vor 7 Stunden schrieb wulf 21:

Bitdefender

 

...enthält ein Hintergrundmodul, das TCP/RTSP-Netzwerkverkehr (und womöglich auch anderen) überwacht bzw. analysiert, was zu erheblichen Verzögerungen führt. Früher konnte man für dieses Modul Ausnahmen konfigurieren oder es durch Entfernen einer DLL ganz deaktivieren. Dies ist nicht mehr möglich. Wenn du das Timeout im Client nicht anpassen kannst, ist die vollständige Deinstallation von Bitdefender die einzige bekannte Möglichkeit, das Problem zu lösen.

 

Der DVBViewer setzt seit Version 7.2.5 sein Timeout automatisch hoch, wenn er Bitdefender auf dem PC erkennt (siehe im DVBViewer Hilfe -> Versionshinweise). Hier betraf es das anfängliche OPTIONS-Kommando. Der VLC hatte schon immer ein höheres Timeout.

 

Suche für weitere Informationen im Forum nach Bitdefender bzw. mit Google nach site:dvbviewer.tv Bitdefender. Es hatten bereits zahlreiche Anwender Probleme mit dieser Software. Wir raten deshalb von Bitdefender ab und empfehlen die Verwendung einer anderen weniger übergriffigen Sicherheitssoftware.

 

[wulf 21]

Hallo, vielen Dank für die Antwort.

 

Tatsächlich war Bitdefender für das seltsame Verhalten verantwortlich. Nach vollständiger Deinstallation ist diese spezielle Problem verschwunden. (Man sollte meinen, dass wenn man die Firewall in den Einstellungen deaktiviert, das System sich so verhält, wie wenn sie nicht installiert wäre, dem ist offenbar aber nicht so).

 

Es ging zwar zuerst immer noch nicht richtig, aber das lag offenbar am Netzwerk. Anscheinend gehen UDP-Datenpakete verloren, wenn in einem Burst mehr Daten von dem PC mit Media Server durch die Netzwerkleitung an die Fritzbox geschickt werden, als diese gerade weiterleiten kann (sie kann anscheinend keine Pakete kurz zwischenspeichern und später weiterleiten). Stellt man in der Fritzbox den Anschluss des PCs auch auf 100 Mbit/s, obwohl der mainboard Netzwerkadapter 1Gbit unterstützt, dann funktioniert alles richtig.

[Griga]

vor 2 Stunden schrieb wulf 21:

Man sollte meinen, dass wenn man die Firewall in den Einstellungen deaktiviert, das System sich so verhält, wie wenn sie nicht installiert wäre, dem ist offenbar aber nicht so

 

Was da stört, ist keine Firewall-Funktion. Firewalls erlauben oder blockieren Verbindungen nach bestimmten Regeln, aber verzögern sie nicht. In Bitdefender ist offenbar zusätzlich eine Art On Access-Scanner für Netzwerkverbindungen aktiv, d.h. er schaut sich die übertragenen Inhalte an. Warum er sich sekundenlang mit den wenigen Bytes einer RTSP Request befasst, bleibt rätselhaft. Vielleicht lädt er sie in die Cloud hoch und wartet auf das Ergebnis einer Analyse, keine Ahnung...

 

Einzusehen ist auch nicht, warum Bitdefender überhaupt in Übertragungen mit allgemein bekannten Multimedia-Protokollen innerhalb eines privaten Netzwerks eingreift. Für Netzwerkkompetenz spricht das nicht gerade. Und ein derart fragwürdiges Modul unbeeinflussbar vom Anwender mit einem eigentlich ordentlichen Virenscanner zwangszuverheiraten, erscheint mir ebenfalls ziemlich daneben

 

vor 2 Stunden schrieb wulf 21:

Anscheinend gehen UDP-Datenpakete verloren, wenn in einem Burst mehr Daten von dem PC mit Media Server durch die Netzwerkleitung an die Fritzbox geschickt werden, als diese gerade weiterleiten kann (sie kann anscheinend keine Pakete kurz zwischenspeichern und später weiterleiten).

 

Das Problem hatte ich auch mal. Seitdem kann man mit einem Tweak die maximale Output-Datenrate des Media Servers begrenzen, mit der Folge, dass solche Bursts über die Zeit "verschmiert" werden. DMSTweaker.bat im DVBViewer-Programmverzeichnis starten, dann die Einstellung "Maximale Sat>IP-Server-Bitrate in MBit/s" suchen. Mehr dazu hier und hier.

 

[Trill Ian]

Obwohl Griga recht gerne auf Bitdefender rumhackt, das muss hier nicht die Quelle allen Übels sein.

 

Dein Problem kann auch die Fritzbox sein, die ja nun mal nicht das sauberste Netzwerkgerät ist, sondern an vielen Stellen Fünfe-Gerade-sein-lässt und gefährliche Abkürzungen verwendet.

 

Hier besonders die Behandlung der "Flow Control" (bzw, das Ignorieren derselben). Diese ist essentiell nötig um die Geschwindigkeitsanpassung zwischen 1G und 100Mbit/s Netzwerken zu ermöglichen.

Wobei, in Richtung 100->1 entsteht ja kein Problem, denn die langsam ankommende Pakete kann der Switch immer ohne Verzögerung weiterleiten.

Aber andersrum (besonders beim Streamen mit hohen Datenmengen) wirds kritsch. Die eintreffenden Pakete müssen zwischengespeichert werden und bei "Puffer voll" wird dem Sender ein STOP! Paket entgegengeworfen, der hört dann auf der Switch kann seinen Puffer leeren. So ist die Idee, aber bei vielen Geräten klappt das nicht wirklich. Auch geht mal gerne das START Paket nach Pufferleerung verloren.

 

Wobei es da große Unterschiede gibt:

* "managed" Switche erledigen den Job selber. Sie puffern und stoppen/starten den Sender. Sie haben auch ausreichend Speicher um die nötigen Puffer bereitzustellen.

* "unmanaged" Switche gibt es in 2 Varianten (beide haben üblicherweise keine oder sehr kleine Puffer)

   1) "pass through" (die Érlaubnis für Flow Control wird durchgereicht, das nächste Gerät ist für die Erfüllung verantwortlich)

   2) "strip/ignore" (die Anforderung wird verworfen, das endet oft im Chaos)

 

Wobei gilt:

* immer, wenn Geschwindigkeitsanpassungen erforderlich sein, benötigt man eine funktionierende Flow Control.

* "alte" Geräte mit nur bis zu 100Mbit/s kennen Flow Control gar nicht, es muss zwingend von einem "managed" Switch davor erfüllt werden. Die Durchleitung endet also im Nichtverstehen.

* die Fritzbox is auf keinen Fall ein "managed" Switch, sie gehört wahrscheinlich zu "unmanaged 1" (so genau weiß das keiner und will es auch gar nicht wissen).

  Sie ist netzwerktechnisch betrachtet ein Spielzeug. Ihr Einsatz sollte auf die nötigsten Funktionen (Modem und ggf Telefon) beschränkt bleiben, sonst droht Ungemach.

 

Also, besorg Dir mal einen ordentlichen Switch, steck alle Kisten daran und auch die Fritzbox nur mit einer Leitung zu diesem Switch...

Vielleicht kann Dir jemand einen zum Probieren leihen, ansonsten sind die auch nicht mehr wirklich teuer.

 

Und bevor Du ins Grübeln kommst, im "Normalfalle" fällt das Problem bei dem Receiver gar nicht auf, denn üblicherweise überträgst Du die Daten (z.B. Aufnahmen) VOM Receiver (lahm) zum PC (flotter). Du willst es aber andersrum haben und da klemmts halt mit hoher Wahrscheinlichkeit.

Edited February 9, 2024 by Trill Ian

[Griga]

Am 6.2.2024 um 23:19 schrieb wulf 21:

wahrscheinlich nach Timeout nach 4 Sekunden

 

Anzumerken ist hier noch, dass ein Timeout von 4 Sekunden bei SETUP viel zu wenig ist. Das daraus resultierende Tunen im Server kann deutlich länger dauern, insbesondere bei schmalbandigen Sat-Transpondern mit geringer Symbolrate. Da besteht auch beim Sat>IP Client Plugin im VU+ SOLO SE Receiver Verbesserungsbedarf.

 

Der DVBViewer macht es so, dass er erst mit OPTIONS feststellt, ob der Server überhaupt ansprechbar ist - das geschieht außer bei Anwesenheit (oder besser gesagt: Unwesenheit ) von Bitdefender mit geringem Timeout - dem Server aber nachfolgend bei SETUP 15 Sekunden Zeit lässt.

 

[wulf 21]

Hallo,

 

On 2/8/2024 at 1:48 AM, Griga said:

Das Problem hatte ich auch mal. Seitdem kann man mit einem Tweak die maximale Output-Datenrate des Media Servers begrenzen, mit der Folge, dass solche Bursts über die Zeit "verschmiert" werden. DMSTweaker.bat im DVBViewer-Programmverzeichnis starten, dann die Einstellung "Maximale Sat>IP-Server-Bitrate in MBit/s" suchen. Mehr dazu hier und hier.

 

Vielen Dank für den Tipp, das hat das Problem behoben.

 

11 hours ago, Trill Ian said:

Obwohl Griga recht gerne auf Bitdefender rumhackt, das muss hier nicht die Quelle allen Übels sein.

 

Dein Problem kann auch die Fritzbox sein, die ja nun mal nicht das sauberste Netzwerkgerät ist, sondern an vielen Stellen Fünfe-Gerade-sein-lässt und gefährliche Abkürzungen verwendet.

 

Griga hat in diesem Fall ja gar nicht behauptet, der Bitdefender sei die Quelle allen Übels. Um es nochmal klar auseinanderzuhalten:

• Bitdefender ist schuld an dem RTSP Setup timeout Problem, das ich im Originalpost beschrieben habe
• die Fritz Box ist schuld am Verschlucken von UDP-Paketen

Nach weiteren Tests bei mir, hat sich beides als eindeutig korrekt herausgestellt. Ob ich deswegen jetzt noch einen extra Switch kaufe, oder bei dem Workaround Datenrate durch Media server begrenzen belasse, überlege ich mir.

 

10 hours ago, Griga said:

Anzumerken ist hier noch, dass ein Timeout von 4 Sekunden bei SETUP viel zu wenig ist. Das daraus resultierende Tunen im Server kann deutlich länger dauern, insbesondere bei schmalbandigen Sat-Transpondern mit geringer Symbolrate. Da besteht auch beim Sat>IP Client Plugin im VU+ SOLO SE Receiver Verbesserungsbedarf.

 

Keine Ahnung, ob das SETUP Timeout des SATP>IP clients generell zu klein ist, oder evtl. je nach Art des Tuners angepasst wird. Der Client weiß ja, dass der Server DVB-C bietet, und dafür sind die 4 Sekunden eigentlich mehr als ausreichend, wenn Bitdefender nicht dazwischengrätscht.

 

Genau genommen enspricht aber diese Verhalten des Media Servers eigentlich nicht der SAT>IP Spezifikation. Laut https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf soll der server das physische Tuning nicht abwarten, bevor er auf Requests antwortet. Stattdessen sollen nach SETUP und PLAY solange leere RTP-Pakete geliefert werden, solange das Signal noch nicht da ist und in RTCP über den aktuellen tatsächlichen Zustand des tuners informiert werden.

[Trill Ian]

vor 7 Stunden schrieb wulf 21:

Ob ich deswegen jetzt noch einen extra Switch kaufe

Na ja, extra kaufen solltest Du keinen. Kennste nicht jemanden, der irgendeinen alten managed Switch in der Ecke liegen hat ? (hier stapeln sich 5 aus den letzten Jahrzehnten)

Nur kurz ausprobieren und gut ist.

 

[Griga]

vor 23 Stunden schrieb Trill Ian:

Die eintreffenden Pakete müssen zwischengespeichert werden und bei "Puffer voll" wird dem Sender ein STOP! Paket entgegengeworfen, der hört dann auf der Switch kann seinen Puffer leeren.

 

Auch bei einem verbindungslosen Protokoll wie UDP? Auf welcher Ebene wird ein solches STOP verarbeitet? Im Media Server-Code jedenfalls nicht. Der empfängt überhaupt kein Feedback auf das, was er sendet. Ich finde zu dem Thema auf Anhieb nur sowas.

 

vor 10 Stunden schrieb wulf 21:

Laut https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf soll der server das physische Tuning nicht abwarten, bevor er auf Requests antwortet.

 

Ein guter Hinweis. Dem werde ich mal nachgehen.

 

[Trill Ian]

vor 20 Minuten schrieb Griga:

Auch bei einem verbindungslosen Protokoll wie UDP? Auf welcher Ebene wird ein solches STOP verarbeitet?

Das passiert alles schon eine Etage tiefer, auf Ethernet Layer 2. Die entsprechenden Bits sind im äussersten Frame. Der Switch braucht kein IP kennen und schon gar nicht TCP oder UDP.

Die Bits sind gut versteckt im Control Byte. Etwas mehr Info unter https://www.juniper.net/documentation/de/de/software/junos/interfaces-ethernet/topics/topic-map/flow-control-ethernet-interfaces.html

(dort wird auch beschrieben, dass es das bei Fast Ethernet (100Mbit/s) noch nicht gab, was dann zu erwähnten Problemen führt).

Nicht verwechseln mit VLANS (Pakete sind 4 Byte länger!) und QOS (Prioritätssteuerung, manche Headerbytes sind ANDERS definiert wenn Controlbit X gesetzt ist)!!!

 

Das Ganze ist also total weit entfernt von irgendeinem Programmierer. Du kannst da gar nix dran machen, das ist fest eingebaut und verdrahtet.

Nur bei managed Switchen findest Du die letzte Spalte, wo man die Funktion ein und ausschalten kann (oder auch nur eine Richtung erlauben). Üblicherweise ist sie AN (bei SFP1 steht zwar "off", aber das lügt, weil da gerade nix angeschlossen ist, kann er nicht übeprüfen, ob die Gegenstelle da mitspielt oder nicht).

 

[Griga]

Am 9.2.2024 um 22:55 schrieb wulf 21:

Keine Ahnung, ob das SETUP Timeout des SATP>IP clients generell zu klein ist, oder evtl. je nach Art des Tuners angepasst wird. Der Client weiß ja, dass der Server DVB-C bietet, und dafür sind die 4 Sekunden eigentlich mehr als ausreichend, wenn Bitdefender nicht dazwischengrätscht.

 

Genau genommen enspricht aber diese Verhalten des Media Servers eigentlich nicht der SAT>IP Spezifikation. Laut https://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf soll der server das physische Tuning nicht abwarten, bevor er auf Requests antwortet. Stattdessen sollen nach SETUP und PLAY solange leere RTP-Pakete geliefert werden, solange das Signal noch nicht da ist und in RTCP über den aktuellen tatsächlichen Zustand des tuners informiert werden.

 

Der RTSP-Server des Media Servers führt tatsächlich zwei potentiell zeitraubende Vorgänge aus, bevor er auf eine SETUP oder PLAY Request des Clients antwortet:

• Anforderung und eventuelle Initialisierung von DVB-Hardware (falls noch nicht in Betrieb)
• Tunen

Das grundlegende Problem ist, dass bei der Programmierung unbekannt ist, um was für Tuner es sich handelt und wie sie (bzw. ihre Treiber) sich verhalten. Es gibt z.B. welche, bei denen der Tune-Aufruf sofort zurückkehrt und der Treiber das Tunen asynchron im Hintergrund ausführt. Andere blockieren, bis sie ein Signal haben oder bis zu einem Timeout. Und außerdem gibt es noch virtuelle Tuner, die Remote-Tuner bzw. andere Sat>IP-Server repräsentieren... kurz gesagt ist der tatsächliche Zeitablauf bei der Programmierung nicht absehbar. Das ist bei receiverartigen Sat>IP-Servern mit fest verbauten Tunern anders.

 

Eine saubere, aber sehr aufwändige Lösung wäre, die genannten Vorgänge in einen separaten Thread zu verlagern, der zwar von Client Requests angestoßen wird, aber ansonsten zeitlich unabhängig abläuft. Das hätte jedoch drastische Folgen für die Media Server-Programmierung: Vieles, was jetzt aufgrund einer festen zeitlichen Reihenfolge einfach strukturiert linear abläuft, müsste dann "threadsicher" für asynchrone Parallelverarbeitung ausgelegt sein. Das gilt auch für Vorgänge, für die das Tunen bereits stattgefunden haben muss, wie die Auswahl der PIDs, die der Client haben will (damit er nicht unversehens Streams vom vorher eingestellten Sender erhält). Außerdem ist unbekannt, wie BDA-Treiber damit zurechtkommen, wenn sie Aufrufe aus verschiedenen Threads verarbeiten müssen, die womöglich gleichzeitig eintreffen. Wenn ein Treiber abstürzt, ist meistens ein Windows-Neustart fällig.

 

Eine entschärfte Variante der asynchronen Verarbeitung wäre, dass der Media Server ein PostMessage an sich selbst sendet, bevor er antwortet, und erst der Empfang dieser Message das eigentlich Tunen auslöst. Dies würde einen separaten Thread ersparen und garantieren, dass das Tunen nicht gleichzeitig mit anderen durch die Message Queue angestoßenen Vorgängen im Server stattfindet (das sind die meisten), sondern nacheinander. Darüber könnte man schon eher nachdenken...

Nichtsdestotrotz verhindert eine "entflochtene" Verarbeitung, dass der Client in der Antwort eine Rückmeldung über den Erfolg der Hardware-Initialisierung und des Tunens erhält. Es kann ja durchaus sein, dass der Treiber einen Fehler meldet und damit sagt "nö, mach ich nicht". Bislang reicht der Media Server sowas mit einem 404 Not Found oder ähnlichem sofort weiter, worauf z.B. der DVBViewer den Anwender informiert, dass der Sender nicht vom Server verfügbar ist. Ohne eine solche Antwort (bzw. nach einem 200 OK) wartet der DVBViewer vergeblich auf UDP/RTP-Pakete, die nie kommen. Wie sich sowas per RTCP erledigen ließe, sehe ich nicht.

 

[wulf 21]

Interessant, anscheinend benutzt der DVBViewer <-> Media Server in der Kombination features, die so im SAT>IP standard eigentlich nicht vorgesehen sind.

 

Das wird auch so in https://www.linuxtv.org/wiki/index.php/W_scan_cpp angemerkt

Quote

NOTE:

* SAT>IP servers report signal a limited set of reception stats only: Frontend lock, Signal level(0..255, w_scan_cpp translates to dBuV), Signal quality(0..15 -> 0..100%).
* Level is reported in dBuV or percent
* Quality is reported as percent
* unsupported features are not reported at all.

Die Rückmeldung 404 Not Found ist laut der Spec eigentlich nur genau für den Fall gedacht: Client fragt eine StreamID an, welche nicht existiert (bzw. Client fragt mit DESCRIBE ohne StreamId Angabe nach Liste aller Streams, im Moment ist aber kein Stream aktiv).

 

Für den Fall Client fragt etwas in Parameter, welchen der Server schon vor dem Tuning weiß, dass er es gar nicht erfüllen kann (z.B. Client fragt nach DVB-C, aber Server hat nur DVB-S. Client fragt nach Frequenz, welche Außerhalb des einstellbaren Bereichs der Tuner liegt etc.) ist 403 Forbidden mit Out-of-Range header für unerfüllbare Parameter vorgesehen.

 

Für den Fall "kein Freier Tuner" ist 503 mit No-More: frontends vorgesehen.

 

Für den Fall "ich habe einen Tuner, der das Liefern kann, was du möchtest", aber später "ach nein, hat doch nicht geklappt" scheint es nichts explizit zu geben.

 

Die einzige Möglichkeit die ich mit RTCP sehe:

• Mit frontend lock = 0 wird signalisiert tuning in Bearbeitung
• Mit frontend lock = 1 wird signalisiert tuning fertig

Also könnte man Sender nicht verfügbar (kein Signal oder Fehlerzustand) nur signalisieren, wenn lock von 0 auf 1 zurück-wechselt + signalstärke und qualität glatt = 0.

PID nicht verfügbar oder Tuner hat Kanalwechsel verweigert -> lock wechselt von 0 auf 1 und es werden die tatsächlich im Moment am Tuner eingestellten Parameter mitgeteilt.

 

Die Hardware müsste sich der SAT>IP Server eigentlich vom Standard her wohl in dem Moment anfordern/initialisieren, in dem der Server startet (bzw. die Hardware konfiguriert wird). Aber das könnte evtl. als nutzerunfreundlich angesehen werden (z.B. würde bei parallel installierten Media Server und DVBViewer, in welchem die Hardware fälschlicherweise nicht aus der Config entfernt wurde, das Tunen dann scheitern, wenn der Mediaserver nur läuft, auch wenn er gerade nichts macht). Ein Server namens minisatip, den ich mal Testweise auf der VU+ Solo SE Box hatte, hat sich jedenfalls genauso verhalten (die Hauptanwendung findet erst mal keinen Tuner mehr, wenn der Server zuerst startet)

 

Apropros Signalstärke und Qualität. Die scheint auch nicht entsprechend der Spec übermittelt zu werden.

Teilstring tuner=1,98,1,0,410,8,dvbc,256qam,6900,,,,0

Dabei ist 98 die Stärke - die wird anscheinend direkt als %-Angabe zwischen 0 und 100 angegeben, statt wie vorgesehen zwischen 0 und 255, weswegen der Client in der Box die Signalstärke im Signalfinder mit 38% angibt (DVBViewer mit 98% - 98/255=38 gerundet).

Die Qualität (basierend auf Bit/Paketfehlern) wird anscheinend überhaupt nicht übermittelt (Client zeigt SNR = 0% nach Senderwahl), aber vielleicht ist die je nach Hardware auch nicht verfügbar (und es werden nur direkt die schon Fehlerkorrigierten Pakete vom Treiber ausgespuckt) - könnte man im Zweifel defaultmäßig auf 15 setzen, wenn lesbares Signal vorhanden und keine Diskontinuitäten.

 

Aber das sind für mich nur Schönheitsfehler. Solange sonst alles glatt funktioniert stören ein paar fehlerhaft angezeigte Werte ja nicht :D.

[Griga]

vor 11 Stunden schrieb wulf 21:

Für den Fall "kein Freier Tuner" ist 503 mit No-More: frontends vorgesehen.

 

Hinsichtlich der Fehlercodes wäre wahrscheinlich mal eine Anpassung an den aktuellen Stand der Spezifikationen fällig. Der Sat>IP-Server im Media Server (früher Recording Service) ist praktisch gleichzeitig mit der ersten Fassung der Spezifikationen entstanden (damals in Kontakt mit SES Astra). Er war eine der ersten Implementationen überhaupt. Inzwischen ist wohl das eine oder andere präzisiert worden.

 

Änderungen könnten allerdings gewisse Kompatibilitätsprobleme mit Clients aus der DVBViewer-Familie (DVBViewer, TransEdit) mit sich bringen, weil es dabei spezielle Verabredungen gibt. Zum Beispiel sendet der Media Server ihnen im Fall "kein freier Tuner" zusammen mit 404 informationen darüber, welcher Sender den Tuner blockiert, worauf der DVBViewer auf diesen zwangsumschaltet. Falls es z.B. der KiKa ist, weiß Papa, dass der Kinderzimmer-Client schuld ist...

 

vor 12 Stunden schrieb wulf 21:

Die Hardware müsste sich der SAT>IP Server eigentlich vom Standard her wohl in dem Moment anfordern/initialisieren, in dem der Server startet (bzw. die Hardware konfiguriert wird).

 

...mit der Folge eines erhöhten Energieverbrauchs. Viele DVB-S-Geräte schalten die LNB Spannungsversorgung ab, wenn sie unbenutzt sind. Geräte für andere Empfangsarten legen sich womöglich sonstwie schlafen. Wenn ein BDA-Tuner einmal auf Empfang geschaltet ist, bleibt er i.a. dabei, außer man gibt ihn frei.

 

vor 12 Stunden schrieb wulf 21:

Apropros Signalstärke und Qualität. Die scheint auch nicht entsprechend der Spec übermittelt zu werden.

 

Grundsätzlich ist es unmöglich, mit BDA-Tunern die Sat>IP-Spezifikationen vollständig zu erfüllen. Das gilt insbesondere für den Tunerlock-Status sowie Signalqualität/stärke. Je nach Chipsatz und Treiber liefern Geräte herstellerspezifische Werte, wenn überhaupt. Jeder kocht in der Hinsicht sein eigenes Süppchen. Was der Media Server liefert, ist der Versuch, einen kleinsten gemeinsamen Nenner zu realisieren.

 

vor 12 Stunden schrieb wulf 21:

Die Qualität (basierend auf Bit/Paketfehlern) wird anscheinend überhaupt nicht übermittelt (Client zeigt SNR = 0% nach Senderwahl), (...)  könnte man im Zweifel defaultmäßig auf 15 setzen, wenn lesbares Signal vorhanden

 

Wäre vielleicht nicht schlecht. Wenn ich mich richtig erinnere, gab es schon mal Berichte, dass ein Fernseher als Media Server-Client nach jedem Senderwechsel "Kein Signal" einblendete.