Ruckelnde Aufnahmen mit Digibit R1

  • Hallo Leute,


    ich habe bei meinem VDR ein Problem, bei dem ich alleine nicht weiterkomme.

    Seit ich den Digibit R1 mit der AXE-Firmware verwende habe ich in meinen Aufnahmen Artefakte (Ruckeln).

    Das normale Live-TV funktioniert allerdings problemlos.


    Hier ist mein Setup:


    Satip-Server:

    * Digbit R1 mit satip-axe-201705251044.


    Vdr-Server headless:

    * Linux mint 18.1

    * vdr 2.2.0 mit Satip 2.2.5


    Client:

    * Raspberry Pi 3 mit Libreelec.

    * Anbindung an VDR mittels VNSI.


    Bevor ich den Digibit verwendet habe, hatte ich einen Sat-IP-Server von Kathrein (EXIP 414).

    Mit diesem Server hatte ich kein ruckeln in meinen Aufnahmen, Live-Tv ging ebenfalls.

    Allerdings hat sich das Ding sporadisch aufgehangen und musste Hard neu gestartet werden ... aber das ist eine anderes Thema.


    Ich habe bei meinem VDR-Server während der Aufnahmen keine nennenswerte CPU-Last (2-3%). Im Syslog gibt es meiner Meinung nach ebenfalls nichts auffälliges.

    Da ich mit der Suchmaschine meines Vertrauens keine Treffer bezügliches meines Problems gefunden habe, hoffe ich, das ihr mich auf die richtige Spur bringt.


    Gruß,

    Practical

  • Hmm,


    okay evtl habe ich eben gelogen ... es war nicht nur --devices=4 sondern auch -n gesetzt.

    Hatte früher mal mit den Parametern gespielt wegen dem Kathrein und das wohl nicht zurückgesetzt.

    Die Probleme bei den Aufnahmen sind aber weiterhin da (also ohne den Parameter -n)


    Gruß,

    Practical

  • Hi,


    die 15. er Versionen sind noch im Test und deswegen hier verlinkt :


    https://github.com/perexg/satip-axe/issues/94


    die digibit und der vdr sollten am gleichen gigabit switch hängen - keine fritzbox als switch, die hat ihre eigene agenda beim traffic shaping,

    evtl verändert das die Reihenfolge der udp pakete,


    dann bei vdr noch in der sysctl.conf etwas setzen:


    Code
    1. net.core.wmem_max=20491520
    2. net.core.rmem_max=20491520
    3. #net.ipv4.tcp_rmem= 10240 87380 125829120
    4. #net.ipv4.tcp_wmem= 10240 87380 125829120
    5. net.ipv4.tcp_mem = 65536 131072 262144
    6. net.ipv4.udp_mem = 65536 131072 262144


    und ab version 2.2.5 für satip plugin bei vdr 2.2.0 akzeptiert er folgende parameter als Beispiel (lokal anpassen, wichtig ist -r ) :


    Code
    1. --plugin=satip -d 3 -s 192.168.1.145|DVBS2-4|minisatip;192.168.1.133|DVBT2-2|minisatip -r 851968

    der minisatip auf meiner digibit hier läuft mit folgenden Parametern:


    Code
    1. minisatip7 -f -g -a 0:0:0 -H 3:25 -B 10000 -R /mnt/data/html -p http://192.168.1.145:80/playlist.m3u -D 4 -e 0-3 -l general,http,pmt


    auf der digibit ist in der letzten 15. er Version die sysctl.conf auch neu angepasst :



    damit läuft es hier, siehe auch https://github.com/perexg/satip-axe/issues/108,


    viele Grüsse pbg4

    vdr1:Produktivsystem: Zotac Box mit Atom 525/ION 2.Generation yaVDR 0.6.1 und satip plugin, mit digibit r1/minsatip
    vdr2:Zotac CI-320 vdr für ARD radio transponder und VDR Aufnahmen server yaVDR 0.6.1,.. und weiterer minisatip-server + Hauppauge WinTV-Quad HD,
    vdr3: testsystem: Shuttle NC02U mit Skylake und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..
    vdr4: testsystem: Acer Laptop ES11-132 mit Braswell und Softhddevice VAAPI/HEVC für DVB-T2, Ubuntu Zesty, VDR von Hand auf Basis yaVDR,..

    The post was edited 1 time, last by pbg4 ().

  • Hallo pbg4,


    den digibit und den VDR an den selben Switch zu hängen ist leider nicht so einfach umzusetzen.

    Daher kann ich hier nicht mal eben einen Test machen.


    Die Änderungen an der sysctl.conf plus das anhängen von -r 851968 an das satip-plugin haben leider keinen Erfolg gehabt.


    Die 15er Version von axe muss ich noch testen.


    Gruß,

    Practical

  • Hallo,


    nach langer Suche konnte ich das Problem beheben.

    Es lag am Client.

    Dort ist ein Rasperry Pi im Einsatz.

    Bei diesem war der MPEG2-Decoder nicht aktiviert.

    Allerdings haben die Aufnahmen erst bei der Umstellung auf den Digbit angefangen zu ruckeln.


    Gruß,

    Practical

  • Hi,


    fals ich ganz kurz reingrätschen :saint: darf ... welche Vorteile bringt die alternative Firmware auf dem Digibit ?

    yavdr 0.61 testing SilverStone GD04S, Intel DH77EB, Intel G1610 CPU, 4GB RAM, Zotac Nvidia GTX-630 ,Corsair 4GB, Be quiet! BN140 System Power7, Samsung 830 SSD
    4 DVB-C Tuner L4M-Flex + Twin CT. Qnap TVS-873 per NFS als Aufnahmefreigabe.Per HDMI an Denon AVR-4300H/LG OLED 65B6D

  • @Perlb: die alternative Firmware erlaubt einen stabilen/stabileren Betrieb der Dinger.

    VDR-Clients:
    Raspbian
    mit Paketen von eTobi - vdr 2.2 - Kernel: 4.1.13-v7+ Raspberry PI 1B


    Home-Server:
    Debian Jessie mit Paketen von eTobi - vdr 2.2 - Kernel 3.16.0-4-amd64

    Point of View MB-D510-MATX - 2GB RAM - Antec NSK 2480 -1 x Samsung HD154UI (/, /mnt/media/[...]) - 1 x Samsung HD154UI (/var/lib/video) - 1 x Mystique SaTiX-S2 Dual, 2 x Typhoon DVB-T PCI

  • erlaubt einen stabilen/stabileren Betrieb der Dinger

    Die normale Firmware funktioniert eigentlich ganz gut, die alternative Firmware hat vor allem den Vorteil das man da Sat>IP über TCP aktivieren kann was elementare Probleme von Sat>IP aus der Welt schafft. Das bietet außer diese alternative Firmware ja leider noch nicht mal das ultra Premium Segment.

  • Hallo Practical,


    ich habe mir eben einen Kathrein Exip 418 gekauft und komme nicht so ganz klar damit und VDR.


    MIt VLC und der Android App SAT>IP läuft es stabil (also die HW ist richtig installiert) - auch bei drei Teilnehmern.


    Ich kann ein einziges Mal einen Kanal anwählen und dieser wird auch ruckelfrei dargestellt im VDR mit vdr-satip 2.4.0 (auf Debian

    und mit e-tobi und experimental auf stretch). Sobald ich wechseln will, hängt sich das ganze auf.

    Parallel dazu sehe ich im log massenhaft davon:


    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Connect failed [device 0]

    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.2.39/ [device 0]

    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Connect failed [device 0]

    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.2.39/ [device 0]

    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Connect failed [device 0]

    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.2.39/ [device 0]

    Jun 3 13:45:50 hdtv vdr: [6134] SATIP-ERROR: Connect failed [device 0]

    Jun 3 13:45:51 hdtv vdr: [6134] SATIP-ERROR: Detected invalid status code 503: rtsp://192.168.2.39/ [device 0]


    Kannst Du mir sagen, wie Du VDR mit Deinem Exip 414 zusammen zum Laufen gebracht hast?


    Kannst Du mir Hinweise zum Debugging geben?


    Ich würde sonst nächste Woche das Gerät zurück schicken, wenn ich es nicht in Griff bekommen.


    Danke schonmal vorab für einen kurzen Hinweis :-)


    Gruß

    Joachim

    VDR Nutzer seit > 10 Jahren. Bisher TT-6400 - seit Update auf Debian Stretch kaputt - nun erste Schritte SAT>IP

  • Hi,

    Wo steht das der geht? Oben wird der 414 erwähnt als instabil.

    Was für eine Netzwerk verbindung?

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de


  • SurfaceCleanerZ wrote:

    Wo steht das der geht? Oben wird der 414 erwähnt als instabil.

    Was für eine Netzwerk verbindung?


    Aller erster Beitrag:

    Practical wrote:

    Bevor ich den Digibit verwendet habe, hatte ich einen Sat-IP-Server von Kathrein (EXIP 414).

    Mit diesem Server hatte ich kein ruckeln in meinen Aufnahmen, Live-Tv ging ebenfalls.

    Allerdings hat sich das Ding sporadisch aufgehangen und musste Hard neu gestartet werden ... aber das ist eine anderes Thema.

    Da erwähnt Practical, dass er den EXIP 414 am laufen hatte.


    Netzwerk ist bei mir ein reiner 16-Port Gigabit Switch. Sollte kein Engpass sein ;)

    VDR Nutzer seit > 10 Jahren. Bisher TT-6400 - seit Update auf Debian Stretch kaputt - nun erste Schritte SAT>IP

  • Ich glaube die Aussage sollte ehr sein "Wer sagt dir dass der 418 technisch gleich wie der 414 ist".


    Nur weil beide vom selben Hersteller kommen muss noch lange nicht das Selbe drin sein...

    Client 1 Hardware : MSI Z87-G43, I5-4570, 4 GB Ram (oversized aber war über :) ),Zotac NVidia GT630 (25 Watt),Thermaltake DH202 mit iMon-LCD ( 0038 ) und vdr-plugin-imon
    Software : yaVDR 0.6,sofhhddevice @ 1920x1080@50Hz
    Server Hardware : MSI Z87-G43, I7-4790, 16 GB RAM, 5x3 TB WD Red, Digibit-R1 (2 Devices)
    Software : Ubuntu 16.04 LTS mit yavdr-Paketen,virtualbox,diverse VM's


    Yoda: Dunkel die andere Seite ist...sehr dunkel!
    Obi-Wan: Mecker nicht, sondern iss endlich dein Toast ...

  • Ich glaube die Aussage sollte ehr sein "Wer sagt dir dass der 418 technisch gleich wie der 414 ist".


    Nur weil beide vom selben Hersteller kommen muss noch lange nicht das Selbe drin sein...

    Danke, guter Punkt. Was man so einfach unreflektiert annimmt. Du kannst gut recht haben!

    VDR Nutzer seit > 10 Jahren. Bisher TT-6400 - seit Update auf Debian Stretch kaputt - nun erste Schritte SAT>IP