Wenn dir die erste Sekunde genügt:
Wenn ich mir die CCs der Video-PID (5111) ausgeben lasse, dann sehe ich, dass die Pakete #1 und #4 (dazwischen liegen TS-Pakete von anderen PIDs) den gleichen CC haben (nämlich 11). Das triggert den cTsChecker.
Kann es sein, dass das bereits in der originalen Aufnahme so war?
Das Sample, dass ich hochgeladen habe, war in der originalen Aufnahme an 1:46 und dort nach der Reindizierung ohne Fehler (siehe die Screenshots oben). Auch nach dem Schnitt war am Anfang kein Fehler ausgewiesen. Doch nach Reindizierung der geschnittenen Aufnahme tritt jetzt genau an dieser Stelle ein Fehler auf. Ein Zufall?
Aber mit der Farbe scheint es noch ein Problem zu geben.
Die in cProgressBar verwendete Bitmap hat nur 2bpp. Das hat eigentlich schon bisher nicht für die im Konstruktor erlaubten 5 Farben gereicht, fiel aber nicht auf, wenn einige davon gleich waren.
Mach mal das hier und schau, ob es damit gefixt ist:
--- skins.c 2024/09/19 09:49:02 5.3
+++ skins.c 2024/09/21 16:04:47
@@ -152,7 +152,7 @@
}
cSkinDisplayReplay::cProgressBar::cProgressBar(int Width, int Height, int Current, int Total, const cMarks *Marks, const cErrors *Errors, tColor ColorSeen, tColor ColorRest, tColor ColorSelected, tColor ColorMark, tColor ColorCurrent, tColor ColorError)
-:cBitmap(Width, Height, 2)
+:cBitmap(Width, Height, 4)
{
total = Total;
if (total > 0) {Ein Zufall?
Keine Ahnung. Lass uns das mal weiter beobachten, ob noch mehr solcher Effekte auftreten.
Den Effekt konnte ich bislang mit jeder Aufzeichnung, die ich reindiziert habe (mit oder ohne vorheriges Schneiden), reproduzieren. Dabei war es egal, ob sie original völlig fehlerfrei waren oder erst nach dem Schneiden. Nach dem Reindizieren ist eine Zahl von null Fehlern vermerkt ("O 0"), eine Fehlermarke ganz am Anfang erscheint aber dennoch.
Das müsstest du bei dir mit eigenen Aufzeichnungen ebenso leicht reproduzieren können.
Eine Frage noch am Rande von mir, sind die Paketbauer mit der Namensgebung der Plugins einverstanden?
libvdr-foo.so.5 -> vdr plugin foo mit VDR API = 30005
sind die Paketbauer mit der Namensgebung der Plugins einverstanden?
Waren es denn nicht die Paketbauer, die eine völlig unterschiedliche Nummerierung wollten?
Das müsstest du bei dir mit eigenen Aufzeichnungen ebenso leicht reproduzieren können.
Tatsächlich! Ich hab soeben eine kurze Aufnahme gemacht (fehlerfrei), dann den Index gelöscht und die Wiedergabe gestartet , und es wurde ein Fehler am Anfang gemeldet. Ich gehe dem nach.
Eine Frage noch am Rande von mir, sind die Paketbauer mit der Namensgebung der Plugins einverstanden?
libvdr-foo.so.5 -> vdr plugin foo mit VDR API = 30005
Der Unterschied ist eigentlich nur ein Problem für Plugin Entwickler. Die 30000 Offset sind nötig damit die Nummer steigend bleibt.
Für die Paketbauer ist die API Version die "5". Ich werde mit dem nächsten VDR Update auch bei Arch nur die eigentliche Version ohne das rein interne Offset hinterlegen.
Für die Paketbauer ist die API Version die "3".
Es ist inzwischen die '5' ;-).
Ja. Sorry. Zu spät editiert 😂
Ein bisschen Spaß muss sein, dann ist die Welt voll Sonnenschein. 🤣
Beim Index-Regenerieren wird die Video-Datei nach dem Einlesen der PAT/PMT zurückgespult ("rewind"), daher hat der FrameDetector die ersten Pakete zweimal gesehen.
Erfolgreich getestet - Danke wieder einmal! 
Funktioniert auch mit gepatchtem skinlcarsng, Danke!
Ich weiß nicht, ob es einen Hinweis im Code oder der History gibt, dass die index Dateien neu generiert werden müssen, damit was angezeigt wird? Dieser Hinweis und wie man das macht, wäre vielleicht noch hilfreich.
Ich habe auch gesucht, ob es eine vdr/genindex-Option gibt, die alle index Dateien auf einmal neu erzeugt. Gefunden habe ich nichts, auch kein fertiges Skript. Daher habe ich einfach folgenden Einzeiler über Nacht durchlaufen lassen:
for i in $(find -name *.rec); echo $i; do /usr/local/bin/vdr --genindex $i; done... fürs Archiv
Beim Index-Regenerieren wird die Video-Datei nach dem Einlesen der PAT/PMT zurückgespult ("rewind"), daher hat der FrameDetector die ersten Pakete zweimal gesehen.
Hallo Klaus, ich habe den VDR mit deinen Patches jetzt seit ein paar Tagen am Laufen und auch die Skins LCarsNG und Nopacity mit dem neuen Aufruf von cProgressBar gepatcht. Die neue Behandlung der TS-Fehler funktioniert super, und mein Workflow zum Schneiden einer fehlerbehafteten Aufzeichnung hat sich – ohne die nun nicht mehr erforderliche Nutzung externer Tools und der entsprechenden Zusatzarbeiten – erheblich vereinfacht.
Was ich noch vermisse, ist die Möglichkeit, Fehlermarken direkt anspringen zu können. Da ich die Tasten 1 und 3 zum schnelleren Setzen von Schnittmarken aufgrund der Verwendung von markad (Dank dafür an kfb77 !) so gut wie nie benötige, fände ich es klasse, wenn man sie in den OSD-Einstellungen für das Navigieren zwischen Fehlermarken umwidmen könnte.
Danke & Grüße
Stefan
Codefor i in $(find -name *.rec); echo $i; do /usr/local/bin/vdr --genindex $i; done
denke, das sollte eher so aussehen:
for i in $(find . -name "*.rec"); do
echo $i
/usr/local/bin/vdr --genindex $i
donewenn ich mich nicht irre
Oh, falsch abgeschrieben...
Als Einzeiler für die Kommandozeile:
for i in $(find -name *.rec); do echo $i; /usr/local/bin/vdr --genindex $i; doneDie " und den Punkt brauch ich für find hier nicht zwingend.
Don’t have an account yet? Register yourself now and be a part of our community!