VDR Version 2.8.1 freigegeben

  • Also fehlt im Skindesigner noch ein Trick. kamel5 hast du noch eine Idee?

    Ihr habt ja nun schon herausgefunden, das es am MenuOrg Plugin liegt. Da werde ich wohl nicht viel im skindesigner unternehmen können.

    Im Moment bin ich dabei eine neue Version vom skindesigner zu machen, die dann auch die Änderung bzgl. der gelöschten Aufzeichnungen enthält.

    Grüße
    kamel5

    Grüße
    kamel5

    VDR 2.8.2: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 10TB HD mit ZFS RaidZ, Intel A380, Fedora 44 Kernel 7.1 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Habe eine dvb-t2 (h265) Aufnahme*, welche erst 0 Fehler aufweist und nach Schnitt 323 Fehler anzeigt.
    Wenn ich die Index Datei der geschnittenen Aufnahme lösche, sind es wieder 0 Fehler?

    Beide info Dateien angehängt + Downloadlink der original Aufnahme (*)

    Alles mit vdr 2.8.1 gemacht und zweimal reproduziert.

    Files

    Klick für meine VDR Hard- u. Software

    vdr1: NUC12WSKi5 16GB | VDR*ELEC LE13 32GB M.2 2242 | Video: 4TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr2: HP Pro Mini 400 G9 i5 32GB | Ubuntu 24.04.3 LTS yavdr ansible vdr-2.8.2 256GB M.2 2230 | Video: 4TB M.2 Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr3: Raspberry CM5 auf CM5-IO-BASE-A | Seeed PCIe 3.0 dual M.2 HAT | VDR*ELEC LE13 | 1TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    TV: Philips 55OLED805

  • Habe eine dvb-t2 (h265) Aufnahme*, welche erst 0 Fehler aufweist und nach Schnitt 323 Fehler anzeigt.

    Bei mir verhält es sich mit meiner Aufnahme dieser Sendung ganz genauso. Hab die Ursache nicht gefunden.

    P.S. Habe auch vdr 2.8.1.

    mein VDR
    • Software: yaVDR0.7-Ansible mit vdr-2.8.2 auf Ubuntu Server 26.04
    • DVB-T2: Hauppauge WinTV-dualHD
    • Fernseher: LG OLED42C48LA

    Edited once, last by blau: vdr 2.8.1. ergänzt (April 14, 2026 at 1:41 PM).

  • Habe eine dvb-t2 (h265) Aufnahme*, welche erst 0 Fehler aufweist und nach Schnitt 323 Fehler anzeigt.

    Ein paar mehr Infos wären nicht schlecht gewesen, z.B. dass die Fehler nicht an Schnittmarken sondern mittendrin auftreten ...
    Einen ähnlichen Fehler hatte ich mit einer der letzten VDR-Versionen weil der FrameBufferzu klein war (der in 2.8.1 jetzt größer ist).
    Hast Du Fehler im Log beim Aufnehmen von DVB-T2, z.B. etwas mit MaxFrameSize ?

  • Ich gelobe Besserung.

    Hast Du Fehler im Log beim Aufnehmen von DVB-T2, z.B. etwas mit MaxFrameSize ?

    Mmm, ein journalctl | grep "MaxFrameSize" bringt kein Ergebnis.

    Vdr läuft im Loglevel 3 - d.h. nur Fehler. Bei Aufnahmen sehe ich keine Fehler im Log.

    Klick für meine VDR Hard- u. Software

    vdr1: NUC12WSKi5 16GB | VDR*ELEC LE13 32GB M.2 2242 | Video: 4TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr2: HP Pro Mini 400 G9 i5 32GB | Ubuntu 24.04.3 LTS yavdr ansible vdr-2.8.2 256GB M.2 2230 | Video: 4TB M.2 Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr3: Raspberry CM5 auf CM5-IO-BASE-A | Seeed PCIe 3.0 dual M.2 HAT | VDR*ELEC LE13 | 1TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    TV: Philips 55OLED805

  • Ja, Log geht zurück bis 01.04. - also bis weit vor der Aufnahme.

    journalctl | grep -i "frame larger than buffer" bringt kein Ergebnis.

    Klick für meine VDR Hard- u. Software

    vdr1: NUC12WSKi5 16GB | VDR*ELEC LE13 32GB M.2 2242 | Video: 4TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr2: HP Pro Mini 400 G9 i5 32GB | Ubuntu 24.04.3 LTS yavdr ansible vdr-2.8.2 256GB M.2 2230 | Video: 4TB M.2 Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr3: Raspberry CM5 auf CM5-IO-BASE-A | Seeed PCIe 3.0 dual M.2 HAT | VDR*ELEC LE13 | 1TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    TV: Philips 55OLED805

  • bringt kein Ergebnis

    Dann weiß ich auch nicht weiter :( Sonst auch keine Auffälligkeiten bei der Aufnahme oder beim Schnitt im Log?
    Zumindest ist es das gleiche Fehlerbild wie bei mir damals: Aufnahme 0 Fehler, Schnitt xFehler, Re-Index 0 Fehler. Ursache war damals, dass einige Frames unvollständig (zu kurz) waren und das nur beim Schnitt aufgefallen ist da ein Re-Index das nicht prüft

  • Ursache war damals, dass einige Frames unvollständig (zu kurz) waren

    Wie kann man denn das feststellen? Ich hatte ja diese Fehler damals und jetzt auch.

    mein VDR
    • Software: yaVDR0.7-Ansible mit vdr-2.8.2 auf Ubuntu Server 26.04
    • DVB-T2: Hauppauge WinTV-dualHD
    • Fernseher: LG OLED42C48LA
  • Hier ein weiterer gleichgelagerter Fall.

    Log der Aufnahme:

    Die Aufnahme hat 0 Fehler.

    Info

    nach Schnitt sind es 55 Fehler

    nach Index Neugenerierung wieder 0 Fehler.

    Es handelt sich um dv-t2 Sender mit folgendem channels.conf Eintrag:

    Code
    NDR FS SH HD;ARD:618000:B8D0G19128S1T16Y0P0:T:27500:5137=36:5138=deu@17,5139=mis@17,5141=qks@17:5140:0:899:8468:5634:0

    journalctl | grep -i "frame larger than buffer" hat keinen Treffer.

    Die beiden dvb-t2 Tuner sind meine Hauptaufnahmequelle. Das Phänomen habe ich jetzt 2-3 mal beobachtet. Würde sagen es kommt bei 1% der getätigten Aufnahmen vor.

    Wie kann ich da weiter diagnostizieren?

    Klick für meine VDR Hard- u. Software

    vdr1: NUC12WSKi5 16GB | VDR*ELEC LE13 32GB M.2 2242 | Video: 4TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr2: HP Pro Mini 400 G9 i5 32GB | Ubuntu 24.04.3 LTS yavdr ansible vdr-2.8.2 256GB M.2 2230 | Video: 4TB M.2 Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr3: Raspberry CM5 auf CM5-IO-BASE-A | Seeed PCIe 3.0 dual M.2 HAT | VDR*ELEC LE13 | 1TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    TV: Philips 55OLED805

  • Hie noch der Logauszug vom schneiden:

    Klick für meine VDR Hard- u. Software

    vdr1: NUC12WSKi5 16GB | VDR*ELEC LE13 32GB M.2 2242 | Video: 4TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr2: HP Pro Mini 400 G9 i5 32GB | Ubuntu 24.04.3 LTS yavdr ansible vdr-2.8.2 256GB M.2 2230 | Video: 4TB M.2 Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr3: Raspberry CM5 auf CM5-IO-BASE-A | Seeed PCIe 3.0 dual M.2 HAT | VDR*ELEC LE13 | 1TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    TV: Philips 55OLED805

  • Es wäre gut, wenn du die ungeschnittene Aufnahme aufhebst, falls sich das mal jemand angucken will.

  • Es wäre gut, wenn du die ungeschnittene Aufnahme aufhebst, falls sich das mal jemand angucken will.

    Klar, liegt erstmal gepackt in meiner Dropbox -> Link

    Klick für meine VDR Hard- u. Software

    vdr1: NUC12WSKi5 16GB | VDR*ELEC LE13 32GB M.2 2242 | Video: 4TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr2: HP Pro Mini 400 G9 i5 32GB | Ubuntu 24.04.3 LTS yavdr ansible vdr-2.8.2 256GB M.2 2230 | Video: 4TB M.2 Rec (XFS) + 8TB SATA Archiv (exFAT) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    vdr3: Raspberry CM5 auf CM5-IO-BASE-A | Seeed PCIe 3.0 dual M.2 HAT | VDR*ELEC LE13 | 1TB M.2 Rec (XFS) | 2x WinTV dualHD (DVB-T2/DVB-C) | RP2350 IRMP Pico | One4all URC 1635 FB
    TV: Philips 55OLED805

  • An der "Störstelle" (die in Wirklichkeit keine ist) befindet sich ein I-Frame, der nur Audio-Pakete enthält, aber kein Video. Bei der Index-Berechnung macht das nichts, da dort jedes TS-Paket einzeln analysiert wird und nur der PTS der Video-Pakete gecheckt wird. Beim Schneiden werden aber ganze Frames gecheckt, und wenn da ein Frame nicht mit einem Video-Paket beginnt (oder, wie hier, gar keines enthält), dann erwischt der cFrameChecker den PTS eines Audio-Paketes, und kommt damit an der Stelle durcheinander. Er meint dann dort fehlen Frames. Zumindest meine ich, das soweit verstanden zu haben. Man möge mich bitte korrigieren, wenn der Fehler woanders liegt.

    Mit beiliegendem Patch werden beim Schneiden in einem solchen Fall keine "Phantom-Fehler" mehr angezeigt.
    Der Patch sollte ausschließlich die Fehlererkennung beim Schneiden fixen, und ansonsten keinerlei Auswirkungen haben.

    Die Aufnahme als solche ist in Ordnung, und wenn die Fehler nach dem Neu-Generieren des Index weg sind, lag es an diesem Bug.

    Ich vermute mal, dass kein Plugin cFrameChecker verwendet, es könnte aber sein, dass Plugins TsGetPts() verwenden. Im Zweifelsfall also einfach alles neu übersetzen. In der nächsten Version werde ich APIVERSNUM entsprechend hochsetzen.

Participate now!

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