RecCopy

[Steffenlight]

@ibbi

habe jetzt eine Weile mal aufmerksam das Geschehen verfolgt und das Protokoll beäugt :-)

Außer zwei Dateien mit failed to decode at ..% hatte ich noch kein failed to stabilize.

Wie würde der Log mit dem skip-Eintrag aussehen das ich ihn dan auch sehe

[ibbi]

[quote=""dvdbommel""]kann mir mal jemand sagen wie das Problem gelöst wurde !!![/quote]

Durch Korrektur eines Sektors der Verzeichnisstruktur direkt auf der Platte (auf eigene Gefahr und ohne irgendeine Gewähr).

Ob dies bei Dir aber möglich ist bzw. ob dies überhaupt der Grund ist, muss vorher durch ein Scan-TAP festgestellt werden, welches Deine gesamte Verzeichnisstruktur in eine Datei schreibt, damit ich da nachsehen kann.

Wenn Du damit leben kannst, dass ich den Inhalt Deiner Festplatte kenne, PN.

[ibbi]

[quote=""Steffenlight""]Außer zwei Dateien mit failed to decode at ..% hatte ich noch kein failed to stabilize.

Wie würde der Log mit dem skip-Eintrag aussehen das ich ihn dan auch sehe [/quote]

So, wie ich es geschrieben habe:

[quote=""ibbi""]Meldung "Retrying to stabilize"[/quote]

[Steffenlight]

Sorry ops: doch zuviel Input am Wochenende :d rinking:

[Happy]

Hallo,
vielleicht könnten sich die Automoveanwender bzw. ibbi mal kurz das hier anschauen.

Gruß,
Happy

[ibbi]

[quote=""Steffenlight""]habe jetzt eine Weile mal aufmerksam das Geschehen verfolgt und das Protokoll beäugt :-)

Außer zwei Dateien mit failed to decode at ..% hatte ich noch kein failed to stabilize.[/quote]

Rein statistisch gesehen ...

[quote=""Steffenlight""]Habe das Problem, dass sich manchmal (bei täglichen Aufnahmen ca. jede 5te.) mehrere entschlüsselte Dateien von REC Copy auf der Platte habe die nur ein schwarzes Bild enthalten.[/quote]

... müsste es schon reichlich Resultate geben.

[Steffenlight]

[quote=""ibbi""]Rein statistisch gesehen ...



... müsste es schon reichlich Resultate geben. [/quote]

Seh ich auch so aber es ist wie es ist: Hält man die Kanone drauf bleiben Sie meistens ruhig.
Mal sehen was heut so drin steht

[ramses69]

Hi

Leider trat wieder folgendes Problem auf, daß der Topf behauptet, es ist gerade eine Aufnahme aktiv und RecCopy beendet sich. Heute morgen ca 9:00 war die Abfrage am Schirm "Aufnahme aktiv trotzdem abschalten JA NEIN" oder so ähnlich. Ich wählte NEIN, und als aktive Aufnahme wurde Film1(COPY) angezeigt.

Ich weis, das ist bis jetzt kein RecCopy Problem, ABER Film1.rec ist in das Orginale Verzeichnis verschoben worden

Könnte man in dem Fall wenn gerade eine Aufnahme läuft prüfen ob es sich um die COPY Aufnahme handelt, und wenn ja, die Aufnahme beenden und das ganze noch einmal versuchen.

Wenn ich schon beim Wünschen bin , würde ich mir noch eine Art Info beim Start wünschen wenn ein Problem aufgetreten ist (wie beim FpLogger).


Auszug aus dem Log File:

Code: Alles auswählen

31.07.2007
02:04:35  Version 4.1b8
02:04:35  Start reason is 'Boot'
02:04:35  Loading options
02:04:35  Processing RecCopy timer
02:04:35  Activity after completion will be 'Shutdown'
02:04:37  Added "Film1" to list
02:04:37  Added "Film2" to list
02:04:37  Working in /DataFiles
02:04:39  Scanning "Film1"
02:04:39  Scanning "Film2"
02:05:39  Originals will be kept
02:05:39  Decoding "Film1"
02:05:42  Waiting for playback stabilization
02:05:48  Stabilization reached
02:05:48  Speeding up
02:05:51  Decoding finished
[color=Red]02:05:52  A recording is currently in progress
[/color]02:06:00  Saving options
02:06:00  Reschedule possible at 02:21
02:06:00  Reschedule timer set
02:06:00  Saving options
02:06:00  Job completed
02:07:30  Exiting - good bye

Gruß Ramses

[Harvey]

Das "Decoding finished" einze Zeile über der roten finde ich etwas merkwürdig (Film1 wird ja wohl länger als ein paar Sekunden gewesen sein).

[ibbi]

[quote=""ramses69""]Könnte man in dem Fall wenn gerade eine Aufnahme läuft prüfen ob es sich um die COPY Aufnahme handelt, und wenn ja, die Aufnahme beenden und das ganze noch einmal versuchen.[/quote]

Bis dann da wieder ein Fehler auftaucht, weil der Topf behauptet, die Aufnahme sei jetzt beendet und sie läuft doch noch?

Irgendwann macht es programmtechnisch keinen Sinn mehr, da muss einfach ein Mensch eingreifen.

[quote=""ramses69""]Wenn ich schon beim Wünschen bin , würde ich mir noch eine Art Info beim Start wünschen wenn ein Problem aufgetreten ist (wie beim FpLogger).[/quote]

Einfach schauen, ob es eine RecCopy -Fehler- gibt.

[ramses69]

[quote=""ibbi""]
Einfach schauen, ob es eine RecCopy -Fehler- gibt.[/quote]

Aber in diesem Fall wurde die Datei ins -Orginale- verschoben und es gab keine COPY

Gruß Ramses

[ibbi]

[quote=""ramses69""]Aber in diesem Fall wurde die Datei ins -Orginale- verschoben und es gab keine COPY [/quote]

Weil der Topf gesagt hat, es ist alles ok und fertig.

Woher soll ich wissen, dass er lügt?

[Steffenlight]

Mögen die TAPs mit dir sein

[MiK]

Ich habe in den letzten Tagen ein sehr seltsames Verhalten von RecCopy beobachtet.

Ausgangslage:
- Eine verschlüsselte Aufnahme von 4:48 Länge
- RecCopy Timer auf 4:00 Uhr Nachholtimer bis 9:00 Uhr Dazwischen eine Stunde JAG, so dass sich zweimal 2 h für RecCopy ergeben.

Eigentlich müsste das bei 4x locker ausreichen um die Datei zu entschlüsseln. Aber im Protokoll steht immer wieder, dass die Aufnahme geskipped wurde, weil nicht genug Zeit ist.

Ich dachte das liegt evtl. an irgendwelchen Sicherheitsmargen und wollte die Datei heute früh manuell entschlüsseln. Wenn ich das aus dem RecCopy-menü versuche, bekomme ich die Meldung, dass entweder Timer im Weg sind oder nicht genug Plattenplatz. Beides ist definitiv nicht der Fall.

Wenn ich dann RecCopy aus dem Filer aufrufen möchte, beendet sich Filer und lässt sich auch nicht mehr starten. Und entschlüsselt wird natürlich auch nichts.

Am Ende habe ich dann die Entschlüsselung von Hand angschmissen, mit dem Nachteil, dass der Topf jetzt bis heute abend durchläuft.

Ich benutze von RecCopy und Filer jeweils die neueste Beta. Kann jemand erkären, was da passiert? Mit welchem Faktor wird bei 4x Entschlüsselung gerechnet?

PS.: Protokoll konnte ich heute morgen auf die Schnelle nicht mitnehmen. Das gibts dann frühestens morgen.

[Elle4u]

[quote=""MiK""]Wenn ich dann RecCopy aus dem Filer aufrufen möchte, beendet sich Filer und lässt sich auch nicht mehr starten. Und entschlüsselt wird natürlich auch nichts.[/quote]

Filer lässt sich so lange nicht mehr öffnen, bis RecCopy meldet, dass er nicht mehr zu Gange ist.

[ibbi]

[quote=""MiK""]Mit welchem Faktor wird bei 4x Entschlüsselung gerechnet?[/quote]

2,4-fach. Tests haben ergeben, dass die Geschwindigkeit bis etwa dahin einbrechen kann.

[MiK]

[quote=""Elle4u""]Filer lässt sich so lange nicht mehr öffnen, bis RecCopy meldet, dass er nicht mehr zu Gange ist.[/quote]
Dann ist das von Filer-Seite geklärt.

[quote=""ibbi""]2,4-fach. Tests haben ergeben, dass die Geschwindigkeit bis etwa dahin einbrechen kann.[/quote]
Das erklärt, warum es nicht in die 2 Stunden gepasst hat. Aber warum verweigerte RecCopy auch beim manuellen Starten in der RecCopy-GUI mit dieser Fehlermeldung den Dienst?

Außerdem gibt es in diesem Fehlerfall anscheinend auch keine korrekte Rückmeldung an Filer, wenn es von dort gestartet wurde. (s.o.)

[ibbi]

[quote=""MiK""]Aber warum verweigerte RecCopy auch beim manuellen Starten in der RecCopy-GUI mit dieser Fehlermeldung den Dienst?[/quote]

Weil da genau dasselbe abläuft wie bei der timerbasierten Entschlüsselung oder bei TAPCOM.

Das erste asimovsche Gesetz von RecCopy lautet: RecCopy darf keine Aufnahme zerstören oder durch Untätigkeit gestatten, dass einer Aufnahme Schaden zugefügt wird.

[MiK]

Aber es steht ja keine Aufnahme an. Nur das Ende des Zeitraums für den Nachholtimer war zu nahe. Und selbst das habe ich dann ein paar Stunden nach hinten gestellt und es ging trotzdem nicht. Wie es nach dem Ende des Nachholtimerzeitraums aussieht habe ich noch nicht getestet.

Klar soll auch beim manuellen Entschlüsseln auf Timer geachtet werden. Aber irgendwelche Nachholtimer-Einstellungen sollten doch keine Rolle spielen.

[ibbi]

[quote=""MiK""]Aber es steht ja keine Aufnahme an.[/quote]

Du sagtest doch, es gäbe zweimal 2 Stunden im erlaubten Nachholfenster. Zu dem Faktor 2,4 kommen noch 5 Minuten Sicherheitszuschlag, so dass wir auf insgesamt 125 Minuten voraussichtliche Entschlüsslungszeit kommen. Reicht nicht.