1.) Ich denke mal, beim Schneiden kann man immer selber entscheiden, welche alte Aufnahme man löschen will. Bei einer laufenden Aufnahme *muss* was Altes dran glauben, damit die neue Aufnahme klappt.
2.) Hat vermutlich historische Gründe, weil unabhängig voneinander entstanden?
3.) Nicht alles muss immer einstellbar sein ;-).
Nicht alles muss immer einstellbar sein ;-).
Muss nicht. Kann aber nützlich sein...;) Wäre es eventuell möglich, diesen Patch bitte zu integrieren:
Wenn ich mich recht entsinne, war das etwas komplexer: Während Aufnahmen wird öfter gechecked ob genug Platz ist als beim Schneiden. Für HDDs funktioniert das gut, aber bei SSDs ist das Schneiden oft so schnell, dass trotz der Checks die Platte volllaufen kann (und dann auch eine gleichzeitig laufende Aufnahme abbricht). Letztendlich muss man die Schreibrate mit der Checkfrequenz und MINDISKSPACE vergleichen. Ich hatte mir damals mit dem angehängten Patch beholfen und seitdem keine Probleme mehr. Ob die Werte allgemeingültig sind kann ich aber nicht einschätzen.
--- recording.c.orig 2022-02-02 10:56:43.000000000 +0100
+++ recording.c 2022-10-03 14:25:40.677547499 +0200
@@ -59,7 +59,7 @@
#define SORTMODEFILE ".sort"
#define TIMERRECFILE ".timer"
-#define MINDISKSPACE 1024 // MB
+#define MINDISKSPACE 4096 // MB
#define REMOVECHECKDELTA 60 // seconds between checks for removing deleted files
#define DELETEDLIFETIME 300 // seconds after which a deleted recording will be actually removed
@@ -159,7 +159,7 @@
// a file, or mark a file for removal ("delete" it), so that
// it will get removed during the next call.
static time_t LastFreeDiskCheck = 0;
- int Factor = (Priority == -1) ? 10 : 1;
+ int Factor = (Priority == -1) ? 20 : 1;
if (Force || time(NULL) - LastFreeDiskCheck > DISKCHECKDELTA / Factor) {
if (!cVideoDirectory::VideoFileSpaceAvailable(MINDISKSPACE)) {
// Make sure only one instance of VDR does this:Code- int Factor = (Priority == -1) ? 10 : 1; + int Factor = (Priority == -1) ? 20 : 1;
10 oder 20. Wenn ich den Code richtig verstehe, dann passiert sowieso gar nichts:
"...no deleted recording found, priority %d too low to trigger deleting an old recording"
Und das beobachte ich auch: Ganz langsam geht der freie Platz beim Scheiden runter auf 0, und dann bricht der Schneideprozess ab.
Natürlich könnte man die ganze Logik des Platzschaffens ändern (z.B. andere Prioritäten setzen), aber alleine MINDISKSPACE konfigurierbar zu machen, kann gut helfen ohne großes Fehlerrisiko.
10 oder 20. Wenn ich den Code richtig verstehe, dann passiert sowieso gar nichts:
"...no deleted recording found, priority %d too low to trigger deleting an old recording"
Dann ist Dein Problem aber ein etwas anderes. Wenn VDR keine Aufnahmen zum Löschen findet (diejenigen, die *.del heißen und quasi im "Papierkorb" sind), dann kann er auch keine löschen. Mit den Prioritäten der Aufnahmen habe ich mich nie befasst da ich nur selbst löschen will.
Immer warten mit dem Schneiden bis "vielleicht" die alten Aufnahmen gelöscht sind ist ja keine Lösung...
Das hatte ich in etwas so interpretiert: Du möchtest, dass die alten Aufnahmen beim Schneiden automatisch gelöscht werden, ohne zu warten, dass es bei der nächsten Aufnahme passiert.
Dann möchte ich tatsächlich das selbe.
Da Klaus aber anscheinend die Logik nicht ändern möchte (seine Antwort auf meine Frage 1), kann man wenigstens dafür sorgen (mit dem neuen Parameter Setup.MinDiskSpace), dass VDR regelmäßig (beim Aufnehmen) genügend Platz schafft, zum Schneiden oder vielleicht für andere Bedürfnisse.
Mit den Prioritäten der Aufnahmen habe ich mich nie befasst da ich nur selbst löschen will.
Ja, das sieht bei mir tatsächlich anders aus. Ich möchte, dass VDR für mich löscht.
Wie wäre es denn hiermit?
Anhand der Schnittmarken und der Größe der Ursprungsdatei lässt sich relativ genau der für die geschnittene Datei benötigte Plattenplatz berechnen. VDR könnte dies tun bevor der Auftrag angenommen wird, und falls nicht genügend Platz frei ist (unter Berücksichtigung eventuell bereits gelöschter Aufnahmen "*.del") eine Fehlermeldung ausgeben. Das evtl. benötigte Löschen von *.del Aufnahmen könnte dann bereits vor Beginn des Schneidens stattfinden.
Das wäre wohl die eleganteste Lösung! +1
Wirklich elegant gelöst.
Bei einer laufenden Aufnahme *muss* was Altes dran glauben, damit die neue Aufnahme klappt.
Hallo Klaus,
Ich habe gerade gemerkt, dass das gar nicht funktioniert, sobald man schneidet, da LastFreeDiskCheck ständig aktualisiert wird.
falls nicht genügend Platz frei ist eine Fehlermeldung ausgeben.
Das würde bei mir nicht funktionieren, da ich oft mehrere Filme scheiden möchte, aber der Platz dafür garantiert nicht vorher vorhanden. Daher hier ein aktualisierter Patch:
Viele Grüße, Peter
Das hört sich gut an. Im Prinzip mache ich das schon per Hand mit der Größenanzeige in skinElchiHD und der Diskspace-Anzeige in systeminfo 
. Gilt das Verfahren dann auch beim Verschieben auf eine andere Platte?
Der Freiplatz müsste dann über alle Schnittaufträge in der Queue aufsummiert werden und MINDISKSPACE für gerade laufende Aufnahmen sollte (zumindest auf der primären Platte) auch noch frei bleiben.
Hier mal ein erster Vorschlag. Weitestgehend ungetestet, daher bitte mit Vorsicht genießen.
Bitte probiert es mal, oder schaut euch einfach den Diff an, ob euch was auffällt.
Ich habe jetzt noch zur Sicherheit MINDISKSPACE abgezogen, um zu verhindern, dass die Platte total volläuft.
Ich habs noch nicht ausprobieren können, aber habe gesehen, dass der Platz aus dem Verhältnis der NumFrames nachher/vorher berechnet wird. Wäre es nicht besser (d.h. genauer) den Platz anhand der rauszuscheidenden Teile zu berechnen so wie ich es in skinElchiHD mache?
Und bei int LengthInSeconds(void) const; und int LengthInSecondsAfterEdit(void) const; in recording.h sind die Kommentare vertauscht 
Wäre es nicht besser (d.h. genauer) den Platz anhand der rauszuscheidenden Teile zu berechnen so wie ich es in skinElchiHD mache?
Wie machst du es denn in skinElchiHD?
Kommentare vertauscht
Danke, hab's korrigiert.
Wie machst du es denn in skinElchiHD?
Ich hole aus der Indexdatei die Filepositionen der Schnittmarken und summiere die Größen auf. Vielleicht geht das heute auch etwas eleganter, aber die Routine ist von 2008
Ich hole aus der Indexdatei die Filepositionen der Schnittmarken und summiere die Größen auf
Magst du mal einen Vergleichstest machen? Sollte ja in deinem Code leicht einzubauen sein, da du ja alle Daten zur Hand hast.
Wenn der Fehler größer als 5% ist, lasse ich mich von deiner Methode überzeugen.
Ok, denke aber, dass ich frühestens Sonntag zum Testen komme...
Don’t have an account yet? Register yourself now and be a part of our community!
