RecStripper - TAP zum Schrumpfen der Aufnahmen

[chris86]

[quote="Sirius"]
Das hat bei mir auch zunächst funktioniert, aber momentan strippt er gerade und ich bekomme den Fortschritt nicht mehr eingeblendet.
Gibt es einen Trick, den Fortschritt wieder einzublenden? (mit Weiß geht es momentan nicht mehr).

Oder darf man eine bestimmte Taste (Exit ?) nicht drücken während des Hintergrundstrippens?[/quote]

Wie in der Beschreibung aufgeführt, dient zum Ein- und Ausblenden des Fortschrittsbalkens ausschließlich die weiße Taste.
Drücken der Exit-Taste (bei eingeblendeter Fortschrittsanzeige) führt plangemäß zum sofortigen Abbruch des Strip-Vorgangs.
Zumindest in der Theorie. In der Praxis hat sich (wie oben geschrieben) gezeigt, dass der Hintergrundprozess aktuell häufig nicht richtig abgebrochen wird.

[HD_Topfgucker]

[quote="chris86"]@HD_Topfgucker:
SourceCode steht jetzt online. Eigenes Kompilieren unter Linux geschieht auf eigene Gefahr.
- Sollte aber jetzt (sowohl in 32bit, als auch 64bit) möglich sein.
Wenn du es versuchst, würde ich mich über Rückmeldung (läuft es durch / funktioniert das Abspielen und Spulen auf dem Topf / was sagt das Log bzw. die Ausgabe) freuen.[/quote]

Hallo Chris,

Ich habe deine Sourcecodes mal unter Opensuse 13.1 32 Bit kompiliert.

Das Programm läuft nach ersten Tests komplett durch. Die geschrumpften Streams lassen sich abspielen.
Ich werde mich mal daran machen und eine komplette Serie auf einer externen jfs formatierten Festplatte zu schrumpfen.
Bis jetzt hatte ich noch nicht die nötige Zeit mich darum zu kümmern. Das Problem mit den nicht erzeugten
Inf Dateien scheint gelöst zu sein.
Hatte allerdings noch eine ältere mit MC geschnittene Datei bei der nach dem Strippen keine Inf erzeugt wurde.

Berichte später wieder

Grüße aus Thüringen
HD_TOPFGUCKER

[chris86]

Hatte allerdings noch eine ältere mit MC geschnittene Datei bei der nach dem Strippen keine Inf erzeugt wurde.

Vielen Dank für die ausführliche Rückmeldung!
Die inf wird dann nicht erzeugt, wenn während des Strippens ein Fehler auftritt und/oder die Datei nicht komplett verarbeitet werden kann.
Mich würde hier die (Log-)Ausgabe von RecStrip interessieren.
Falls sich das Problem reproduzieren lässt, wäre es super, wenn ich evtl. auch einen Blick auf diese Aufnahme werfen könnte...

[chris86]

Soo, es gibt nun eine neue Beta-Version von MovieCutter 3.6, die einige Verbesserungen bei der Verwaltung von Hintergrund-Prozessen mitbringt. Dies...

• ... behebt den Fehler, dass ein Strip-Vorgang im Hintergrund nicht korrekt abgebrochen werden konnte.
• ... reduziert die CPU- und HDD-Last während des Strippens deutlich.
• ... ermöglicht eine verlässlichere Status-Anzeige.

Die neue Version ist ab sofort auf der Homepage verfügbar.
Die Installation über TAPtoDate ("MovieCutter 3.6", ggf. Reparatur-Installation) sollte ebenfalls gehen - bei mir hat es jedenfalls einwandfrei geklappt. Ansonsten gerne nochmal melden...

[Twilight]

twilight

[uenger]

Moin,
MovieCutter 3.6 hat geklappt, danke dafür.
RecStripper gibt allerdings noch immer die bekannte Fehlermeldung aus (es ist ein Downloadfeher aufgetreten).

LG
uenger

[chris86]

RecStripper gibt allerdings noch immer die bekannte Fehlermeldung aus (es ist ein Downloadfeher aufgetreten).

Ich kann nur raten, was da bei dir schief läuft...
Angenommen, ich habe richtig geraten - dann sollte es jetzt wieder funktionieren
Ansonsten müsstest du mir evtl. mal dein TAP2Date-Log zusenden...

[uenger]

Moin chris,
Du hast richtig geraten, jetzt hat es geklappt, vielen lieben Dank.
Was war es denn?

LG
uenger

[macfan]

Gruß, Horst

[chris86]

Du hast richtig geraten, jetzt hat es geklappt, vielen lieben Dank.
Was war es denn?

Meine Vermutung war, dass du ein veraltetes/beschädigtes ttd-Archiv auf deinem Topf hattest, welches auf ein falsches Installationspaket verweist.
Daher habe ich das ttd-Datum geändert, um ihn zu "zwingen", es neu herunterzuladen.

[HD_Topfgucker]

Hallo Chris,

Ich habe einige weitere Tests mit HD Streams durchgeführt.
Dabei habe ich auch vollständig entschlüsselte Pay TV Streams mit behandelt. Die original Dateien
lassen sich auf jedem Computer abspielen und sind noch nicht mit MC geschnitten.
Nach dem fehlerfreien Strippen werden aber bei Pay TV Streams NAV Dateien ohne Inhalt erzeugt.

Dabei ist mir folgendes beispielhaft aufgefallen:

ARD - korrektes erzeugen von rec, inf und nav
SAT1- korrektes erzeugen von rec und inf nav wird als leere Datei angelegt
RTL - korrektes erzeugen von rec und inf nav wird als leere Datei angelegt

Alle 3 Aufzeichnungen sind exakt 2 Minuten lang und lassen sich abspielen. Nur ARD lässt sich
bekanntermaßen spulen.
Nach Behandlung mit rebuildnav ergibt sich folgendes Szenario.
Dateien der Sat1 Pro7 Gruppe - Die nav Datei wird korrekt hergestellt.
Dateien der RTL Gruppe erhalten obwohl sie unverschlüsselt sind das gelbe $ Zeichen und die
Nav Datei wird nicht hergestellt. Das strippen ist somit sinnlos.

Allgemein sind die Streams der privaten Sender weniger aufgebläht (keine filler Nalu s)

Kann jemand diese Beobachtungen bestätigen ?

Wo kann man ansetzen um die Nav Dateien der RTL Gruppe zu erzeugen?

Grüße
HD_TOPFGUCKER

[chris86]

Interessante Beobachtung!
Ich selbst habe kein PayTV und konnte das daher nicht testen.
Zunächst wäre die Log-Ausgabe von RecStrip (unter ProgramFiles/Settings/RecStripper/RecStrip.log) ein wichtiger Ansatzpunkt.
Außerdem wäre es sehr hilfreich, wenn du mir entsprechende kurze Testaufnahmen zur Verfügung stellen könntest...
Achso, und sind die Aufnahmen über das offizielle CI+ Modul erzeugt worden oder über ein ein alternatives CI-Modul?

[Twilight]

kann das an der internen ci+ verschlüsselung liegen? auch wenn hd+ aufnahmen unverschlüsselt sind so sind sie, wenn mit legalen mitteln aufgenommen, intern verschlüsselt auf der platte.

twilight

[chris86]

Deshalb meine Frage nach dem "offiziellen" Modul. Legal ist das andere ja auch ;-)

[jkIT]

[quote="HD_Topfgucker"] Die original Dateien
lassen sich auf jedem Computer abspielen [/quote]
Das spricht gegen die Theorie mit der internen Verschlüsselung.

Auch das RebuildNav Log könnte einen Anhaltspunkt liefern.

[Twilight]

ok, 1:0 für jkit

twilight

[Alter Sack]

Das spricht gegen die Theorie mit der internen Verschlüsselung.

Wenn bei der Aufnahme kein CAM gesteckt ist ... und man sie nachträglich entschlüsselt ...

[HD_Topfgucker]

Hallo,

die Originalfiles wurden während der Aufnahme komplett mit einem CI Modul entschlüsselt.
Sie sind spulbar und auch auf verschiedenen Computern und Platformen abspielbar. Also
keine interne Verschlüsselung.

Anbei die logs von recstrip, recstripper und tapsystem. Ein separates rbn log habe ich nicht gefunden.

Liebe Grüsse

[HD_Topfgucker]

@ Chris

sende Dir gern die 3 Originalen Files in Summe ca 480 MB zur Prüfung. Aber Wie?

Gruß HD_Topfgucker

[chris86]

2 Probleme:

- Die "Betrugsfälle" (RTL) enthalten laut RbN-Log verschlüsselte Pakete - laut RecStrip jedoch nicht. Ist das dieselbe Aufnahme, oder wurde sie erst nach diesem RbN + Decrypt Vorgang in RecStrip gefüttert?

- Irgendwas scheint mit der PMT nicht zu stimmen, so dass keine VideoStream-Info gefunden wurde und RecStrip nicht entscheiden konnte, ob es eine SD- oder HD-Aufnahme vor sich hat. (Deshalb wurden übrigens auch keine Filler-NALUs detektiert).

Die Aufnahmen würde ich mir wirklich gerne ansehen!
Hast du die Möglichkeit, sie z.B. bei DropBox oder einem OneClick-Hoster (wie z.B. Rapidshare oder MEGA) hochzuladen?
Wenn nicht, schreib mir ne E-Mail, dann müssen wir sehen, ob wir irgendwo einen FTP-Server o.ä. auftreiben...