(phys.) Löschen gelöschter Aufnahmen beim Schneiden

Quote from Der_Pit

Hi,

Ich war mir nicht sicher ob das hierher gehört, ich verwende extrecmenu. Aber der Schnitt selbst ict doch VDR core Funktion, oder?

Jedenfalls, gestern ist mir das Schneiden einer Aufnahme fehlgeschlagen. Nach etwas Suchen hab ich rausgefunden dass die Platte voll war: Ich hatte ca. 33GB an alten Sachen gelöscht bzw. auf eine andere Platte verschoben, aber VDR benennt die ja erstmal nur um.... Jedenfalls waren also nicht - wie von VDR im Menü angezeigt - 10 Stunden frei, sondern nur ene halbe :(, und der Schneidevorgang kam nicht auf die Idee mal eben den Lösch-Thread anzuwerfen, um auch wirkich physikalisch Platz für die geschnittene Aufnahme zu machen...

Ich weiss nicht ob's wirklich ein Bug ist - aber auf jeden Fall ist's sehr irritierend....

VDR sollte eigentlich beim Schneiden schon Plattenplatz freischaufeln, wenn möglich.
Teste doch bitte mal, ob das Problem auch auftritt, wenn du mit der VDR-internen Schnittfunktion arbeitest (also nicht mit extrecmenu).

Klaus

Ist mir auch schon mit extrecmenu passiert, vermutlich ein Bug.

Hallo,

bei mir ist das Problem gestern Abend auch aufgetreten und zwar ohne extrecmenu (aber zugegebenermaßen mit ein/zwei Patches ;D).

Ich habe mehrfach versucht, eine Aufnahme zu schneiden, und es ist immer wieder gescheitert. Dabei habe ich einige interessante Effekte beobachtet:
* Die Freespace-Anzeige im Skin wechselte manchmal von 13,1GB schlagartig auf 5,5 GB sobald der Schnitt gestartet war ( 5,5 GB waren real frei, 13,1 GB inkl. der gelöschten Aufnahmen). Nachdem der Schnitt gescheitert war, blieb sie manchmal auf 5,5 GB, manchmal sprang sie auf 13,1 GB zurück. Wann die beiden Fälle autraten war nicht reproduzierbar.
* Im Log erscheinen keine Meldungen, dass er nichts zum Löschen findet, er löscht aber auch nichts.

Wo kann man da ansetzen?
Sollte in cCuttingThread::Action() beim AssertFreeDiskSpace(-1) nicht besser ein Force dabei sein? Denn dass er in DISKCHECKDELTA = 100 Sek. die letzten MINDISKSPACE = 1024 MB voll schreibt ist ja recht wahrscheinlich bei den heutigen Plattengeschwindigkeiten.
Wird bei der Berechnung des Freiplatzes manchmal die Liste der gelöschten Aufnahmen nicht einbezogen? Der Skin nutzt zur Anzeige cVideoDiskUsage::FreeMB()
[Edit]Gut möglich, dass das am fehlenden cVideoDiskUsage::HasChanged(lastDiskUsageState); liegt [/Edit]

Grüße
FireFly

Beim Durchlesen von AssertFreeDiskSpace() (in recording.c) ist mir zunächst mal aufgefallen, daß man sich die Suche nach einer "alten" Aufnahme zum Löschen komplett sparen kann, wenn Priority <= 0 ist, denn in dem Fall wird man nie eine Aufnahme mit noch kleinerer Priorität finden. Ich werde daher folgendes einbauen:

--- recording.c 2013/04/11 08:14:01     3.1
+++ recording.c 2013/08/21 13:03:38
@@ -178,6 +178,7 @@
               return; // the next call will actually remove it
            }
         // No "deleted" files to remove, so let's see if we can delete a recording:
+        if (Priority > 0) {
         isyslog("...no deleted recording found, trying to delete an old recording...");
         cThreadLock RecordingsLock(&Recordings);
         if (Recordings.Count()) {
@@ -206,6 +207,9 @@
            }
         // Unable to free disk space, but there's nothing we can do about that...
         isyslog("...no old recording found, giving up");
+           }
+        else
+           isyslog("...no deleted recording found, priority %d too low to trigger deleting an old recording", Priority);
         Skins.QueueMessage(mtWarning, tr("Low disk space!"), 5, -1);
         }
      LastFreeDiskCheck = time(NULL);

(Der Übersichtlichkeit halber habe ich den Diff mit -ubw gemacht, da sonst der eingerückte Block die egentliche Änderung "zugekleistert" hätte).

Aber nun zum eigentlichen Thema des Threads.
In cCuttingThread::Action() wird AssertFreeDiskSpace(-1) seit Version 1.7.32 nur noch einmal für jede Schnittmarke aufgerufen, während es vorher einmal pro Frame aufgerufen wurde. Wenn man also bei einer langen Aufnahme nur den Anfang und das Ende wegschneidet, dann wird AssertFreeDiskSpace(-1) nur einmal am Anfang aufgerufen und das wars.
Folgende Änderung sollte den vorherigen Zustand wieder herstellen:

--- cutter.c    2013/05/02 09:09:21     3.1
+++ cutter.c    2013/08/21 13:15:24
@@ -556,6 +556,8 @@
       bool Independent;
       int Length;
       if (LoadFrame(Index, Buffer, Independent, Length)) {
+         // Make sure there is enough disk space:
+         AssertFreeDiskSpace(-1);
          bool CutIn = !SeamlessBegin && Index == BeginIndex;
          bool CutOut = !SeamlessEnd && Index == EndIndex - 1;
          bool DeletedFrame = false;
@@ -608,8 +610,6 @@
               cCondWait::SleepMs(100);
               continue;
               }
-           // Make sure there is enough disk space:
-           AssertFreeDiskSpace(-1);
            // Determine the actual begin and end marks, skipping any marks at the same position:
            cMark *EndMark = fromMarks.GetNextEnd(BeginMark);
            // Process the current sequence:

Falls das nicht hilft (oder das Problem auch bei VDR Versionen vor 1.7.32 auftritt) sagt bitte Bescheid.

Klaus

Danke Klaus. Ich hatte mich schon gewundert, dass AssertFreeDiskSpace() nur einmal pro Schnitt aufgerufen wurde. Bin mir aber recht sicher, dass Dein diff den Fehler behebt.
Testen ist momentan nicht so einfach bei mir weil ich mittlerweile meinen Devel-VDR, auf dem ich auch kompiliere, auf openSuse 12.3 upgegraded habe und der produktive noch auf 12.1 ist.

Hallo Klaus, ich habs getestet: mit dem Patch funktioniert das Löschen von zum löschen markierten Aufnahmen wieder.