Bitte testen: Anzeige der Fehler in der Fortschrittsanzeige

kls · Sep 20th 2024

In GIT (http://git.tvdr.de) gibt es eine neue "master" Version mit folgenden Änderungen:

Code

- Fix for compilers that don't like non-constant format strings (thanks to Stefan Hofmann).
- Deprecated code is now marked with [[deprecated]] to issue a compile time warning when
  used.
- Made APIVERSION independent from VDRVERSION to avoid irritation in case only
  VDRVERSION is incremented (originally suggested by Winfried Köhler, with contributions
  from Lars Hanisch and Manuel Reimer).
  APIVERSNUM is now 30003.
- Fixed a problem in cSchedule::Sort(), in case hasRunning was true, but there was no event
  with RunningStatus() >= SI::RunningStatusPausing (reported by Markus Ehrnsperger).
- Silenced a compiler warning with gcc 14.1.0 (reported by Winfried Köhler).
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Moved error checking from recorder.c to remux.c.
- The number of errors in a recording now represents the number of broken frames.
- Now distinguishing between frames with errors and completely missing frames.
- Recording errors are now marked in the index file.
- Fixed description of cSkinDisplayReplay::SetRecording().
- Errors are now shown as diamond shaped markers in the replay progress display of the
  default skins. Plugin authors can switch to the new constructor of cProgressBar to
  benefit from this feature. Of course this only works with recordings that have error
  information stored in their index file.
  APIVERSNUM is now 30004.
- When the index file of a recording is regenerated, errors in the recording are now
  stored in the index file.
- The info file of an edited recording now contains the number of errors in the edited
  version. Note that this applies only to recordings that have errors stored in their
  index file. If errors are not stored in the index file, the edited version will have
  its number of errors set to zero.
  APIVERSNUM is now 30005.

Display More

Bevor ich eine neue Versionsnummer vergebe und sie freigebe wäre es nett, wenn einige diesen Stand testen würden.

Dafür mussen eventuelle Plugins neu übersetzt werden.

jrie · Sep 20th 2024

Quote from kls

If errors are not stored in the index file, the edited version will have its number of errors set to zero.

Ich finde das alte Verhalten besser, also Übernahme von der Original Aufnahme.

Dann ist man wenigstens darauf gefasst, dass da Fehler sein können (und die Original Aufnahme bereits gelöscht ist).

kls · Sep 20th 2024

Quote from jrie

Ich finde das alte Verhalten besser, also Übernahme von der Original Aufnahme.

Mit dieser Änderung wird der Fehlerzähler nur zurückgesetzt, wenn der originale Index Fehlermarkierungen enthält:

Diff

--- cutter.c    2024/09/19 20:21:58     5.2
+++ cutter.c    2024/09/20 21:22:43
@@ -302,6 +302,10 @@
         maxVideoFileSize = MEGABYTE(Setup.MaxVideoFileSize);
         if (isPesRecording && maxVideoFileSize > MEGABYTE(MAXVIDEOFILESIZEPES))
            maxVideoFileSize = MEGABYTE(MAXVIDEOFILESIZEPES);
+        if (fromIndex->GetErrors()->Size() > 0) {
+           recordingInfo->SetErrors(0); // the fromIndex has error indicators, so we reset the error count
+           recordingInfo->Write();
+           }
         Start();
         }
      else
@@ -616,6 +620,9 @@
      if (frameErrors > recordingInfo->Errors()) {
         recordingInfo->SetErrors(frameErrors);
         recordingInfo->Write();
+        Force = true;
+        }
+     if (Force) {
         LOCK_RECORDINGS_WRITE;
         Recordings->UpdateByName(editedRecordingName);
         }
@@ -631,6 +638,7 @@
      if (!fromFile || !toFile)
         return;
      int LastEndIndex = -1;
+     HandleErrors(true); // to make sure an initially reset error count is displayed correctly
      while (BeginMark && Running()) {
            // Suspend cutting if we have severe throughput problems:
            if (Throttled()) {
@@ -706,8 +714,8 @@
               cRecordingUserCommand::InvokeCommand(RUC_EDITINGRECORDING, editedVersionName, originalVersionName);
               if (cVideoDirectory::RemoveVideoFile(editedVersionName) && MakeDirs(editedVersionName, true)) {
                  recordingInfo.Read();
-                 recordingInfo.SetErrors(0);
                  recordingInfo.SetFileName(editedVersionName);
+                 recordingInfo.Write();
                  SetRecordingTimerId(editedVersionName, cString::sprintf("%d@%s", 0, Setup.SVDRPHostName));
                  cuttingThread = new cCuttingThread(originalVersionName, editedVersionName, &recordingInfo);
                  return true;

Display More

vdr.5 wird entsprechend geändert:

Code

If this is an edited recording, the number of errors is that of the edited
recording, if the index of the original recording contains error indicators
(i.e. the original recording's index was created with VDR version 2.7.2 or
later). Otherwise it's the number of errors in the original recording.

wirbel · Sep 21st 2024

Quote from kls

wenn einige diesen Stand testen würden.
Dafür mussen eventuelle Plugins neu übersetzt werden.

Keine Probleme beobachtet bisher.

SHofmann · Sep 21st 2024

Quote from kls

If this is an edited recording, the number of errors is that of the edited recording, if the index of the original recording contains error indicators (i.e. the original recording's index was created with VDR version 2.7.2 or later). Otherwise it's the number of errors in the original recording.

Wie verhält sich denn das Ganze, wenn ich eine geschnittene Aufzeichnung nochmals "nachschneide"? Auch dabei könnten fehlerbehaftete Frames entfallen, was zu einem Update der Fehler führen sollte.

Gut wäre es, wenn man die Zähler aktualisiert, sobald bei jedem Schneiden einen Frame mit der "neuen" Fehlerkennung gefunden wird, und die alten Fehler nur dann stehen zu lassen, wenn beim Schneiden kein solcher Eintrag eingelesen wird?

Ist es das, was die eingangs zitierte Stelle besagen soll?

SHofmann · Sep 21st 2024

Noch eine Frage: Wenn ich – zum Beispiel fürs Testen der neuen Version – den Index einer fehlerhaften Aufzeichnung neu generieren lasse, erhalte ich dann eine Index-Datei im neuen Format?

Zumindest wäre das meine Vermutung…

kls · Sep 21st 2024

Ja, neu generierte Index-Dateien haben die neuen Flags bei Fehlern gesetzt.

Ist natürlich auch rückwärtskompatibel, neue Index-Dateien funktionieren also auch mit früheren VDR-Versionen (nur werden dort halt die Fehler nicht dargestellt).

kls · Sep 21st 2024

Quote from shofmann

Wie verhält sich denn das Ganze, wenn ich eine geschnittene Aufzeichnung nochmals "nachschneide"?

Was meinst du mit "nachschneide"?

SHofmann · Sep 21st 2024

Ich schneide dir originale Aufzeichnung (X -> %X) und dann die geschnittene nochmals (%X -> %%X). Um der Frage nach dem "warum" zuvorzukommen: Wenn man beim ersten Schneiden ein paar Frames der Werbung mitnimmt und diese bei zweiten Schneiden wieder entfernt, werden häufig Knackser und andere Störgeräusche, die (zumindest bei der TT S2-6400) an Schnittmarken manchmal auftreten, eliminiert. Kein Ahnung warum, ist halt eine heuristische Erkenntnis und könnte damit zusammenhängen, dass Bild und Ton im Videostrom versetzt sein dürfen und sich die "Natur" der Tonspur an Werbeblöcken meist ändert.

Quote from kls

Ja, neu generierte Index-Dateien haben die neuen Flags bei Fehlern gesetzt.

Und noch eine Frage: Könnte man beim Schneiden "alter" Aufzeichnungen nicht zusätzlich auch – ähnlich wie das Tool "addon-checkts" es macht – den Continuity Counter heranziehen, um Aufnahmefehler beim Schneiden zu erkennen und im Index zu vermerken?

Quote

vdr-checkts parses VDR recordings (only TS-recordings / vdr 1.7.x) and records any discontinuities in the transport stream by checking the continuity counter.

kls · Sep 21st 2024

Quote from shofmann

Ich schneide dir originale Aufzeichnung (X -> %X) und dann die geschnittene nochmals (%X -> %%X)

Das macht aus VDR-Sicht keinen Unterschied. Beim zweiten Schneiden ist %X wie jede andere Aufnahme, ob geschnitten oder nicht.

Quote from shofmann

Und noch eine Frage: Könnte man beim Schneiden "alter" Aufzeichnungen nicht zusätzlich auch – ähnlich wie das Tool "addon-checkts" es macht – den Continuity Counter heranziehen, um Aufnahmefehler beim Schneiden zu erkennen und im Index zu vermerken?

Beim Schneiden wird der CC neu berechnet. Hier auch noch Fehlererkennung einzubauen würde das alles nur noch komplizierter machen.

Lösch einfach vor dem Schneiden den alten Index und lass ihn neu berechnen. Oder lösch den der geschnittenen Aufnahme und lass den neu berechnen.

SHofmann · Sep 21st 2024

Quote from kls

Lösch einfach vor dem Schneiden den alten Index und lass ihn neu berechnen. Oder lösch den der geschnittenen Aufnahme und lass den neu berechnen.

Ich habe, um deinen aktuellen Stand testen zu können, bei einer "alten" Aufzeichnung den Index neu generieren lassen und die Aufzeichnung um eine mir bekannte Fehlerstelle herum geschnitten. Obwohl bein Schneiden also Fehler "mit geschnitten" wurden, sind in der geschnittenen Aufzeichnung keine Fehler verzeichnet. Laut deines Hinweises hätte ich die aber angezeigt bekommen sollen, richtig?

kls · Sep 21st 2024

Quote from shofmann

Ich habe, um deinen aktuellen Stand testen zu können, bei einer "alten" Aufzeichnung den Index neu generieren lassen

Wurden nach dem Neu-Generieren des Index in der Fortschrittsanzeige der alten Aufnahme Fehler angezeigt?

SHofmann · Sep 21st 2024

Nein, hier der Ablauf:

originale Aufzeichnung:

reindizierte Aufzeichnung:

Ein Fehler sollte bspw. bei 1:46:46 angezeigt werden, wo im Original die zweite
Schnittmarke zur Kennzeichnung der Fehlerstelle gesetzt ist).

geschnittene Aufzeichnung (ab 1:46)

Auch hier sollte ein Fehler bei 0:46 angezeigt werden.

Wie gesagt: Es handelt sich um eine "alte" Aufzeichnung ohne die neuen Marken, nur mit Fehlern im Continuity counter. Deshalb auch meine Anfrage, denn von solchen Aufnahmen sind wohl genügend viele "da draußen" im Umlauf.

kls · Sep 21st 2024

Benutzt deine Skin denn überhaupt die neue cProgressBar?

Falls nicht, teste bitte mal mit der LCARS-Skin.

SHofmann · Sep 21st 2024

Guter Tipp:

reindizierte Aufzeichnung

Was man hier in der Verkleinerung kaum sieht, am TV in groß aber schon: Ganz am Anfang wird auch eine Fehlermarke angezeigt. Das sollte wohl aber eher nicht so sein, richtig?
geschnittene Aufzeichnung

Auch hier erscheint am Anfang eine weitere Fehlermarke, sobald man die geschnittene Aufzeichnung reindiziert:

Ein Startwert-Problem, denke ich.

Insgesamt ist das jedenfalls eine tolle Sache, vielen Dank dafür!

Jetzt muss SkinNopacity das ebenfalls "nur" noch unterstützen.

kls · Sep 21st 2024

Quote from shofmann

Was man hier in der Verkleinerung kaum sieht, am TV in groß aber schon: Ganz am Anfang wird auch eine Fehlermarke angezeigt. Das sollte wohl aber eher nicht so sein, richtig?

Das sollte eigentlich die letzte Änderung im GIT ("Fixed syncing the frame checker to I-frames") gefixt haben. Zumindest hat sie das bei mir, denn ich hatte den Fehler davor auch.

Quote from shofmann

Tolle Sache, jetzt muss SkinNopacity das ebenfalls "nur" noch unterstützen.

Da kann der Autor ja bei cSkinDisplayReplay::cProgressBar "abschreiben ;-).

SHofmann · Sep 21st 2024

Quote from kls

Das sollte eigentlich die letzte Änderung im GIT ("Fixed syncing the frame checker to I-frames") gefixt haben. Zumindest hat sie das bei mir, denn ich hatte den Fehler davor auch.

Das ist auch bei mir der letzte Commit aus dem Git. Trotzdem habe ich dies Anzeige. Aber wird IndependentFrame denn auch beim Reindizieren passend (mit true, würde ich vermuten) vorbelegt?

Quote from kls

Da kann der Autor ja bei cSkinDisplayReplay::cProgressBar "abschreiben ;-).

Wenn es so einfach geht wie in LCARS, versuche ich mich selbst mal daran…

kls · Sep 21st 2024

Quote from shofmann

Aber wird IndependentFrame denn auch beim Reindizieren passend (mit true, würde ich vermuten) vorbelegt?

Beim Reindizieren wird der gleiche Code verwendet wie bei der Aufnahme.

Kannst du mir den Anfang der Aufnahme irgendwie zur Verfügung stellen?

Quote from shofmann

Wenn es so einfach geht wie in LCARS, versuche ich mich selbst mal daran…

Ganz so einfach wird es wohl kaum sein, denn LCARS musste nur den neuen Contructore verwenden.

SkinNopacity scheint die Fortschrittsanzeige komplett selber implementiert zu haben. Aber auch dort kann man das entsprechend einbauen, die Daten stehen ja zur Verfügung.

SHofmann · Sep 21st 2024

Wenn dir die erste Sekunde genügt:

Sample.zip

Quote from kls

SkinNopacity scheint die Fortschrittsanzeige komplett selber implementiert zu haben.

Ich denke, es könnte genauso einfach sein, denn bisher haben wir genau einmal im Code stehen:

Code

    cProgressBar pb(barWidth - geoManager->replayProgressBarHeight,
                    geoManager->replayProgressBarHeight - 2,
                    Current,
                    Total,
                    marks,
                    Theme.Color(clrReplayProgressSeen),
                    Theme.Color(clrReplayProgressRest),
                    Theme.Color(clrReplayProgressSelected),
                    Theme.Color(clrReplayProgressMark),
                    Theme.Color(clrReplayProgressCurrent));

An keiner anderen Stelle taucht cProgressBar sonst noch einmal auf. Der Rest scheint nur dazu zu dienen, deinen cProgressBar in die Grafik der Skin einzubetten.

SHofmann · Sep 21st 2024

So einfach war es auch. Hier für alle Fans des Skins ein Patch:

0003a Display of error marks in progress bar.zip
(jetzt in Übereinstimmung mit der Nomenklatur)

Aber mit der Farbe scheint es noch ein Problem zu geben. Für die Anzeige der Fehlermarken habe ich rot (FF.FF0000) eingestellt:

Solange die Aufzeichnung abgespielt wird und sich die aktuelle Position irgendwo zwischen Schnittmarken befindet, erscheint die Fehlermarke in der gewünschten Farbe (rot):
Sobald man auf die letzte Schnittmarke zurückspringt, ändert sich die Farbe der Fehlermarke und nimmt augenscheinlich die Farbe der Schnittmarke an (schwarz):

kls, kannst du dir das bitte nochmal ansehen? Da SkinNopacity wie auch SkinLcars identische Aufrufe habe, dürfte das Verhalten bei beiden gleich sein.

Und noch eine Frage: Könnte man denn die Fehlermarken nicht auch als Sprungziele für die Navigation mit 7 und 9 definieren, eventuell als einstellbare Option im OSD-Setup?

Bitte testen: Anzeige der Fehler in der Fortschrittsanzeige

Participate now!

Share