RebuildNAV & RecCopy TAP

[paul79]

Vermutung: durch einen Umbau in der FBLib wurden keine 64-Bit-Libs gelinkt und somit konnten keine Files > 2GB geöffnet werden.

Woher kenne ich das bzw ein ähnliches Problem nur..

[Philipswalther]

Alex Danke für die C Version
Hoffen wir mal das diese nun wieder so funktioniert wie immer alles bei Dir

[matradix]

Eine 1,8GB Datei hat nun mit der c funktioniert! Morgen stehen welche über 2GB an. Werde berichten.

Was ich allerdings nicht verstehe, ist dass mit dem Timer im Zusammenhang mit SE.
Habe in rbn den Zeitraum von 3:00 bis 7:30 gesetzt. Wenn ich nun in die Timerliste schaue, dann steht da SE scan Timer von 5:00 bis 5:03 und der Descrambletimer gleich ab 5:04. Ist das nicht zu wenig Zeit für den SE scan?
Wieso steht da der Descrambletimer nicht ab 3:00?

Dann habe ich den rbn Zeitraum mal von 2:30 bis 6:00 gesetz. Darauf landet der SE scan auf 5:59. Kann mir mal jemand die Logik dahinter erklären?

Am liebsten wäre es mir so:
Descramble Zeitraum von 3:00 bis 7:30
SE scan ab 5:00.
SE sollte sich immer hinter den Descramble einreihen und Descramble sollte auch auf 3:00 starten. Natürlich vorausgesetzt, dass da keine anderen Timer sind, was aber bei oben genannten Zuständen auch nicht der Fall war.

Wieso kann ich den Descramble Timer in SE Timeransicht nicht mit blauer Taste löschen?


Edit:
Hier noch das log.
Komisch dass der ein und selbe AD Timer über den Tag verteilt immer wieder hin und hergeschoben wird.

[FireBird]

Es bringt nichts, die Zeiträume überlappen zu lassen, da ein SE-Timer praktisch immer den AD-Zeitraum ab 5h belegt und RbN somit nie mehr als 2 Stunden vergeben kann. Da müsste RbN den ScanTimer löschen und das wird es nicht tun.

Re. blaue Taste: da es sich beim AD-Timer um einen besonderen Timer handelt, wird er in SE zwar angezeigt, man kann ihn aber nicht verändern.

[matradix]

oK ich verstehe. Danke.

Habe oben leider zu spät noch editiert. Kannst du dir das verückte log erklären?

[FireBird]

Da haben sich die beiden Timer bekriegt. War zum Zeitpunkt von RbN der SE-Timer nicht vorhanden, hat RbN seinen eigenen Timer an den Anfang des Blocks gesetzt. Hat der SE-Timer um 5h den Rbn-Block zerteilt, hat RbN den größeren verfügbaren Block, nämlich den nach dem SE-Timer, für das AutoDescrambling eingeteilt.

[matradix]

Aha, nun hab ich die Logik glaub kapiert! :

Somit sollte der Zeitraum von RnB wohl vor SE enden.
Leider krieg ich da aber schlecht 4 Stunden unter, wenn SE bei 5 Uhr bleiben soll und man Nachts noch ev. bis 3 Uhr fern schaut.
Hm, wie soll ich denn das hinbiegen?

[FireBird]

Hm, wie soll ich denn das hinbiegen?

Ab 2h auf schnelles Vorspulen schalten.

[matradix]

Das verkraftet mein Modul nicht.

[matradix]

Ne, ich leg SE auf 6 oder 7 Uhr. Da schaut bei uns eh keiner.

[chrisly]

Im TMSA-Thread wird zur Zeit diskutiert, dass Dateien nach Entschlüsselung nicht mehr nach Aufnahmedatum, sondern nach Dateidatum sortiert werden.

Maliboy hatte dazu folgende Idee:

Lieber wäre mir, wenn ein Tap (z.B. RebuildNav) das Dateidatum wieder auf der Datum der INF zurück setzen würde.

Wäre das evtl. umsetzbar?

[FireBird]

Die werden immer nach Dateidatum sortiert, so in den Optionen ausgewählt. Die Kopie wird halt den Zeitpunkt der Kopie als Zeitstempel erhalten. Ich weiß nur nicht auswendig, welcher in der inf steht. Ich nehme an, dass als Aufnahmestart bei der Kopie ebenfalls der Zeitpunkt der Kopie eingetragen sein wird. Bliebe höchsten, falls vorhanden, der Event und wenn der nicht stimmt, ist alles aus.

[camello]

Ab 2h auf schnelles Vorspulen schalten.

@ Firebird
Was meinst du damit. Gibt es da eine Kopierfunktion, die ich noch nicht kenne?

[FireBird]

Höchsten Festplatte Richtung Hirn.

[FilmFan]

Ich nehme an, dass als Aufnahmestart bei der Kopie ebenfalls der Zeitpunkt der Kopie eingetragen sein wird. Bliebe höchsten, falls vorhanden, der Event und wenn der nicht stimmt, ist alles aus.

Man könnte sich das Datum vorher "merken".

Darum mache ich auch immer vorher Automove (Datum/Uhrzeit in den Dateinamen übernehmen - SE kann das ja auch) und sichere zusätzlich die originale .inf-Datei. Dann kann man die alten Informationen wie Datum/Uhrzeit in die neue .inf-Datei und als Dateidatum übernehmen (wenn mein TFInfo mal so weit ist ). Das könnte natürlich auch ein TAP machen.

[sumo]

Die werden immer nach Dateidatum sortiert, so in den Optionen ausgewählt. Die Kopie wird halt den Zeitpunkt der Kopie als Zeitstempel erhalten. Ich weiß nur nicht auswendig, welcher in der inf steht. Ich nehme an, dass als Aufnahmestart bei der Kopie ebenfalls der Zeitpunkt der Kopie eingetragen sein wird. Bliebe höchsten, falls vorhanden, der Event und wenn der nicht stimmt, ist alles aus.

Mit "Info" wird in der originalen Topf Dateiliste und auch in TMSA das Sendedatum/Uhrzeit der Aufnahme angezeigt. Weiß aber nicht ob die Info aus der .inf oder dem Event kommt.

Wäre toll wenn RbN das Dateidatum einer Kopie zurückpatchen könnte

[mgaertner]

Dann hätte ich noch die V4.8c anzubieten.

Hab die Zwischenzeit mit der Privat-Version gearbeitet und jetzt direkt wieder auf die reguläre umgestellt

DANKE Alex!!!

[sumo]

[quote="FireBird"]Dann hätte ich noch die V4.8c anzubieten.[/quote]

Da bin ich noch eine Antwort schuldig. Die V4.8c läuft bisher wie geschmiert.

Vielen Dank, sumo

[ninfinity]

Gibt es noch die Funktion, dass man für jeden Wochentag einen eigenen AD-Timer-Bereich über AutoDescrambleTimeStart1..7 in der ini definieren kann? In der neuen Anleitung ist kein Hinweis mehr darauf. Wenn ja, kann man Timer-Blöcke bilden? Bsp., Mo-Fr ein Timer-Bereich: Einträge in der ini ohne Zahl. Sa und So davon abweichend, deshalb ini-Einträge mit 6 und 7 am Ende? Oder muss ich, wenn ich einen Eintrag mit Zahl habe, jeden Wochentag einzeln aufführen?

Gruß
ninfinity

[FireBird]

Das sollte weiterhin funktionieren. Die AutoDescrambleTime* gilt für alle Tage und dann kannst Du zusätzlich Ausnahmen für einzelne Tage definieren. Also zusätzliche Einträge für 6 und 7 genügen.