Danke für das Log!
Reboot ist natürlich ganz schlecht!!
Vermutlich weisen diese Aufnahmen irgendwelche Besonderheiten auf. Das müssen wir rausfinden.
Und die RecStrip.log ist sicher ganz leer??
@Sirius: Ich hab eine Idee, woran es liegen könnte:
Besitzen deine beiden Aufnahmen Schnittmarken von MovieCutter?
Wenn ja, dann lösche diese mal vollständig (mit MC) und verarbeite die Dateien nochmal mit RecStripper!
Edit: Oder Töppies Vorschlag - das macht auch Sinn!
[quote=""Sirius""]
1. Die beiden Aufnahmen wurden noch nicht geschnitten.
2. Regionalfenster? keine Ahnung, im Vorlauf ist ein Stück NDR//Aktuell.
Ich teste nachher noch mal mit anderen Dateien ..
.[/quote]
1. Die frage ist, ob Schnittmarken (also Segmente) angelegt wurden! Egal, ob tatsächlich geschnitten oder nicht... Wenn ja, die Segmentmarken entfernen!
Test mit anderer Datei von Das Erste HD.
3353MB geschrumpft auf 2367MB.
Beide Log Dateien vorher umbenannt.
1. Es wurde nun auch eine RecStrip.log angelegt
2. Infotafel vorhanden, da nun .inf existiert
3. Spulen funktioniert
Verbleibende Zeit wurde mit ca. 1200s angezeigt (20 Min.)
Nach ca. 13 Min. fror TV Bild ein, Ton lief noch, nach 15 Sek. kam Meldung:
RecStripper beendet. 0 von 1 Dateien erfolgreich verarbeitet. => OK
Keine Reaktion auf OK => Receiver mit Power neu gestartet.
Aber die Datei war wie oben geschrieben im RecStrip_Out vorhanden und voll funktionsfähig.
Hier die Logs.
Beim zweiten Versuch (ohne TAPs gestartet) gab es nach 13 Min. einen Reboot.
Hab ich jetzt erst bemerkt: Beim Spulen (2x) gab es doch ab und an minimale Artefakte, Klötzchen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
ES WARNING: For PID 13F2 AC3 properties changed at 00:04:09.496 (2.0 48kHz >>> 5.1 48kHz)
ES WARNING: For PID 13F2 AC3 properties changed at 01:31:01.368 (5.1 48kHz >>> 5.0 48kHz)
ES WARNING: For PID 13F2 AC3 properties changed at 01:31:01.432 (5.0 48kHz >>> 2.0 48kHz)
Am PC gestripped (neu kompilierte Version, Visual C++ Update nicht nötig):
Packets: 48896844
Dropped (NALU): 12575692 (25%)
Dropped (all): 16478016 (33%)
Elapsed time: 235sec.
Ich bin total begeistert
Zum Spulen in der gestrippten Aufnahme bin ich noch nicht gekommen, das Traumschiff
ist gerade wichtiger
[quote=""Alter Sack""]Zum Spulen in der gestrippten Aufnahme bin ich noch nicht gekommen...[/quote]
Das Spulen funktioniert zwar von 2x bis 64x, das Bild ist aber mehr oder weniger stark verpixelt
oder mit Doppelkonturen versehen, je mehr Bewegung im Bild, desto stärker die Störungen.
Eine bestimmte Stelle im Film lässt sich aber auch trotz der Störungen noch finden, im Original
läuft es aber eben absolut flüssig, außer beim Schneiden spule ich aber eigentlich nie, insofern
für mich nicht tragisch.
[quote=""Alter Sack""]Das Spulen funktioniert zwar von 2x bis 64x, das Bild ist aber mehr oder weniger stark verpixelt
oder mit Doppelkonturen versehen, je mehr Bewegung im Bild, desto stärker die Störungen.
[/quote]
Sag ich ja - das Spulen ist der kritische Punkt...
Was du beschreibst klingt so, als könnte auch die nav dran schuld sein. (RecStrip passt diese an, aber vllt. macht es dabei noch Fehler... )
Könntest du vielleicht einmal folgenden Test mit dieser Aufnahme machen?
Die nav-Datei umbenennen und anschließend mit RebuildNav eine neue erzeugen lassen. Geht das Spulen dann besser?
Falls ja, wäre es klasse, wenn du mir diese beiden navs zukommen lassen könntest, damit ich den Fehler suchen kann...
So, ich habe jetzt den ersten Test mit einer Aufnahme von EinsFestival HD durchgeführt. 4,7 GB -> 3,5 GB, also eine satte Ersparnis. Inhalt ist gleich, Springen geht, Spulen auch, aber mit deutlichen Bildstörungen.
Logs (warum gibt es zwei verschiedene?) hängen an. Das Log enthält auch eine Fehlermeldung.
Gruß, Horst
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
[quote=""chris86""]Die nav-Datei umbenennen und anschließend mit RebuildNav eine neue erzeugen lassen. Geht das Spulen dann besser?[/quote]
Mit der neuen Nav, die RebuildNav erstellt hat, klappt das Spulen wieder einwandfrei, Du hast Post.
habe ich jetzt auch bei 2 Aufnahmen, die über Nacht gestrippt wurden, es sind alte Aufnahmen
von Sky HD aus 2010 und 2011, jeweils um die 16GB groß (Avatar + Robin Hood).
Details konnte ich mir noch nicht angucken, sie sind aber vermutlich geschnitten und enthalten
Vorschaubilder aber keine Sprungmarken, falls das auch einen Einfluß haben könnte.
Ich habe den Avatar jetzt mal von TSDoctor checken lassen, es gibt 6 Warnungen und 3 Fehler,
die aber auch beim Original (geschnitten) gefunden werden.
[quote=""chris86""]Reboot ist natürlich ganz schlecht!![/quote]
Ich habe mal einen 2100er TMS aus dem Keller geholt, den Sirius ja scheinbar nutzt.
Bei dem sind Reboots fast ein Dauerzustand, aber es liegt wohl nicht an der Prozessorleistung,
der 16GB Avatar läuft komplett durch, auch die Kopie ist vorhanden, der Reboot kommt immer
am Ende des Schrumpfung (wenn das Logfile geschrieben wird ?).
RecStripper durfte sich ganz alleine austoben, kein anderen TAPs, kein Netzwerkkabel, nicht
mal ein SAT-Leitung war dran.
Selbst die 1min SD-Tagesschau, die ich Dir geschickt habe, führt zum Reboot ... aber nicht immer.
Auch mit einem 1-minütigen Schnipsel von RTL-SD lässt sich das reproduzieren, mal klappt es,
mal gibt es einen Reboot, für den Reboot sind max. 2-4 Versuche nötig.
Was mir id dem Zusammenhang noch aufgefallen ist, es fehlt noch eine Prüfung, ob die zu
bearbeitende Aufnahme im Zielordner schon vorhanden ist.
Die gleche RTL-SD-Aufnahme kann ich beim 2401 20x nacheinander durchlaufen lassen, einen
Reboot gibt es nie, nur das angezeigte Ergebnis ist nicht immer gleich, mal wird 0/1 und mal 1/1
angezeigt, die Aufnahmen sind aber im Zielordner vorhanden, der Dr. hat auch nichts zu meckern.