[Octopus NET Pro und Sat>IP] Fehler beim Umschalten (Tele 5 SD --> kabel eins SD)

    Hallo.

    Ich habe recht häufig Aufnahmefehler und kann diese nun, nach längerer Suche, zuverlässig reproduzieren.

    Bei mir im Einsatz sind eine Octopus NET Pro mit 8 Tunern.

    Das Problem tritt unabhängig der Firmware auf. Ich habe für deinen Test auch auch ein Downgrade gemacht.

    Auch habe ich den VDR direkt mit einem 10 m Netzwerkkabel an der Octopus angeschlossen um die Verkabelung als Ursache auszuschließen.

    Das satip-plugin starte ich mit folgenden Parametern:

    --plugin=satip -d 6 -s 192.168.139.201|DVBS2-4|OctopusNet:0x80 -S

    Code
    satip.CICAM = 0 0
satip.DisabledFilters = 
satip.DisabledSources = 
satip.EnableCIExtension = 0
satip.EnableEITScan = 1
satip.EnableFrontendReuse = 0
satip.OperatingMode = 3
satip.TransportMode = 0

    Die Aufnahmefehler entstehen, wenn ich eine Aufnahme laufen habe und Live auf einen Sender des gleichen Transponders schalte.

    z.B.

    Aufnahme: Arte HD

    Live TV: Das Erste HD

    In der Konstellation wird nur ein Tuner von der Octopus Net verwendet und es gibt nur einen aktiven Stream.

    Die Fehler sehe ich mit folgendem Befehl, sobald ich auf den Sender des gleichen Transponders schalte.

    tail -f /var/log/messages | grep -E 'error|switching'

    Gleiches konnte ich auch auf dem Sat1/ Pro7-Transponder feststellen.

    Schalte ich auf einen Sender eines anderen Transponders, kommen keine Fehler.

    Hat jemand eine Idee woran das liegen kann?

    Ob das mal jemand mit einer Octopus Net mal nachstellen kann?

    Vielen Dank

    Gruß

    Heiko

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Mir fällt zumindest mal was in deiner Konfiguration auf, ohne dass das der Grund für dein Problem sein muss:

    Quote from heifisch

    DVBS2-4

    Bedeutet, dass deine OctopusNet 4 Tuner hat, sollte besser DVBS2-8 heißen.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Quote from kfb77

    sollte besser DVBS2-8 heißen.

    nur wenn er auch alle 8 Tuner diesem VDR zur Verfügung stellen will. Vielleicht hat er ja noch einen weiteren Client

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Gut, das scheint dann nicht korrekt zu sein.

    Ich werde das ändern.

    Der Fehler tritt aber auf, wenn nur ein Tuner benutzt wird. Wird also nicht die Ursache sein.

    Aber Ihr habt diese Probleme nicht?

    Kann es am Client liegen wenn der Stream aufgedrösselt wird?

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Quote from Dr. Seltsam

    nur wenn er auch alle 8 Tuner diesem VDR zur Verfügung stellen will. Vielleicht hat er ja noch einen weiteren Client

    Dafür sorgt -d 6: 6 Tuner verwenden, Rest für andere.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Quote from kfb77

    Mir fällt zumindest mal was in deiner Konfiguration auf, ohne dass das der Grund für dein Problem sein muss:

    Bedeutet, dass deine OctopusNet 4 Tuner hat, sollte besser DVBS2-8 heißen.

    Ich habe das geändert, es hat aber keinen Einfluss auf dieses Verhalten...

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Quote from heifisch

    :0x80 -S

    Versuche es mal ohne das. Das ist noch ein Unterschied zu meinen Einstellungen.

    Ich kann das Problem nicht 1:1 nachstellen, da mein VDR kein Frontend hat. Mit 2 Aufnahmen von deinen Beispiel Kanälen geht es bei mir ohne Fehler.

    VDR

    Server: Ubuntu 24.04 headless VDR im LXC Container, Plugins: satip (Octopus NET SL SX8), live, epgsearch, epg2vdr, markad

    Clients: LibreELEC auf RasPi3 und RasPi 3+

    Quote from kfb77

    Versuche es mal ohne das. Das ist noch ein Unterschied zu meinen Einstellungen.

    Ich kann das Problem nicht 1:1 nachstellen, da mein VDR kein Frontend hat. Mit 2 Aufnahmen von deinen Beispiel Kanälen geht es bei mir ohne Fehler.

    Danke für das Testen und die Hinweise.

    Ohne :0x80 habe ich keine Aufnahmefehler beim Umschalten.

    Jedoch bekomme ich dann wieder das Problem beim Umschalten zwischen Tele5 und Kabel 1, welches ich hier beschrieben hatte:

    Die Auflösung des Stream wird beim Umschalten nicht korrekt erkannt und es kommt zu Clear Meldungen.

    -S hat keinen Einfluss auf das Verhalten.

    Also würde ich davon ausgehen, dass Fehler im satip-Plugin die Ursache für die Probleme sind.

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Das Umschaltproblem sieht für mich mehr nach einem Problem im Ausgabedevice aus. Probier doch mal softhddevice und vergleiche.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Quote from heifisch

    Ohne :0x80 habe ich keine Aufnahmefehler beim Umschalten.

    Code
    0x80: Fix re-tuning bug by teardowning a session

    Na wenn du extra eine Satip Session beendest, dann werden auch ein paar TS Pakete fehelen, denk ich doch mal.

    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler
    Display Spoiler


    to spoil
    verderben
    beschädigen
    plündern
    behindern
    berauben
    vereiteln
    rauben
    zerstören [fig.] [verderben, verunstalten]
    vergällen
    verhageln [fig.]

    Quote from Dr. Seltsam

    Das Umschaltproblem sieht für mich mehr nach einem Problem im Ausgabedevice aus. Probier doch mal softhddevice und vergleiche.

    Das hatte ich schon mit softhddevice-cuvid probiert. Da hatte ich beim Umschalten auch öfters Bildfehler, aber zumindest hatte sich der VDR dabei mit clear -Meldungen nicht aufgehängt. Allerdings gab es andere Probleme mit dem Plugin z.B. beim Schneiden von Aufnahmen, so dass ich wieder zurück zu softhdcuvid gewechselt bin.

    jojo61 hat zu dem Thema gemeint, dass man da nichts machen kann, wenn der Stream falsche Daten liefert.

    Deshalb bin ich am probieren, ob irgend welche satip Parameter das Problem beseitigen.

    Mit dem quirk:

    Code
    0x80: Fix re-tuning bug by teardowning a session

    war zumindest das Umschaltproblem weg.

    Allerdings habe ich mir damit die Aufnahme-Fehler eingefangen.

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Softhddevice unterliegt einer aktiven Weiterentwicklung. Es werden durch lnj ständig Probleme im git gefixt. Probier mal eine aktuelle Version.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Quote from heifisch

    Allerdings habe ich mir damit die Aufnahme-Fehler eingefangen.

    Was mir beim Drüberfliegen nicht klar wurde, sind das sichtbare Fehler oder siehst Du die Fehler nur im syslog?

    Eine Erklärung hat ja wirbel geliefert, 0x80 killt aktiv satip sessions, was den Verlußt einiger bzw. evtl. aller TS Pakete erklärt.

    Quote from heifisch

    hat zu dem Thema gemeint, dass man da nichts machen kann, wenn der Stream falsche Daten liefert.

    Deshalb bin ich am probieren, ob irgend welche satip Parameter das Problem beseitigen.

    Für den falschen (Inhalt des) TS Streams kann ja der SAT>IP Server eigentlich nichts, der setzt diesen ja nur von SAT auf IP um.

    Evtl. sollte das Umschaltproblem doch nochmals näher betrachtet werden. Hat einer der o.a. Sender vmtl. eine eher unübliche abweichende Auflösung?

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

    Edited once, last by fnu (November 7, 2023 at 2:14 PM).

    Quote from Dr. Seltsam

    Softhddevice unterliegt einer aktiven Weiterentwicklung. Es werden durch lnj ständig Probleme im git gefixt. Probier mal eine aktuelle Version.

    Gerade eben mit softhddevice -cuvid Version 2.0.6-GIT63983d6 probiert:

    Immer mal Bildfehler beim Umschalten zwischen Tele5 und Kabel1, aber keine Hänger.

    Aber immer noch Probleme beim Schneiden von Aufnahmen.

    Beim Verschieben der Schnittmarken wird das Bild nicht aktualisiert.

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Quote from fnu

    Was mir beim Drüberfliegen nicht klar wurde, sind das sichtbare Fehler oder siehst Du die Fehler nur im syslog?

    Ich sehe die Fehler im syslog.

    Man sieht die Bildfehler beim Abspielen der Aufnahme und checkts findet auch Fehler.

    Quote from fnu

    Eine Erklärung hat ja wirbel geliefert, 0x80 killt aktiv satip sessions, was den Verlußt einiger bzw. evtl. aller TS Pakete erklärt.

    Für den falschen (Inhalt des) TS Streams kann ja der SAT>IP Server eigentlich nichts, der setzt diesen ja nur von SAT auf IP um.

    Ja, das war nur ein Versuch, der das eine Problem verschwinden lies und ein neues hervor brachte...

    Quote from fnu

    Evtl. sollte das Umschaltproblem doch nochmals näher betrachtet werden. Hat einer der o.a. Sender vmtl. eine eher unübliche abweichende Auflösung?

    Ja, das glaube ich mittlerweile auch.

    Ein unübliches Verhalten liefert z.B. Kabel 1 mit dem ständigen Wechsel zwischen interlaced und progressive., wie hier beschrieben.

    Die Auflösung ändert sich eigentlich nicht.

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

    Ok, nur der Vollständigkeit halber, Kabel 1 / Tele5 in SD oder HD?

    HowTo: APT pinning

    Click for my gear

    [¹] Intel NUC Kit NUC7i5BNH, Akasa Newton S7, 8GB DDR4, WD Black SN700 500GB NVMe, Crucial MX500 2TB, CIR, SAT>IP, Ubuntu LTS 18.04.5, VDR 2.4.1 (15W)
    [²] Intel NUC Kit NUC7i3BNH, 8GB DDR4, WD PC SN520 250GB NVMe, Crucial MX500 1TB, CIR, SAT>IP, Ubuntu LTS 20.04.1, VDR 2.4.1 (13W)
    [³] BQ500, Asrock X470D4U, AMD Ryzen 5 5600, 32GB DDR4 ECC, 2x WDC SN750 512GB, 4x Samsung SSD 4TB, 1x Samsung SSD 8TB, 1x Crucial MX500 500GB, 1x WDC Blue SSD 500GB, Windows Server 2019 Hyper-V (35W)
    [⁴] Jultec JPS0501-12AN, JPS0501-8M2, Octopus Net (DVBS2-8) & openHABian 3.3.0

    Quote from heifisch

    Man sieht die Bildfehler beim Abspielen der Aufnahme und checkts findet auch Fehler.

    Wenn checkts Fehler findet, braucht man sich über Bildfehler beim Abspielen der Aufnahme nicht zu wundern.

    Quote from jrie

    Wenn checkts Fehler findet, braucht man sich über Bildfehler beim Abspielen der Aufnahme nicht zu wundern.

    Klar, ging wohl um die Frage, ob ich die Fehler nur im syslog sehe, oder ob die Aufnhamen auch beschädigt werden.

    Gentoo Linux ~ VDR 2.6.9 ~ DD Octopus NET V2 S2 Max - SAT>IP ~ LENOVO ThinkServer TS200V ~ Intel(R) Core(TM) i5 CPU680@3.60GHz ~ 16GB RAM ~ NVIDIA T400

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login