RebuildNAV & RecCopy TAP

[Gerti]

Hi!

Ist längst drauf...
Wie gesagt, tritt es aber nicht immer, sondern nur manchmal auf...

Gruß,
Gerti

[Paulchen Panther]

Kann es sein, dass das passiert, wenn es bereits eine entschlüsselte Aufnahme gleichen Namens gibt aber eben eine andere Folge?
Ich habe das Gefühl dass das bei mir so ist.

[TV-Junkie]

Danke, gleichfalls.



Und jetzt zu Ha-Jü: die besagte Aufnahme wurde am 19.12 in den AD-Folder verschoben und am 20.12 um 01:00 entschlüsselt. Laut Logs spricht nichts dagegen, daß die Entschlüsselung erfolgreich erledigt wurde. Warum die Aufnahme nicht gelöscht wurde, kann ich nicht sagen und es sieht eher nach einem Firmware-Bug aus. Kannst Du nur bitte prüfen, ob der AD-Timer auch auf „Original=Löschen“ steht.

Hast Du eine Erklärung, weswegen der AD-Timer heute Nacht nicht angesprungen ist?

Nö, müsste ich mal nachschauen, ob sonst noch was war, was Timer Diags ggf nicht gelistet hat.
ansonsten keine Ahnung.
@Gerti: Beim AD Timer von Hand anlegen hatte ich noch nie Probleme, das die Aufnahme danach nicht gelöscht war.
Liegt ggf auch daran, das ich nicht soviel bei Sky aufnehme.
@ Alex, siehst du ein problem darin, bei erfolgreicher Decodierung das File im AD Ordner via Tap zu löschen

[FireBird]

siehst du ein problem darin, bei erfolgreicher Decodierung das File im AD Ordner via Tap zu löschen

Wer sagt mir, dass es erfolgreich war?

[TV-Junkie]

Eine gute Frage
Die entschlüsselte Datei

[Ricki]

Wer sagt mir, dass es erfolgreich war?

Dein Log File , und die Rückmeldung der User? Wenn es nicht erfolgreich war was macht RbN damit?

[FireBird]

Dein Log File , und die Rückmeldung der User? Wenn es nicht erfolgreich war was macht RbN damit?

RbN macht nach dem Abwurf ins AD-Verzeichnis gar nichts mehr. Es wird die (DEC)-Datei nochmals gescannt, da sie neuer ist, als der LastScanTime-Eintrag in der INI. Aber mir ist lieber, Topfield fixt den Bug, als daß ich den überdrüber-Algorithmus erfinde, um eine möglicherweise hängengebliebene Datei zu löschen.

[Ricki]

R Aber mir ist lieber, Topfield fixt den Bug, als daß ich den überdrüber-Algorithmus erfinde, um eine möglicherweise hängengebliebene Datei zu löschen.

hast recht. Bugfix sollte vor gehen. Hoffen wir mal das es auch kommt .

[FireBird]

RebuildNAV & RecCopy V2.3 ist online. Einzige Änderung: Kompatibilität mit dem australischen TRF-2400.

[BluField62]

Danke

...aber die alte Version hieß auch schon 2.3?!

Ich muss aber nur das NAV TAP ersetzen oder?

[Ricki]

Firebird, warst sehr fleißig. Note 1+

[deangelj]

RebuildNAV & RecCopy V2.3 ist online. Einzige Änderung: Kompatibilität mit dem australischen TRF-2400.

Thank you from your southern cousins

[FireBird]

Hi John,

maybe Filer is also interesting for you?

Regards, Alex

[Gerti]

Hi!

@FireBird: Könnte man den RecCopy Teil nicht nocht beschleunigen?
Ich habe den Eindruck, dass verschlüsselte Dateien komplett gescannt werden, bevor diese verschoben werden. Es würde doch reichen, soviel zu scannen, bis die Bedingung "zu viel verschlüsselt" erfüllt ist und dann schon die Datei zu verschieben.

Gruß,
Gerti

[FireBird]

Schau Dir die Rebuild()-Funktion, case-Block RS_ProcessBuffer, an. Sobald eine CryptLimitViolation erkannt wird, wird verschoben.

[Gerti]

Hi!

Mmmh, bei mir wurde eine Datei recht lange gescannt, obwohl diese imho vollverschlüsselt war...

Gruß,
Gerti

[FireBird]

Dann lass mal das CryptPacketCheck darüberlaufen. Die fragliche Aufnahme muss sich im AutoDescramble-Verzeichnis befinden.

[Twilight]

Mmmh, bei mir wurde eine Datei recht lange gescannt, obwohl diese imho vollverschlüsselt war...

zumindest ist das das was der tms meint

twilight

[mn2000]

[quote="FireBird"]@Blu: ich habe das TAP neu kompiliert. Kannst Du es bitte testen?[/quote]

Hi Firebird,

habe mit der neuen Version und der 5000 FB das gleiche Probs, lässt sich nichts steuern.

Hast Du für mich auch mal das neu kompilierte Tap?

Gruss mn2000

[BluField62]

Nimm das aus Post #1!
Edit: musst natürlich dein altes Zeug löschen