Kann der VDR Aufzeichnungen löschen bevor der Speicherplatz auf 0 geht

    kls : Irgendwas stimmt mit dem Algorithmus noch nicht:

    Code
    vdr: [13935] total: 0:43:23, 4691,76 MB
vdr: [13935] cutted time skinElchiHD: 0:05:32, VDR: 0:37:50
vdr: [13935] cutted size skinElchiHD: 599 MB, VDR: 4091 MB

#cat marks 
0:00:00.00
0:00:00.00
0:04:59.37
0:10:31.49
    Code
    vdr: [13935] total: 0:00:38, 64,58 MB
vdr: [13935] cutted time skinElchiHD: 0:00:21, VDR: 0:00:00
vdr: [13935] cutted size skinElchiHD: 37 MB, VDR: -1 MB

#cat marks 
0:00:17.14

    Und für Aufnahmen im PES-Format scheint es gar nicht zu funktionieren:

    Also doch meine Routine übernehmen? :saint:

    Hab's jetzt nochmal überarbeitet und aus cMarks::GetFramesAfterEdit() ein cMarks::GetFrameAfterEdit() gemacht. Damit kann man jetzt für jeden beliebigen Frame den Frame nach dem Schneiden ermitteln (typischerweise für Current). Damit dürfte die Anforderung von hier erfüllt sein.

    <edit>Korrigierte Version hochgeladen, es war eine Klammer zu viel</edit>

    kls, ich muss das noch mal aufwärmen.


    Das:

    Code
      int GetFrameAfterEdit(int Frame, int LastFrame) const;
       ///< Returns the number of the given Frame within the region covered by begin/end sequences.
       ///< 
       ///< LastFrame must be given by the caller.
       ///< If there are no editing marks, 0 will be returned.
       ///< In case of an error -1 is returned.

    stimmt so nicht ganz.

    "0" kann auch zurückgegeben werden, wenn es Marken gibt.

    Wenn es keine Marken gibt, sollte aus meiner Sicht auch "-1" zurückgegeben werden, z.B. so:

    Code
     int cMarks::GetFrameAfterEdit(int Frame, int LastFrame) const
 {
-  if (LastFrame < 0 || Frame < 0 || Frame > LastFrame)
+  if (Count() == 0 || LastFrame < 0 || Frame < 0 || Frame > LastFrame)
      return -1;
   int EditedFrame = 0;
   int PrevPos = -1;

    Sonst muss man bei Benutzung dieser Funktion vorher immer nochmal prüfen, ob es überhaupt Marken gibt.


    Grüße

    kamel5

    VDR 2.6.8: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.9 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

    Hier die Ergebnisse meiner Tests (mit Version 07):

    Die Ausreißer habe ich an den Anfang der Liste kopiert. Bei den meisten Aufnahmen (SD & HD, TS & PES getestet) sind die Werte ähnlich, da die Bitrate über die gesamte Aufnahme offenbar recht konstant bleibt. Aber wenn sie das nicht ist, können die Werte bei großen Aufnahmen mehrere Hundert MB daneben liegen.

    Zitat von FireFly

    zumal Deine Routine nicht nur die TS/PES-Files in Betracht zieht sondern DirSizeMB() benutzt, wo jede Datei auf volle MB abgerundet wird ;) Ok, das ist auch ne Art Filter auf die TS/PES-Files ...

    So ganz verstehe ich diesen Satz nicht. Ist das jetzt gut oder schlecht? Was bedeutet "ne Art Filter auf die TS/PES-Files"?

    DirSizeMB() geht ja alle Dateien des angegebenen Verzeichnisses durch, nicht nur die TS/PES-Files.

    Dann wird die Größe jeder einzelnen Datei auf volle MB abgerundet (size += st.st_size / MEGABYTE(1);), so dass alle außer den TS/PES-Files (und evtl. der Index) auf 0 abgerundet werden. Damit sind sie quasi rausgefiltert.

    Dadurch werden sie bei der Größenberechnung zwar nicht berücksichtigt, aber aufgrund der vergleichsweise geringen Größe ist das auch kein Problem. Nur wenn man es ganz exakt haben wollte, müsste man sie mit einbeziehen.

    Gut erkannt, das war mir noch nie aufgefallen.

    Vielleicht sollten wir lieber auf volle MB aufrunden?

    Also size += (st.st_size + MEGABYTE(1)) / MEGABYTE(1);

    Dann wären wir zumindest auf der sicheren Seite. Aber wie du schon sagtest, wir haben es hier mit Gigabytes zu tun, da spielen ein paar Megabyte keine Rolle - wenn ich da an die Anfänge meiner Computerzeit denke, da wäre so ein Satz undenkbar gewesen ;-).

    Zitat von kls

    Vielleicht sollten wir lieber auf volle MB aufrunden?

    Beim Aufrunden pro Datei hätte ich 9MB zu viel bei einer Beispielaufnahme (5 Bilder, info, resume, marks, index von 1,1 MB).


    Besser wäre es, wenn man die Größe in Bytes aufaddieren würde und erst den Return-Wert durch 1 MB teilt (evtl. auf-/abrunden).

    Nehmen wir mal folgendes Beispiel:

    Bilder, info, resume, marks, index haben zusammen 1265848 Byte = 1MB + 217272 Byte

    00001.ts = 2 GB + 506316 Byte

    00002.ts = 553 MB + 804988 Byte

    Pro Datei abgerundet fehlen da also zusammen 217272+506316+804988 = 1528576 Byte = 1MB + 480.000 Byte

    Je nach Auf-/Abrunden also 1-2 MB beim Return-Wert.

    Ich denke nicht, dass die Änderung sich lohnt, zumal ja die Größenabschätzung fürs Schneiden bei schwankender Bitrate mehrere MB daneben liegen kann ....


    Zitat von kls

    wenn ich da an die Anfänge meiner Computerzeit denke, da wäre so ein Satz undenkbar gewesen ;-).

    Ja, da war ich schon mit 64k RAM glücklich :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden