Posts by sg75

    Ist bei uns (ca. 4TB Aufnahmen) auch so. Deine Vermutung klingt plausibel.

    Wenn ich mich recht erinnere, stürzt VDR beim Versuch, die "überzählige" Aufnahme zu löschen, sogar ein zweites mal ab.

    Ich betreibe meinen Rotor mit einem Sundtek-USB-DVB-S2-Stick an einem Raspberry PI.

    Das klappt stabil. Ich denke, dass die externe Stromversorgung vom Sundtek-Stick vorteilhaft für die Stabilität ist.

    Ja, USALS geht ohne Plugins mit der folgenden diseqc.conf:

    Code
    1. #
    2. # Positioner for steerable dish:
    3. #
    4. S360E 11700 V 9750 t V W20 P W20 t v
    5. S360E 99999 V 10600 t V W20 P W20 T v
    6. S360E 11700 H 9750 t V W20 P W20 t V
    7. S360E 99999 H 10600 t V W20 P W20 T V

    Und bitte nicht vergessen im Setup Längen- und Breitengrad einzugeben (oder direkt in setup.conf):

    Code
    1. [...]
    2. SiteLat = 504
    3. SiteLon = 81
    4. [...]

    Also, 504 entspricht 50,4 und 81 entspricht 8,1 ...

    Ja, der "modesetting"-Treiber und nicht der "intel"-Treiber war aktiv genauso wie die "glamor" AccelMethod.

    "TearFree" "true" wurde nicht angewendet, weil es keine gültige Option wäre.


    Ich kann mein Produktivsystem erst am Wochenende wieder testen. Dann test ich auch meine andere Intel-Hardware mal durch.


    Mit aktuelllem git vom softhdcuvid und der GTX1030 läuft das Produktivsystem stabil ... allerdings mit 5-8 Watt mehr Leistungsaufnahme.

    Hallo jojo,


    der "modesetting"-Treiber macht es leider noch sichtbarer - jetzt ist es eher ein Viertel statt einem Zehntel mit einem Dreieck auf der linken Seite :(


    Im Kameraschwenk in diesem Beispiel ist es am Besten zu sehen.


    Ich baue erstmal wieder die GTX1030 ein, sonst gibt es heute Abend noch Ärger ;)

    Hallo jojo,


    ich habe auf unserem "Produktiv-VDR" auf softhdvaapi (LIBPLACEBO=0) umgestellt (von softhdcuvid mit Nvidia GTX 1030).

    Es läuft schon richtig gut :) Vielen Dank!


    Seit 6acd2feb3f2f9515a28c028c757b26d8f8574e98 gibt es allerdings im oberen Zehntel des Bild Tearing.

    Weil es so weit oben im Bild es, fällt es nicht sofort auf, sondern nur bei Kameraschwenks oder schnellen Bewegungen.

    Es scheint unabhängig vom Codec und Auflösung zu sein.


    Vor diesem Commit war dieses Problem nicht da.


    Allerdings gab es vor diesem Commit ein anderes Problem:

    Beim Seitenwechsel im osdteletext gibt es Sprünge bzw. Zittern im Videostream.

    Mir wäre das egal, aber meine bessere Hälfte mag es nicht tolerieren ...


    Gibt es irgendwelche Tricks, um das Tearing los zu werden?

    Die üblichen xorg.conf Ratschläge habe ich schon erfolglos durchdekliniert:


    Code
    1. Section "Device"
    2. Identifier "Intel Graphics"
    3. Driver "intel"
    4. # Option "DRI" "false"
    5. Option "TearFree" "true"
    6. # Option "AccelMethod" "uxa"
    7. Option "AccelMethod" "sna"
    8. Option "SwapbuffersWait" "true"
    9. Option "TripleBuffer" "true"
    10. EndSectio


    Schöne Grüße

    Christian

    Ja, von Sundtek gibt es nur binäre Userspace-Treiber.

    Die funktionieren als Blackbox und berichten nicht, welche Chips initialisiert werden.


    Geöffnet habe ich den SkyTV 5 auch noch nicht, deswegen kann ich nicht sagen, was verbaut ist.

    Ich war auch erst eher skeptisch, aber es funktioniert seit Jahren in der Praxis im positiven Sinne unauffällig.


    Der Sundtek-Support liest ja hier mit. Vielleicht gibt's ja eine Antwort?


    Danke für den Tip mit force_tbs.diff. Schaue es mir an, wenn es soweit ist.

    Der Rotor ist an einem anderen Standort verbaut und da bin erst wieder in zwei Wochen.

    Hallo Helmut,


    echt prima, dass Du VDR für Multistream fit machst!


    Ich habs gestern mal mit einem Sundtek SkyTV Ultimate 5 getestet.

    Leider unterstützt der Stick kein Multistream. Das rauszufinden hat mich ein paar Minuten gekostet.

    Vielleicht magst Du den folgenden Dreizeilier noch in Deinen Patch einbauen, damit es im Log klar zum Ausdruck kommt, dass Multistream vom Frontend nicht unterstützt wird?


    Schöne Grüße und vielen Dank nochmal

    Christian

    Und hier das Log für die Aufnahme, die beim Sprung +1 Minute hängt:

    So, hier mit -DDEBUG das Log für einen Radiosender, konkret 1LIVE;ARD WDR:12265:HC34M2S0:S19.2E:27500:0:1101=deu@3:0:0:28475:1:1093:0

    jsffm hat es auf den Punkt gebracht: Radio ==> VPID==0.


    Und hier das Log, wenn es bei SD-Sendern beim Springen "klemmt". Der VDR ist erst wieder benutzbar, nach dem Log-Eintrag "video: audio/video difference too big"

    Ich habe das aktuelle git vom sofhdvaapi (ohne libplacebo) mal auf meinem Nuc (Broxton laut vaainfo) und vanilla VDR 2.4.1 getestet.

    Erst hat es Deadlocks bei fast jedem Umschalten gegeben, aber das lag am streamdev-client. Nachdem ich streamdev von https://github.com/ciminus/vdr-plugin-streamdev/ kompiliert habe, waren die Deadlocks nämlich komplett weg. Das alte softhddevice hat die Deadlocks interessanterweise nicht getriggert.


    HD funktioniert super :-)


    SD funktioniert auch gut, aber +/-1 eine Minute springen klemmt fast immer.


    Bei Radio-Sendern gibt es keinen Ton.


    Hier das Log, beim Umschalten auf Radio.