Posts by sg75

    Ich hatte auch mit Crashes bei h264 zu kämpfen und habe es dann mit den GFX memory settings in config.txt in den Griff bekommen (4GB Raspberry PI 4).

    Die Stellschrauben sind gpu_men und dtoverlay=cma-xyz.


    Soweit ich mich erinnern, mussten beide Werte zueinander passen.


    gpu_men darf nicht zu hoch sein, sonst klappt das Booten nicht mehr.


    Ich benutze einen hand-kompilierten Kernel nach diesem Rezept:

    Bei mir funktioniert es jetzt wieder nachdem ich diese Änderungen wieder zurückgeschraubt habe.

    Ich habs jetzt mit dieser /boot/config.txtam Laufen.

    Meine unfundierte Meinung ist, dass die Speicheraufteilung (gpm_mem und cma-xxx) wichtig ist.

    Aber Achtung: Wenn gpu_mem ist groß ist, bootet der Raspberry nicht mehr.

    HEVC klappt super, mpeg2 mit Deinterlacer auch :)

    Vielen Dank zillerbaer , das ist echt ein Meilenstein!!


    h264 funktioniert ca. 10 Sekunden, dann kommt leider reproduzierbar folgende Fehler. Danach hilft nur ein Reboot.

    Tipps?


    Ich habe mal eine Anleitung gemacht, wie man alles hand-kompiliert unter ArchLinux|ARM zum Laufen bringt.

    Vielleicht hilft es ja, mehr Tester zu gewinnen!

    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 ;)