Hallo,
als erstes was zum -ignore:
den -ignore Schalter habe ich ursrpünglich eingebaut, um Audio-Spuren rauszuwerfen. Erst
später kam dann auch bei mir die Idee, den Schalter für Audio-Extraktion zu nutzen. Allerdings
habe ich das bisher nicht über ignore gemacht, sondern über
-dump-payload
Kurze Erklärung:
Der -ignore Schalter veranlasst, das PES-Pakete, die zu einem "ignore-Stream" gehören, sehr früh
verworfen werden, also sobald der Stream "erkannt" wird. Vorteil: Geschwindigkeit.
Ignore wird automatisch für Streams gesetzt, mit denen vdrsync nix anfangen kann, zB Teletext.
Ich habe hier kein Teletext bzw war zu faul, auch noch die PIDs rauszufummeln.
Nachteil: wenn man den Videostream "ignored", dann kann man gegen nichts synchronisieren.
vdrsync bricht ab, sobald es versucht, die Audiospuren zu syncen.
Das hat mich persönlich allerdings nie gestört, weil das reine Extrahieren einer Audiospur mit
-ignore e0,c1,c2,bd -dump-payload 99999999
für die erste Audiospur ohnehin schneller ging. Das hat allerdings wiederum schwere Nachteile, die
mir erst nach eurem Feedback aufallen:
- vdrsync verwirft beschädigte (= "halbe") AudioFrames, wie sie VDR beim schneiden manchmal
erzeugt. Die Option "-dump-payload" schreibt diese allerdings mit raus, so dass es dem
nachfolgenden Programm überlassen bleibt, dass zu fixen. Gar nicht gut 
- Wenn man nur die Audiospur extrahieren möchte, um sie anschliessend wieder mit dem Video
zusammen zu bringen, dann synct vdrsync die Audiospur nicht mit dem Video (ist ja ein dump, also
("roh wie sie kommen auf die Platte").
Lösung: Sehr kleine Anpassungen in vdrsync, die das rausschreiben einer gsyncten Audiospur
ermöglichen, auch wenn Video ignoriert wird. Es handelt sich nur um ein Verlagern der Abfrage
PSEUDO-CODE
If ignore stream then next
/PSEUDO-CODE
von der Stream Identifizierung zu der Stelle, an der die Daten tatsächlich rausgeschrieben werden.
Vorteil: vdrsync würde gesynct(!) und gefixt (!) die Audiospuren schreiben
Nachteil: Es dauert länger, allerdings immer noch schneller als ein "normaler" vdrsync Durchlauf.
Wer will testen? (Wie mplayer bei geschnittenen Aufnahmen "dumped" weiss ich nicht, ob mit oder ohne "Fix" von kaputten Frames)
@ Dimitri
Es sieht so aus, als hättest Du einen Bug gefunden, bei mir funktioniert
./vdrsync -ingore c1,c2,bd
völlig ok. Der Parameter Parser ist allerdings auch noch als rudimentär einzustufen, vielleicht
verstolpert sich vdrsync an der Stelle. Wie sieht der vdrsync-Aufruf genau aus?
Achja, die intermediate Version, die ich in der PM verlinkt habe, kann auch ein Verzeichnis als
Parameter akzeptieren - überfälliges Feature, das ich nicht erwähnt habe :wand. Also ist es nicht
mehr nötig, alle .vdr Files einzeln anzugeben. Wenn man Verzeichnisse und Dateien mischt, dann
gibt es Murks, aber ich wollte die alten Optionen nicht löschen. Konkret:
vdrsync /PATH/001.vdr /PATH/002.vdr -OPTION
sollte funktionieren, ebenso
@ Anonymous
zu der Download Section:
Fände ich recht gut, weil ich selber nicht den wirklichen Ueberblick habe, wer wo wie weit ist. Für
vdrsync selber gibt es dank Dimitri 
eine rudimentäre Homepage, die ich eigentlich erst
ankündigen wollte, wenn ich die "neue" sync-engine fertig habe. So schnell, wie Ihr alle mit
Ideen und Vorschlägen seid, kann ich allerdings ohnehin eine "stable" Homepage vergessen 
zu den Install-Paketen:
Ursprünglich hatte ich gehofft, Mitstreiter für vdrsync selber zu finden, mittlerweile finde ich das,
was hier abgeht noch viel besser. Es ist allerdings auch noch viel schwerer zu koordinieren, d.h. im
Moment macht jeder, was er toll findet - freie Software eben
Mein Ziel wäre im Moment für das gesamte Projekt:
- vdrsync soweit zu verbessern, dass es (fast) immer funktioniert. Ich denke, das ist schon nicht
so schlecht, weiss aber selber, dass noch einige Sachen"wackeln"
- Die Integration mit Dimitris Skripts zu optimieren, d.h. vdrsync tut, was es soll, ohne Kopfstand
für Dimitris Skripts. Bsp: Es ist totaler Blödsinn für skripts, dass vdrsync die Video-Datei eX.mpv
nennt, anstatt einfach Video.mpv. Für die Entwicklung und fürs debuggen war das ok, aber jetzt
muss jedes Skript selber nachsehen, ob es e0, e4 oder e7 war, was der Sender als Video
ausgestrahlt hat - das ist möglich, aber Murks. Ich traue mich aber kaum noch, das zu ändern,
weil die Skripte das sowieso schon abfangen - hmmmmmmm, was jetzt?
- Auf mittlerfristige Sicht ist ein Paket mit Installations-Skript/Anleitung mein Ziel, ich würde auch
versuchen, ein install zu schreiben (allerdings in Perl ;)), momentan fehlt allerdings sowohl Zeit als
als auch eine stabile Grundlage. Abwarten.... bis jetzt kommt alles beser, als geplant
Und jetzt bin ich viiiiiiiieeeeellll zu müde, um noch was anderes zu schreiben....
Cheers
doc
