VDR Developer Version 2.5.4

  • Wäre dann damit dieses leidige Thema ein für alle Mal erledigt?

  • Mich würde interessieren wie der TSCheck für Endanwender nutzbar ist, bzw, wie Skins mit dem O Tag in der info Dateien umgehen?

    Verstehe ich das richtig, dass errors auch für alle Aufnahmen, die mit früheren VDR-Versionen gemacht wurden, mit 0 initialisiert wird? Dann würden die automatisch alle als "fehlerfrei" angezeigt. Kann man errors nicht mit -1 initialisieren, dann würde Errors() nur für neue Aufnahmen einen validen Wert anzeigen.


    MegaV0lt : Im Skin-Plugin kann man dann den Wert abfragen und bei >=0 z.B. in den Aufnahme-Infos anzeigen, genauso wie z.B. die Altersfreigabe oder den Stream-Content

  • Den diff sollten _vorher_ viele testen, bevor du das in deine Version übernimmst,

    damit das wirklich niemand mehr anfassen muss. Ich wäre ungern daran Schuld, wenn das noch mal aufploppt.


    Bei mir passt es (glibc-2.33 + gcc-11.1.0), Null Fehler/Warnungen

    vdr-2.5.4 - OK

    ddci3 - OK (ddci2 + ein paar Extras)

    dvd-plugin-cvs-20120522 - OK

    easyvdr-2021.01.24.1 - OK

    series - OK

    skinsoppalusikka-2.4.0 - OK

    sleeptimer-0.8.2 - OK

    vdirs - OK

    vdr-plugin-control - OK

    vdr-plugin-femon-master - OK

    vdr-plugin-live (github:MarkusEh) - OK (mit/ohne DISABLE_..)

    vdr-plugin-satip - OK

    vdr-plugin-softhddevice-vdpau-vaapi-cuvid - OK

    wirbelscan-2021.02.18 - OK

  • Sehr offtopic. Die Version proviert einen VDR Restart, falls die CI Hardware nicht initialisiert werden konnte.

  • in recordings.h fehlt noch ein "const"

    Code
    1. int Errors(void) const { return errors; } // returns -1 if undefined

    dann compiliert es und es werden nur für neue Aufnahmen die Fehler angezeigt.


    Wenn man eine neue (fehlerfreie) Aufnahme schneidet, wird auch die Kopie mit 0 errors angezeigt. Ich habe dann testweise mal das Tag "O 10" gesetzt und VDR neu gestartet. Die Aufnahme zeigt dann 10 Fehler an,, aber nach dem Schneiden steht in der Kopie "O 0", also keine Fehler (was ja eigentlich auch korrekt ist).

    Wird beim Schneiden noch mal der TScontinuity Check gemacht? Dann würde das ja stimmen.

    Ist errors nach oben begrenzt? Wenn das int überläuft wird es ja negativ und irgendwann sogar wieder Null...

  • Ist errors nach oben begrenzt? Wenn das int überläuft wird es ja negativ und irgendwann sogar wieder Null...

    Doch nicht, wenn als unsigned deklariert.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • in recordings.h fehlt noch ein "const"

    Danke, hab's ergänzt.

    Wird beim Schneiden noch mal der TScontinuity Check gemacht? Dann würde das ja stimmen.

    Nein, das wird nur bei der Aufnahme gemacht. Beim Kopieren der Info-Datei für die geschnittete Version hatte ich im Prinzip die Möglichkeit, die Fehler zu übernehmen oder auf 0 zu setzen. Ich habe mich für Letzteres entschieden.

    Ist errors nach oben begrenzt?

    'int' kann maximal ca. 2 Milliarden sein. 2 Mrd. x 188 (wenn man mal nur die TS-Fehler rechnet) entspricht 376 GB - so eine große Aufnahme, bei der jedes TS-Paket fehlerhaft ist, ist doch eher unwahrscheinlich ;-).

  • Stimmt auch wieder.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Nein, das wird nur bei der Aufnahme gemacht. Beim Kopieren der Info-Datei für die geschnittete Version hatte ich im Prinzip die Möglichkeit, die Fehler zu übernehmen oder auf 0 zu setzen. Ich habe mich für Letzteres entschieden.

    Wird das bei alten Aufnahmen, die das Flag noch nicht hatten auch so gemacht?


    Ich habe hier sicher noch einige alte Aufnahmen, die Fehler haben. Die würden dann nach einem Schnitt auch 0 bekommen.

    Deshalb die Frage, wäre es mit vertretbarem Aufwand möglich, diesen Check auch für den Schnitt bereit zu stellen. Der könnte ja z.B. schaltbar sein, oder auch nur für den Fall, das der Counter noch bei -1 steht.


    Grüße

    kame

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 34 Kernel 5.13 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Wird das bei alten Aufnahmen, die das Flag noch nicht hatten auch so gemacht?

    Im Moment wird 'errors' beim Schneiden auf jeden Fall auf 0 gesetzt, aber ich könnte freilich den Wert -1 bei alten Aufnahmen einfach durchreichen. Wäre dir das lieber?

    wäre es mit vertretbarem Aufwand möglich, diesen Check auch für den Schnitt bereit zu stellen

    Halte ich ehrlich gesagt nicht für sehr sinnvoll. Der Cutter hat schon genug zu tun, die Continuity-Counter, PTS und DTS anzupassen. Der eigentliche Sinn dieses Features ist es ja, bei der Aufnahme zu erkennen, ob diese Fehlerfrei ist, damit eventuelle Wiederholungen nicht mehr aufgenommen werden.

  • Im Moment wird 'errors' beim Schneiden auf jeden Fall auf 0 gesetzt, aber ich könnte freilich den Wert -1 bei alten Aufnahmen einfach durchreichen. Wäre dir das lieber?

    Ja, das wäre mir auf jeden Fall lieber, dann würde man zumindest sehen, das das ungeprüft ist.

    Halte ich ehrlich gesagt nicht für sehr sinnvoll. Der Cutter hat schon genug zu tun, die Continuity-Counter, PTS und DTS anzupassen. Der eigentliche Sinn dieses Features ist es ja, bei der Aufnahme zu erkennen, ob diese Fehlerfrei ist, damit eventuelle Wiederholungen nicht mehr aufgenommen werden.

    OK, das kann ich schon nachvollziehen, wobei heutige Systeme ja in der Regel schnell genug sind für sowas...

    Das Durchreichen der -1 würde mir auf jeden Fall schon weiter helfen.


    Grüße

    kamel5

    VDR 2.5.6: ASUS Prime X470-PRO, Ryzen 7 2700, 64GB, 6TB HD, GT1030, Fedora 34 Kernel 5.13 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Das Durchreichen der -1 würde mir auf jeden Fall schon weiter helfen.

  • Hallo Klaus,


    + The number of errors during a recording is stored in the recording's 'info' file, with
    the new tag 'O'.


    wäre es möglich, den Wert auch an das per "-r" angegebene Skript bei "after" zu übergeben?


    VG

  • 'int' kann maximal ca. 2 Milliarden sein. 2 Mrd. x 188 (wenn man mal nur die TS-Fehler rechnet) entspricht 376 GB - so eine große Aufnahme, bei der jedes TS-Paket fehlerhaft ist, ist doch eher unwahrscheinlich ;-).

    Ok, das sollte für ein TV-Heimgerät reichen ;-)


    Ja, das wäre mir auf jeden Fall lieber, dann würde man zumindest sehen, das das ungeprüft ist.

    mir auch, aber müsste in dem Patch aus Post #57 in Zeile 9 nicht ">= 0" stehen?

    Edit: Nein, es funktioniert mit >0

  • Im Moment wird 'errors' beim Schneiden auf jeden Fall auf 0 gesetzt

    Ich benutze checkts seit vielen Jahren und freue mich , dass dieses Feature jetzt fest im vdr ist. Ich fände es sinnvoller, 'errors' beim Schneiden durchzureichen. Denn ich will auch nach dem Schnitt und Löschen der ungeschnittenen Aufnahme noch wissen, dass es Fehler bei der Aufnahme gab (wohl wissend, dass es durch das Schneiden vielleicht weniger geworden sind).