RebuildNAV & RecCopy TAP
Verfasst: Fr 13. Nov 2009, 16:30
Hi,
dieses TAP sucht nach Aufnahmen, die keine .rec.nav haben und versucht diese zu rekonstruieren. Wenn das klappt, kann man diese Aufnahme pausieren und in ihr herumspulen. Das TAP durchsucht von DataFiles beginnend rekursiv alle Unterverzeichnisse. Wenn man also mittels TMSMount eine externe Festplatte umleitet, wir auch sie „behandelt“.
Log gibt es als RebuildNAV.log und in der Telnet-Konsole. Nachdem das TAP alle Dateien abgearbeitet hat, beendet es sich wieder, oder schaltet den Topf ab. Mit „Exit“ kann man das Info-OSD ein- bzw. wieder ausblenden (die Taste läßt sich via RebuildNAV.ini umkonfigurieren). Ist das OSD sichtbar, kommt man mittels „Menu“ in ein Minimalmenü, über das man die automatische Abschaltung konfigurieren, oder den Scan-Vorgang abbrechen kann.
Vor dem Abschalten wird noch ein 10-Sekunden-Countdown angezeigt, damit man die Abschaltung noch abbrechen kann. Die Aufnahme muß vollständig entschlüsselt sein. Das ist aber keine Einschränkung des TAPs, sondern Voraussetzung für die Analyse der Frames.
MfG. Alex
-----------------------------------------------
Edit 2011-03-27: Nachdem sich mittlerweile viel getan hat, folgend eine kleine FAQ, die die Funktionsweise des TAPs beschreibt.
FAQ
* Warum RebuildNAV und RecCopy in einem TAP?
Grundsätzlich haben die beiden Funktionen nichts miteinander zu tun. Es gibt aber eine Gemeinsamkeit, nämlich das Überprüfen der Gigabyte-großen Aufnahmen. Damit nicht zwei TAPs die selbe zeitaufwändige Aufgabe durchführen, habe ich beschlossen, die beiden Funktionen in einem TAP zu vereinen.
* Was macht RebuildNAV und was macht RecCopy?
RebuildNAV kümmert sich um die Erzeugung einer .nav-Datei. Diese ist für das flüssige Spulen notwendig. RecCopy wiederum überprüft, ob eine Aufnahme verschlüsselte Pakete enthält. Ist dies der Fall, verschiebt das TAP die Aufnahme in den AutoDescramble Ordner und setzt den AutoDescramble-Timer der Firmware.
* Wann scannt RebuildNAV?
Immer dann, wenn keine .nav-Datei existiert oder diese 0 Bytes groß ist.
* Wann scannt RecCopy?
RecCopy merkt sich die letzte komplett gescannte Datei (RebuildNAV.ini-Eintrag „LastScanTime“
und ignoriert alle älteren Dateien. Damit wird sichergestellt, dass eine Datei von RecCopy nur ein Mal gescannt wird.
* Wann scannt RebuildNAV/RecCopy nicht?
Während des AD-Zeitraumes (Standardwert ist zwischen 01:00 und 05:00). In diesem Fall werden nur ein paar Logeinträge geschrieben und das TAP beendet sich wieder. Dies soll verhindern, dass sich RbN und die Entschlüsselung in die Quere kommen.
* Warum wird eine Datei gescannt, obwohl sie als unverschlüsselt markiert ist?
Das Symbol stimmt leider nicht immer und die einzige Methode dies festzustellen, ist der Scan der ganzen Datei.
* Wann entschlüsselt RecCopy?
Nie! RecCopy macht nur die Vorbereitung (Verschieben der Aufnahme in den AutoDescramble-Ordner, setzen eines AD-Timers), die automatische Entschlüsselung wird aber durch die Firmware selbst erledigt. Deshalb beendet sich RbN auch in diesem Zeitraum (siehe obige Frage).
* Wo sehe ich den Entschlüsselungstimer?
Nur in der Topfield-Timerliste. Da es sich um einen Spezialtimer handelt, wird er von den TAPs nicht in deren Listen angezeigt.
* Es lagen mehrere Aufnahmen im AD-Verzeichnis, aber es wurden nicht alle entschlüsselt.
Wenn Timer innerhalb des AD-Zeitraums anliegen, wird nur der größte zusammenhänge Block für die Entschlüsselung genommen und dies kann zu kurz für alle Aufnahmen sein. Aus diesem Grund dürfen auch keine EPG-Scan-Timer in diesem Zeitraum liegen. Für eine genaue Analyse sind 2 Logs notwendig: das RebuildNAV.log für das Setup des AD-Timers und das TimerDiags.log für die Entschlüsselung selbst.
* Es wurde zwar entschlüsselt, das Original liegt aber immer noch AD-Ordner?
Dies liegt an einem Firmware-Bug, die Umstände des Auftretens konnten jedoch noch nicht festgemacht werden. Damit der TMS aber nicht in einer Endlosschleife die selbe Aufnahme wieder und wieder entschlüsselt, wurde die AutoDescramble-Fail-Check-Funktion in RebuildNAV eingebaut. Diese prüft, ob es zu einem Original eine entschlüsselte Kopie gibt und ob diese maximal 1 Minute kürzer ist, als das Original. In diesem Fall wird das Original von RbN gelöscht. Gibt es bereits 3 Kopien, die alle zu kurz sind, verschiebt RbN Original und Kopien in den Ordner „AutoDescramble_Failed“.
* Wie lange soll ich den AD-Zeitraum einstellen?
Das kommt darauf an.
Werden verschlüsselte Aufnahmen nur von Sendern gemacht, die den Schlüssel sehr selten ändern (z.B. ORF), dann kann man den Zeitraum kürzer machen, da eine erst am darauffolgenden Tag entschlüsselte Datei kein Problem bereitet. Sender, die die „Haltbarkeit“ einer Aufnahme kurz halten, erzwingen einen großzügigen AD-Zeitraum, da sich die Datei am nächsten Tag vielleicht nicht mehr entschlüsseln lässt und somit verloren ist.
* Kann RecCopy nicht schneller entschlüsseln, als mit einfacher Geschwindigkeit?
RecCopy entschlüsselt nicht und die Firmware kann es nicht schneller.
* Was bedeuten das DEC im Namen bzw. das C-Symbol in der Dateiliste?
Dass es sich um eine Kopie handelt. RbN kann so eingestellt werden, dass das C-Symbol beim ersten RbN-Lauf nach der Entschlüsselung entfernt wird.
*Bei manchen Kopien sehe ich ein gelb/blaues $, welches später plötzlich Blau ist.
Das ist möglich. Grundsätzlich erhält eine Kopie das weiße C-Icon, welches das $-Icon überdeckt. Hat man RebuildNAV so eingestellt, dass das TAP das C entfernt, erscheint danach das von der Firmware vergebene $-Zeichen. Dies passiert kurz nach dem Start von RbN. Sobald die Kopie fertig gescannt wurde, passt RbN das Icon an. In dem Zeitraum zwischen dem Start des TAP und dem Abschließen einer Datei kann es also vorkommen, dass z.B. ein gelb/blaues $-Icon zu sehen ist, welches später wie durch Geisterhand auf Blau wechselt.
* Das TAP funktioniert nicht!
Ohne RebuildNAV.log können wir nur raten, mit dem Log ist die Lösung meist sehr schnell gefunden.
dieses TAP sucht nach Aufnahmen, die keine .rec.nav haben und versucht diese zu rekonstruieren. Wenn das klappt, kann man diese Aufnahme pausieren und in ihr herumspulen. Das TAP durchsucht von DataFiles beginnend rekursiv alle Unterverzeichnisse. Wenn man also mittels TMSMount eine externe Festplatte umleitet, wir auch sie „behandelt“.
Log gibt es als RebuildNAV.log und in der Telnet-Konsole. Nachdem das TAP alle Dateien abgearbeitet hat, beendet es sich wieder, oder schaltet den Topf ab. Mit „Exit“ kann man das Info-OSD ein- bzw. wieder ausblenden (die Taste läßt sich via RebuildNAV.ini umkonfigurieren). Ist das OSD sichtbar, kommt man mittels „Menu“ in ein Minimalmenü, über das man die automatische Abschaltung konfigurieren, oder den Scan-Vorgang abbrechen kann.
Vor dem Abschalten wird noch ein 10-Sekunden-Countdown angezeigt, damit man die Abschaltung noch abbrechen kann. Die Aufnahme muß vollständig entschlüsselt sein. Das ist aber keine Einschränkung des TAPs, sondern Voraussetzung für die Analyse der Frames.
MfG. Alex
-----------------------------------------------
Edit 2011-03-27: Nachdem sich mittlerweile viel getan hat, folgend eine kleine FAQ, die die Funktionsweise des TAPs beschreibt.
FAQ
* Warum RebuildNAV und RecCopy in einem TAP?
Grundsätzlich haben die beiden Funktionen nichts miteinander zu tun. Es gibt aber eine Gemeinsamkeit, nämlich das Überprüfen der Gigabyte-großen Aufnahmen. Damit nicht zwei TAPs die selbe zeitaufwändige Aufgabe durchführen, habe ich beschlossen, die beiden Funktionen in einem TAP zu vereinen.
* Was macht RebuildNAV und was macht RecCopy?
RebuildNAV kümmert sich um die Erzeugung einer .nav-Datei. Diese ist für das flüssige Spulen notwendig. RecCopy wiederum überprüft, ob eine Aufnahme verschlüsselte Pakete enthält. Ist dies der Fall, verschiebt das TAP die Aufnahme in den AutoDescramble Ordner und setzt den AutoDescramble-Timer der Firmware.
* Wann scannt RebuildNAV?
Immer dann, wenn keine .nav-Datei existiert oder diese 0 Bytes groß ist.
* Wann scannt RecCopy?
RecCopy merkt sich die letzte komplett gescannte Datei (RebuildNAV.ini-Eintrag „LastScanTime“
und ignoriert alle älteren Dateien. Damit wird sichergestellt, dass eine Datei von RecCopy nur ein Mal gescannt wird.* Wann scannt RebuildNAV/RecCopy nicht?
Während des AD-Zeitraumes (Standardwert ist zwischen 01:00 und 05:00). In diesem Fall werden nur ein paar Logeinträge geschrieben und das TAP beendet sich wieder. Dies soll verhindern, dass sich RbN und die Entschlüsselung in die Quere kommen.
* Warum wird eine Datei gescannt, obwohl sie als unverschlüsselt markiert ist?
Das Symbol stimmt leider nicht immer und die einzige Methode dies festzustellen, ist der Scan der ganzen Datei.
* Wann entschlüsselt RecCopy?
Nie! RecCopy macht nur die Vorbereitung (Verschieben der Aufnahme in den AutoDescramble-Ordner, setzen eines AD-Timers), die automatische Entschlüsselung wird aber durch die Firmware selbst erledigt. Deshalb beendet sich RbN auch in diesem Zeitraum (siehe obige Frage).
* Wo sehe ich den Entschlüsselungstimer?
Nur in der Topfield-Timerliste. Da es sich um einen Spezialtimer handelt, wird er von den TAPs nicht in deren Listen angezeigt.
* Es lagen mehrere Aufnahmen im AD-Verzeichnis, aber es wurden nicht alle entschlüsselt.
Wenn Timer innerhalb des AD-Zeitraums anliegen, wird nur der größte zusammenhänge Block für die Entschlüsselung genommen und dies kann zu kurz für alle Aufnahmen sein. Aus diesem Grund dürfen auch keine EPG-Scan-Timer in diesem Zeitraum liegen. Für eine genaue Analyse sind 2 Logs notwendig: das RebuildNAV.log für das Setup des AD-Timers und das TimerDiags.log für die Entschlüsselung selbst.
* Es wurde zwar entschlüsselt, das Original liegt aber immer noch AD-Ordner?
Dies liegt an einem Firmware-Bug, die Umstände des Auftretens konnten jedoch noch nicht festgemacht werden. Damit der TMS aber nicht in einer Endlosschleife die selbe Aufnahme wieder und wieder entschlüsselt, wurde die AutoDescramble-Fail-Check-Funktion in RebuildNAV eingebaut. Diese prüft, ob es zu einem Original eine entschlüsselte Kopie gibt und ob diese maximal 1 Minute kürzer ist, als das Original. In diesem Fall wird das Original von RbN gelöscht. Gibt es bereits 3 Kopien, die alle zu kurz sind, verschiebt RbN Original und Kopien in den Ordner „AutoDescramble_Failed“.
* Wie lange soll ich den AD-Zeitraum einstellen?
Das kommt darauf an.
Werden verschlüsselte Aufnahmen nur von Sendern gemacht, die den Schlüssel sehr selten ändern (z.B. ORF), dann kann man den Zeitraum kürzer machen, da eine erst am darauffolgenden Tag entschlüsselte Datei kein Problem bereitet. Sender, die die „Haltbarkeit“ einer Aufnahme kurz halten, erzwingen einen großzügigen AD-Zeitraum, da sich die Datei am nächsten Tag vielleicht nicht mehr entschlüsseln lässt und somit verloren ist.* Kann RecCopy nicht schneller entschlüsseln, als mit einfacher Geschwindigkeit?
RecCopy entschlüsselt nicht und die Firmware kann es nicht schneller.
* Was bedeuten das DEC im Namen bzw. das C-Symbol in der Dateiliste?
Dass es sich um eine Kopie handelt. RbN kann so eingestellt werden, dass das C-Symbol beim ersten RbN-Lauf nach der Entschlüsselung entfernt wird.
*Bei manchen Kopien sehe ich ein gelb/blaues $, welches später plötzlich Blau ist.
Das ist möglich. Grundsätzlich erhält eine Kopie das weiße C-Icon, welches das $-Icon überdeckt. Hat man RebuildNAV so eingestellt, dass das TAP das C entfernt, erscheint danach das von der Firmware vergebene $-Zeichen. Dies passiert kurz nach dem Start von RbN. Sobald die Kopie fertig gescannt wurde, passt RbN das Icon an. In dem Zeitraum zwischen dem Start des TAP und dem Abschließen einer Datei kann es also vorkommen, dass z.B. ein gelb/blaues $-Icon zu sehen ist, welches später wie durch Geisterhand auf Blau wechselt.
* Das TAP funktioniert nicht!
Ohne RebuildNAV.log können wir nur raten, mit dem Log ist die Lösung meist sehr schnell gefunden.
und Danke!
Ich bin wahrscheinlich wieder darauf hereingefallen, daß Ihr noch mit einer – ähh 