Logdatei-Handling bei mehrteiligen Quellen

Begonnen von tsduser, April 30, 2021, 14:19:50

« vorheriges - nächstes »

tsduser

Tja, ich weiss nicht, ob's ueberhaupt was bringt, wenn ich noch etwas poste, aber ich probiere es einfach noch ein weiteres Mal.
Auch wenn meine letzten Nachrichten (uebermittelte 192er-Datei zum Testen, Probleme beim Raw Cutter) keinerlei weitere Reaktion auszuloesen vermochten, bin ich immerhin froh, dass meine Sorgen hinsichtlich der ueber eine Woche ausbleibenden neuen Posts von Mam (nach der Erwaehnung der Impfnebenwirkungen) und Cypheros unbegruendet waren.

Zum Problem:
Man nehme
- den Doctor 3.1.12
- Zwei Ordner 00001 und 00002 irgendwo
- in den Ordnern jeweils mehrteilige .ts-Dateien zum "Nur überprüfen"

Nun werden die .ts aus 00001 in den Doc gedroppt, und ueberprueft. Geht, gut.
Dann werden die .ts aus 00002 in den noch immer offenen Doc gedroppt, und ebenfalls ueberprueft.
Geht auch, aber warum erscheint keine .log-Datei im Ordner 00002?
Richtig, weil sie soeben die vorher erstellte Logdatei im Ordner 00001 ueberschrieben hat, statt wie auch schon vor langer Zeit steif und fest (trotz gegenteiliger belegender Screenshots) behauptet im Ordner der Quelldateien erstellt zu werden.
Wenn man vor der Ueberpruefung der Dateien im zweiten Ordner den ersten Ordner loescht oder umbenennt, kommt stattdessen die Warnung "Fehler beim Schreiben der Logdatei."

Wichtig ist hier die Verwendung von mehrteiligen Quelldateien; bei Einzeldateien funktioniert es anscheinend sauber mit dem Schreiben des Logs in das Verzeichnis der einzelnen Quelldatei.
Ebenso klappt es, wenn man nur eine einzelne Datei einer mehrteiligen Quelle auf den Doc droppt, und der Dialog "Mehrteilige Quelle entdeckt" erscheint und bestaetigt wird (ausser, wenn man diesen Dialog abgeschaltet hat, oder der Doc die Mehrteiligkeit nicht erkennt). Man muss also tatsaechlich mehrere Dateien zusammen in das Doc-Fenster fallenlassen, um das Problem zu reproduzieren.
Ebenfalls tritt das Problem nicht auf, wenn man zwischen den beiden Ueberpruefungen der zwei Ordner noch was an den Dateien im zweiten Verzeichnis mit dem Doc veraendert, z.B. mit dem Raw Cutter. Dann wird offenbar die interne Doc-Variable "aktueller Ordner" tatsaechlich angepasst.
Immerhin muss man der beeindruckenden Faehigkeit des Doc, die korrekte Reihenfolge der gedroppten Segmente zu erkennen, Anerkennung zollen!

Versteht mich bitte nicht falsch: Ich bin weder der Ansicht, dass die gemeldeten Probleme existenziell wichtig waeren, noch dass sie umgehend angegangen werden muessten, aber wenigstens mal so ein Hinweis "Repro hat geklappt", "Auch damit kein Problem bei mir" oder "Schau ich mir bei Gelegenheit mal an" waere nach fast zwei Wochen nett gewesen. Selbst ein "Interessiert mich nicht weiter" haette der nagenden Unsicherheit entgegenwirken koennen.

Erneut vielen Dank fuer's Lesen bis hierher.

Cypheros

Kann ich leider nicht reproduzieren. Gibt hier keinerlei Probleme mit einer solchen Konstellation.

Natürlich habe ich versucht Deine 192 Byte-Problematic mit deinen Dateien zu lösen aber noch keine Lösung gefunden, die nicht dazu führt, dass die bisherige Erkennung von Paketen darunter leidet.

Es gibt Receiver, die 1 MByte Müll am Anfang haben und da ist es schwer zuverlässig den Anfang zu finden. Habe nach 10 Jahre auch bisher noch keine Aufnahme gehabt, die am Anfang im M2TS-Header den Startcode 0x47 hatte.



tsduser

#2
Vielen Dank fuer die Antwort, und auch fuer's Ausprobieren sowie Deine Nachsicht mit meinem Gekeife.

Ganz klar: Die bestehende Erkennungsfunktionalitaet darf durch etwaige Aenderungen nicht verschlechtert werden; das ist's nicht wert. Problem-umgehende Abhilfen sind ja bereits beschrieben. Und andere Programme haben mit solchen Dateien ebenfalls, teils noch gravierendere, Probleme (z.B. DGAVCIndex oder DGIndex; DGIndex2 dagegen laesst sich damit nicht verunsichern)

Dass das Logdatei-Problem so wie ich es beschrieben habe nicht reproduzierbar sein soll, kann ich dagegen nur schwerlich nachvollziehen.
Ich hatte das, wie auch schon vorher beschrieben, mit mehreren Rechnern und TS-Doctor-Installationen ueberprueft, bevor ich's hier gepostet habe.
Sicherheitshalber habe ich gerade eben trotzdem nochmals
- Per frisch heruntergeladenem Media Creation Tool eine Win10-Installations-ISO (20H2 vom November 2020) erstellt
- Eine HyperV-VM damit in Pro-Version (ohne Netzwerk) erstellt
- TSD 3.1.12 neu heruntergeladen, und darin installiert (Default, und keinerlei Anpassungen oder Einstellungsaenderungen)
- Auf dem lokalen Datentraeger der VM den Ordner C:\Versuch und darin die beiden Ordner 00001 und 00002 erstellt
- In die beiden Ordner jeweils 2 64MB-Dateien chunk1.ts und chunk2.ts (mit 188er Packets) gelegt
- Noch einen Ordner 00003 mit nur einer der beiden Dateien chunk.ts erstellt
- Per Taste "M" beide .ts im Ordner 00001 ausgewaehlt (TSD erkennt korrekt 128MB Gesamtgroesse)
- "Nur überprüfen" angeklickt
- Pruefung wird ausgefuehrt-> Ergebnis: "Fehler beim Speichern der Logdatei. Zugriff verweigert."
- Beide .ts im Ordner 00002 aus dem Windows-Explorer auf das TSD-Fenster gedroppt (TSD erkennt korrekt 128MB Gesamtgroesse)
- "Nur überprüfen" angeklickt
- Pruefung wird ausgefuehrt-> Ergebnis: "Fehler beim Speichern der Logdatei. Zugriff verweigert."
- Die einzelne Datei in 00003 ausgewaehlt
- "Nur überprüfen" angeklickt
- Pruefung wird ausgefuehrt -> Ergebnis: Logdatei chunk_check.log wird in 00003 geschrieben
- Per Taste "M" beide .ts im Ordner 00002 ausgewaehlt (TSD erkennt korrekt 128MB Gesamtgroesse)
- "Nur überprüfen" angeklickt
- Pruefung wird ausgefuehrt-> Ergebnis: Logdatei chunk_check.log im Ordner 00003 wird ueberschrieben (Obwohl die Dateien in 00001 chunk1.ts und chunk2.ts heissen!).

Ich denke, es ist wichtig, dass vor und bei diesen Schritten bei einer sauberen Neuinstallation auch tatsaechlich nichts anderes aus dem TS-Doctor vorher ausgefuehrt wird, was moeglicherweise schon irgendwelche Parameter vorbelegen koennte.

Wenn sich auch das Dialog-Problem beim Raw Cutter bei Dir nicht reproduzieren laesst, stellt sich mir nur noch die Frage: Wie komme ich an Deine TS-Doctor Version? Denn der offizielle Download beseitigt meine Problemchen nicht.

Zu meiner Rechtfertigung:
OK, lizensieren wuerde ich die 3er dann schon noch. Aber bisher habe ich halt in den 3er-Versionen dieselben Probleme wie in meiner liebgewonnenen 2.1.44, die ich trotzdem weiterhin zum Erstellen der Aufnahmen-Info-Datei bei "Nur Pruefung" ausfuehren muesste...
Die berichtigte Datumserkennung und das schickere Pulsmeter reichen mir bisher nicht aus, denn all die anderen Verbesserungen der letzten Jahre zielen an meinen Anwendungsfaellen vorbei. Die Aussicht auf Korrekturen in einer 3er-Version (die in einer 2.1.44 wohl eher ausgeschlossen sind) waere da eine echte Entscheidungshilfe. Denn dass aktiv weiterentwickelt wird, und auch auf Hinweise aus dem Forum oefters eingegangen wird, ist absolut unbestritten.

Cypheros

OK, das Problem liegt am Mergen über M, wenn dann nur überprüft wird. Es wird dann als Dateiname ein leerer String übergeben, da ja keine neue Datei erstellt wird. Dies ist in der Version 3.1.13 behoben.

tsduser

Super, funktioniert bestens bei mir! Auch beim Droppen statt Oeffnen mit M. Vielen Dank!

Fair ist fair: Bestellung ist raus, Ueberweisung ebenfalls. Schauen wir mal, wie schnell die Spasskasse Pdb hausintern arbeitet :-)

In diesem Zusammenhang (gut, sieht zwar gleich wieder aus nach "kleiner Finger, und schon ist der Arm bis zum Schulterblatt weggebissen"):
Jetzt, wo klar ist, dass es sich um eine nicht gefuellte Variable handelt, waere es natuerlich zusaetzlich schoen, wenn auch die 3.1er usw. wieder Aufnahme-Infos beim "Nur überprüfen" schreiben wuerde (falls der entsprechende Code noch auskommentiert in der Quelle vorhanden ist). Vielleicht war es ja derselbe Variablenbereich...

tsduser

#5
Tja, leider offenbar zu frueh gefreut...

Die 3.1.13 funktioniert anscheinend nur mit den Quellen aus meinem damaligen Testaufbau; bei aktuellen Quelldateien gibt's den Fehler das Verhalten immer noch (egal ob 188er oder 192er Dateien):
- Zwei Pfade 00001 und 00002
- In 00001 eine einzelne record.ts-Datei
- In 00002 zwei zusammenhaengende Dateien record.ts und record.ts1
- Die einzelne Datei aus 00001 in den Doc 3.1.13 plumpsen lassen, Nur überprüfen -> Log record_check.log wird in 00001 geschrieben (OK)
- Verzeichnis 00001 loeschen oder umbenennen
- Beide Dateien aus 00002 in den Doc (oder auch in den "M"-Dialog) werfen, Nur überprüfen -> "Fehler beim Schreiben der Logdatei. Das System kann den angegebenen Pfad nicht finden" (ohne Punkt am Ende)
- Verzeichnis 00001 wieder verfuegbar machen
- Wieder beide Dateien aus 00002 in den Doc, Nur überprüfen -> Keine Fehlermeldung, aber record_check.log ueberschreibt (oder legt neu an) die Datei in 00001

Werfe ich nur eine der beiden Dateien aus 00002 auf den Doc, lasse ihn die Mehrteiligkeit der Aufnahme selbst erkennen, und bestaetige die Korrektheit dieser Erkenntnis, wird record_check.log auch korrekt in 00002 geschrieben.

Dasselbe passiert uebrigens, wenn die beiden Dateien in 00002 stattdessen 000.ts und 001.ts heissen. Vielleicht mag dabei als Hinweis gelten, dass im Falle der Wiederexistenz von 00001 (nach Auftreten der o.a. Fehlermeldung bei dessen Abwesenheit) die neue Logdatei dort trotzdem wieder record_check.log heisst, und nicht wie eigentlich ja zu erwarten 000_check.log...

Mindestens eine Variable wird immer noch nicht richtig (re-)initialisiert beim Nur überprüfen...

Nachtrag:
Und dann auch noch zu frueh geschrieben:
Bei den Tests oben habe ich durchgehend mit derselben offenen Doc-Instanz gespielt. Wird dagegen fuer jedes neue Verzeichnis der Doc geschlossen und wieder neu geoeffnet, klappt's auch bei mehrteiligen Dateien sauber. Aber das kann's irgendwie doch nicht sein, oder?


www.cypheros.de