Stapelverarbeitung

[errat]

Ich habe mich für den TS Doctor begeistert, weil ich in den FAQs gelesen habe, dass eine Verarbeitung von der Kommandozeile aus möglich ist: TSDoctor "eingabe" AUTOFIX "ausgabe". Also habe ich mir cmd-Skripte gebaut, die über Nacht meine Aufnahmen von der Vantage HD6000 auf dem Computer im TS Format archivieren sollen. Den letzten Schritt für jede Aufnahme ist dabei der Aufruf von TSDoctor. Dabei musste ich aber feststellen, dass die Commandline  Verarbeitung bei den neuen Verbesserungen am Programm wohl etwas aus dem Fokus gerutscht ist.

Zunächst wird die Angabe der Ausgabedatei völlig ignoriert, es wird immer die Datei ...._fixed.ts im ursprünglichen Verzeichis erstellt. Dann interpretiert TSDoctor die Angabe AUTOFIX recht locker: Der Fix wird zwar sofort gestartet, aber von Auto keine Spur. Alle Dialoge werden so abgespult, wie in den Optionen definiert. Gut, die Optionen kann man so ändern, dass es keine Rückfragen mehr gibt, und meistens funktioniert alles einwandfrei. Nur manchmal bleibt der Herr Doctor nach getaner Arbeit regungslos auf dem Desktop stehen und hält die Stapelverarbeitung so lange auf, bis er mit dem Taskmanager abgeschossen wird. Danach läuft alles normal weiter, außer, dass das Temp-Verzeichnis nicht geleert wurde, was wieder eine Rückfrage beim nächsten Start verursacht. Eine Ursache für das Hängen konnte ich nicht ausmachen. Jedenfalls erhöhen Bewegungen auf dem Desktop, die das Arbeitsfenster von TSDoctor betreffen, die Wahrscheinlichkeit für den Aussetzer ganz enorm.

Die neue Batch Verarbeitung könnte natürlich eine gute Alternative zur Commandline sein, insbesonders, weil da auch das Zusammenmischen gesplitteter Dateien unterstützt wird. Allerdings kann zur Zeit einsolcher Batch wohl nicht automatisiert, sondern nur über einen vergleichsweise klickaufwendigen Dialog erzeugt werden.

Kann ich hoffen, dass es in Zukunft für meine Problemchen eine Lösung geben wird?

-errat-

[Cypheros]

Hi,

welche Version verwendest Du?

Die genannten Fehler sollten schon lange gefixt sein und eine eigene Batch-Verarbeitung ist implementiert.

[errat]

Ich habe diese Erfahrungen zuerst mit der Version 1.70 gemacht, und anschließend auch 1.74 mit dem gleichen Ergebnis probiert. Mein Rechner ist ein betagter Pentium IV mit Wndows XP SP3. Wenn diese Unstimigkeiten aus der Vergangenheit bekannt sind, bin ich gerne bereit weiterzutesten, wenn ich einen Hinweis bekäme, woran es liegen könnte.

Die implementierte Batchverarbeitung habe ich auch schon ausprobiert. Leider müssen in die Batchdateien außer den Dateinamen noch andere Angaben stehen, die mir nicht transparent sind. Daher kann ich sie nicht aus dem Inhalt der zu archivierenden Platte generieren.

Übrigens möchte ich hier definitiv nicht meckern. TSDoctor ist eins der besten Programme, die ich kenne. Allerdings, hohe Qualität weckt hohe Erwartungen.

-errat-

[Cypheros]

OK,

wenn ich das richig verstehe gibt es beim cmd noch immer das Problem, dass der Ausgabepfad nicht korrekt gesetzt wird?
Also bei TSDoctor.exe C:\Aufnahme.ts autofix D:\Archiv\Aufnahme_fixed.ts landet die Aufnahme auf C:\ ?

Was die Hänger angeht, so wäre es natürlich schön zu wissen wie dieser zu reproduzieren ist. Manchmal sind es bei solchen Problemen einfach nur Dialoge, die aus irgendeinem Grund nicht vor dem Hauptfenster sind sondern dahinter. Versuch dann mal bei so einem "Hänger" mit den Tasten "Alt & Tab" das aktive Fenster zu wechseln. Möglicherweise wird dann ein Dialog sichtbar, der auf eine Bestätigung wartet.

[errat]

Asche auf mein Haupt. In der Version 1.0.74 funktioniert in der Tat die Angabe der Ausgabedatei einwandfrei. Ganz offenbar war mir der Fehler mit einer älteren Version (die mit der c't verteilt wurde) aufgefallen und ich habe schlicht mit dem Workaround weitergearbeitet. Ist mir schon peinlich, hier alte Kamellen aufgetischt zu haben.

Was das Hängen angeht, bin ich mir aber sicher, dass das auch in 1.0.74 noch passiert. Ich werde bei nächster Gelegenheit mal den Trick mit alt+tab probieren, allerdings habe ich schon versucht, TSDoctor mit Start /wait /min ... minimiert zu starten. Das war aber noch schlimmer, weil man garnicht sehen konnte, dass nichts geht. Übrigens, wenn das TSDoctor Fenster untätig stehen bleibt, lässt es sich auch nicht mehr mit der Maus verschieben oder sonstwie verändern.

Ich fände es ja am schönsten, wenn bei Commanlinestart mit autofix konsequent jeglicher Dialog unterbunden würde. Zum einen verstehe ich die Hintergründe für die meisten Rückfragen so wie so nicht, zum zweiten ist das Programm viel kompetenter, als ich in absehbarer Zeit werden kann. Und letztlich handelt es sich bei den Aufnahmen um Satellitenaufzeichnungen, wo man immer mit Störungen durch Schnee oder Gewitter rechnen muß. Also auch damit, das man sie nachher nur noch wegschmeißen kann. Daher reicht es mir völlig, wenn mir das Logfile zeigt, ob und wo Fehler sein könnten. Aber in aller Regel gilt doch ohnehin: Was TSDoctor nicht fixen kann, kann man selbst auch nicht vernünftig reparieren.

-errat-

[errat]

Nachtrag:
Wenn man eingibt "TSDoctor.exe C:\Aufnahme.ts autofix D:\Archiv\Aufnahme_fixed.ts", wird in der Tat  D:\Archiv\Aufnahme_fixed.ts erstellt.

Wenn man die Zieldatei ohne Pfad angibt, also im aktuellen Arbeitsverzeichnis erstellen will, etwa so
"C:\Programme\Cypheros\TSDoctor\TSDoctor.exe C:\Aufnahme.ts autofix Recording.ts ",
dann wird C:\Aufnahme_fixed.ts erstellt und von Recording.ts ist nirgends was zu sehen. Dasselbe passiert auch bei einem syntaktisch falschen Dateinamen.
Offenbar ist also eine unqualifizierte Ausgabedatei falsch und wird ignoriert.

Wenn man das weiß, kann man damit leben. Man muß halt immer den Ausgabepfad angeben, notfalls durch Einfügen von %CD%\ vor dem Dateinamen.
Nur war ich bisher nicht auf diese Idee gekommen.

Ich habe inzwischen wieder einen "Hänger" erleben dürfen und "Alt & Tab"  ausprobiert. Aber ohne Erfolg, der Programmrahmen bleibt einfach stehen und der Mauszeiger wird zur Eieruhr, wenn er in den Rahmen kommt.

-errat-

[Cypheros]

Hi,

schaue ich mir für die nächste Version mal genauer an. Was hat der TS-Doctor denn als letztes gemacht, wenn der Hänger kommt? Ist das bei der Verarbeitung eines Streams oder wenn er fertig ist und vielleicht die Fehlerliste anzeigen will?

[errat]

Erst mal vielen Dank für die Mühe. Als Zeichen dafür habe ich erstmal meine C't Version richtig lizensiert.

Also das Hängen erfolgt nach Start von der Commandline, wenn der Stream fertig abgearbeitet ist. Mit der Anzeige der Fehlerliste kann es nicht unbedingt etwas zu tun haben. Ich habe nämlich mehrfach hintereinander versucht, das Verhalten der Ausgabedatei herauszufinden, jedesmal mit demselben fehlerfreien Stream. Beim vierten und beim sechsten Versuch kam es zum Hängen. Beide male stand noch eine Datei (...mixed...?) im temporären Verzeichnis. Nach Abbruch per Taskmanager wird ja jedesmal angeboten, das Problem an Microsoft zu senden, was ich natürlich verneint habe. Aber, wenn man da auf Details klickt, sieht man eine Art Dump, der mir absolut nichts sagt. Könnte es Sinn machen, bei nächster Gelegenheit diesen festzuhalten und Dir zur Verfügung zu stellen?  Wenn ich hier mal spekulieren darf, ich habe den Eindruck, dass das Hängen immer häufiger auftritt, wenn TSDoctor oft hintereinader gestartet wird. So als ob irgendein Speicherbereich überläuft, weil er nicht immer wieder vollständig freigemacht wird.

Übrigens, gibt es auch einen Commandline Aufruf für den File Merger? Bislang habe ich die Streamteile einfach mit Copy /B Teil1+Teil2+Teil3+...  Streamdatei.ts zusammen gebaut. Das funktioniert aber nicht recht, wenn die Teile von einer FAT-32 Partition auf eine NTFS Partition gebracht werden sollen.

Sehe ich es richtig, dass an der internen Batchverarbeitung noch gearbeitet wird? Wenn ich nicht irre, hat sich das .TSB format zwischen 1.0.70 und 1.0.74 angenehm geändert. Ich fände es ja toll, wenn Du das am Ende so offenlegst, dass man seine eigenen Batches ohne Dialog komponieren kann. Dann könnte ich auf die Commandline glatt verzichten.


-errat-

[Cypheros]

Hi,

welchen Receiver benutzt Du? Bei Comag- bzw. Ali-Chipsatz-Aufnahmen bringt copy/B nämlich Fehler in den Stream, da sich die Streamteile überlappen. Das interne Script enthält deshalb entsprechende Informationen, welche Pakete am Anfang und am Ende übersprungen werden sollen. Diese Werte kann nur eine vorherige Analyse liefern.

[errat]

Ich habe einen Vantage HD6000, der .trp, .001, .002, ... Teile  auf einer FAT formatierten Platte erzeugt. Bei Streams mit einer Gesamtgröße unter 4GB oder größeren Streams, deren Teile bereits auf einer NTFS Partition vorliegen, funktioniert copy /B da einwandfrei. Nur beim Kopieren von einer FAT-32 Quelle nach NTFS schlägt völlig unverständlich die FAT-32 Größenbeschränkung auch beim Ziel zu.

Das mit dem Überlappen ist schon interessant und zeigt, welch Nüsse Du zu knacken hast. Wenn aber eine vorherige Analyse die Angaben zu den zu überspringenden Paketen liefern kann, sollte das doch auch zum Zeitpunkt des Mergens herauszufinden sein, zumindest, wenn die Information vorliegt, dass diese Prüfung nötig ist.

Na, ich bin zuversichtlich, dass Du das hinkriegst.

-errat-

[errat]

Ich habe mal probehalber die alte Version 1.0.53 parallel installiert und in meine Stapelverarbeitung eingebunden. Der Stapel läuft inzwischen seit über 12 Stunden ohne Auffälligkeiten und hat in den 12 Stunden 52 Streams mit 211 GB bearbeitet. Es sieht daher für mich so aus, als ob das Hängenbleiben ein relativ neues Feature ist. Ich hoffe, das hilft weiter.

-errat-