SATIP und Transfer-Mode

    LNB: DUR-line UK 104-4+2

    Ich überlege auch auch, ob das LNB einen Defekt hat.

    Die Anzeige im Octopus steht allerdings bei allen Empfänger immer bei 100%. Auch die Signalinformation im VDR steht auf Maximum.


    Nein, kein osdteletex-Plugin installiert.


    Leider weiß ich nicht, wie man eine debug Ausgabe einbaut.

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

    Zitat von wirbel

    Ich vermute mal, dass ifconfig das melden würde.

    Auch bei UDP?

    Ich bin da gerade etwas unsicher.


    Eventuell liefert netstat -s was?


    Zitat von rkp

    Jan 28 21:36:57 ubuntu-yavdr4 vdr: [3448] SATIP: Detected 1 RTP packet error [device 1]

    Das würde ich jedenfalls für einen Netzwerkfehler halten.


    Ich würde es mal mit "RTP-over-TCP" probieren, die Octopus soll das ja können.

    Die Octopus-Firmware ist aktuell?



    Sind eigentlich diese SATIP: Idle timeout - releasing normal?

    Die kamen in dem Log-Ausschnitt immer ein paar Sekunden vor den Fehlern.

    Gruss
    SHF


    Ich gehe mal davon aus das die octupus an dem Unicable Anschluss hängt.

    Ich hatte ähnliche Probleme mit einem Unicable LNB von Inverto. Vermutlich kam der LNB mit dem Scan nicht zurecht, da der LNB da ständig Ein und Ausgeschaltet wird uns sich dann irgendwann aufhängt.

    Abhilfe konnte ich durch einen Quad/Quattro LNB schaffen.

    VDR 4: AMD Kabini 5310, Asrock AM1H-ITX, Gen2Vdr V6, Cine S2, Atric , Harmony 515 , Streacom ST-F7CB EVO

    Zitat von SHF

    Ich würde es mal mit "RTP-over-TCP" probieren, die Octopus soll das ja können.

    Die Octopus-Firmware ist aktuell?

    Die Octopus-Firmware ist aktuell. Ich habe auch mal die Beta getestet, keine Verbesserung.


    RTP-over-TCP habe ich jetzt eingestellt. Ich beobachte das jetzt.

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

    Zitat von rookie1

    Ich gehe mal davon aus das die octupus an dem Unicable Anschluss hängt.

    Ich hatte ähnliche Probleme mit einem Unicable LNB von Inverto. Vermutlich kam der LNB mit dem Scan nicht zurecht, da der LNB da ständig Ein und Ausgeschaltet wird uns sich dann irgendwann aufhängt.

    Abhilfe konnte ich durch einen Quad/Quattro LNB schaffen.

    Ja, der Octopus hängt an einem Unicable Anschluss. Komisch ist nur, dass das ein Jahr problemlos funktioniert hat. Erst nach einem yavdr-Update fing das Problem an. Ich habe schon 2 komplette Neuinstallationen vorgenommen, die Fehler treten immer wieder auf. Nur meine alte yavdr-Version, die ohne Update, arbeite einwandfrei. Führe ich hier ein Update aus, ist das Problem da. Aber dieses scheint komischerweise nur bei mir aufzutreten, andere haben das offenbar nicht.

    Quad/Quattro LNB halte ich mal als letzte Option im Auge.

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

    Tja, zu früh gefreut: es kommt mit dem Patch zwar seltener vor, aber tritt doch noch auf.

    Ursache ist, dass alle Devices in SatIP belegt sind, obwohl der VDR nicht mehr alle benutzt und einen neuen belegen will. Mit dem angehängten Patch und --trace=0x0100 als Parameter für SatIP sieht das dann im Log so aus:


    Irgendwie schafft es SatIP doch noch, die ersten beiden meiner 4 zugewiesenen Devices des OctopusNet doppelt zu belegen nachdem ich das mit dem Patch eigentlich beseitigt hatte.

    Wer mitdebuggen will kann ja den Patch mal installieren, zumindest gibt es dann eine "no assignable frontend found" Fehlermedung im Log wenn kein Device mehr frei ist

    Ich rätsele gerade wie Satip intern arbeitet: da ist offenbar noch eine Verwaltungsschicht dazwischen. Also keine direkte Zuordnung VDR-Device <-> Satip-Device, sondern das Plugin verwaltet die Devices nochmal und kommt da scheinbar durcheinander, deshalb ist unten im Log 2x id=1 TP=111493 zu sehen oder ich verstehe das falsch. Kann das evtl. jemand erklären?

    Ich hatte jetzt über 10 Minuten den Transfer-Mode-Error während eine Aufnahme lief. Die Aufnahme funktionierte aber fehlerfrei und konnte auch während des Aufnehmens angesehen werden. Nach Beenden der Wiedergabe wurde aber kein Live-TV angezeigt da es immer noch den Transfer-Mode-Error gab. Erst nach Beenden der Aufnahme funktioniert Live-TV wieder.


    Soweit ich es verstehe gibt es bei dem plugin Satip devices, mit der Anzahl die das Plugin mitbekommen hat (per default 2, optional mehr oder weniger).

    Meldet ein Server Sat und ein zweiter Kabel-TV, bietet das device gegenüber VDR (SAT + KABEL) an. Eventuell limitiert auf bestimmte Satelliten, siehe commandline help.


    Jedenfalls ein logisches OR aus den Sources aller Server.


    Keinem dieser satip devices ist aber einem verfügbaren Server oder gar einem Device auf einem der Server zugeordnet. Vielleicht gibt es sogar devices, die nie belegt werden können.


    Benötigt VDR ein device und fragt nach ProvidesSource/-Channel etc, wird gesucht welcher SAT>IP server ein passendes freies device anbietet und dieses temporär zugeordnet und nach Benutzung wieder (IDLE timeout) frei (zurück-)gegeben.

    Danke, so verstehe ich das auch. Es gibt 6 Listen mit Devices für die 6 verschiedenen Empfangsarten, die er durchsucht.

    Allerdings scheint er zu vergessen, welche Transponder er getuned hat wenn er welche löschen will, denn TP 110773 ist auf den 4 DVB-S2-Devices nicht gesetzt - oder ich verstehe noch etwas falsch.

    Ich denke (momentan?), da kommt bei der Device-Zuordnung etwas durcheinander. VDR verwaltet ja (bei mir) 4 SAT-Devices bereits und SatIP verwaltet sie nochmals, aber wenn VDR einen Kanal auf einem Device anfordert ist der ja aus VDR-Sicht frei. Im oben angegebenen cSatipFrontends::Assign() merkt dann SatIP, dass es keinen freien Device mehr hat, deshalb kommt von dort die Fehlermeldung.

    To be continued ....

    Hier nochmal die neuesten Erkenntnisse: Satip kommt bei der Device-Zuweisung durcheinander, schön zu sehen im Log unten.

    Beim cSatipFrontends::Assign() sucht er nach einem Frontend, dass frei ist oder dieser deviceID zugeordnet ist. Da nimmt er dann das nächste freie (#2) und weist diesem den Transponder 111361 zu.

    Beim anschließenden cSatipFrontends::Attach() wird aber nicht nach der deviceID gesucht, sondern nach dem angefragten Transponder (111361) und da gibt es bereits ein Frontend (#1) das diesen empfängt, so dass dem Frontend #1 die deviceID zugeordnet wird. Damit beginnt das ganze Dilemma, denn jetzt gibt es zwei Frontends (#1 & #2), die beide der deviceID 1 zugeordnet sind, schön zu sehen beim nächsten Request. Damit vergisst SatIP, dass Frontend #2 mit deviceID 1 gekoppelt ist.



    Wenn jetzt z.B. eine Wiedergabe startet und der VDR dann im Hintergrund die Transponder durchschaltet um das EPG zu aktualisieren, dann ist beim Beenden der Wiedergabe zwar für den VDR ein Device frei, aber nicht beim SatIP Plugin. VDR meldet das dann durch den Transfer-Mode-Fehler.




    Freigegeben wird das Frontend #2 mehr oder weniger zufällig wenn wieder der Transponder angefordert wird oder das Device den Idle Timeout erreicht.

    Code
    022-02-04T14:25:34.246943+01:00 uhdvdr vdr: [1916] SATIP: Idle timeout - releasing [device 1]
2022-02-04T14:25:34.247366+01:00 uhdvdr vdr: [1916] SATIP9: bool cSatipFrontends::Detach(int, int) Detach deviceId 111361 (TP 1):
2022-02-04T14:25:34.247455+01:00 uhdvdr vdr: [1916] SATIP9: bool cSatipFrontends::Detach(int, int) status Frontend DVB-S2/#1 id: 1 atta TP:111641
2022-02-04T14:25:34.247522+01:00 uhdvdr vdr: [1916] SATIP9: bool cSatipFrontends::Detach(int, int) status Frontend DVB-S2/#2 id: 1 atta TP:111361
2022-02-04T14:25:34.247583+01:00 uhdvdr vdr: [1916] SATIP9: bool cSatipFrontends::Detach(int, int) detached deviceID 1 (TP 111361) from DVB-S2/#2


    soweit die "guten" Nachrichten, eine Idee wie man das beheben kann habe ich aber nicht :( da die ganze Zuordnungslogik recht komplex ist und z.B. nicht jedem Assign() ein Attach() folgt

    Bei mir besteht das Problem noch immer. Ich sehe, dass der obige Patch 100 mal runtergeladen wurde. Kann jemand bestätigen, dass der Patch das Problem beseitigt?

    Intel NUC 10 NUC10i3FNH, Digital Devices Octopus NET V2 Max M4, 1000 GB Samsung 970 Evo M.2 2280 PCIe 3.0 x4 NVMe, LG OLED 77CX9LA

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden