Vorschläge zur Verbesserung der Decodiersoftware

[Franz]

Immer wieder passiert es wie erst kürzlich dass ich 2 Filme hintereinander decodiere („der letzte Walzer“ + „der 1. Ritter“) und das Decodierprogramm meldet mir „decoding korrekt“ und als ich mir die Filmdateigröße anschaue hat sie 256 Byte, d.h Filme sind Schrott!!. Meine Herrn Programmierer dass muß doch wirklich nicht sein!! Wenn das Decodierprogramm prüfen kann ob genügend Speicherplatz auf dem Rechner ist, dann könnte es auch noch einige andere Punkte prüfen und ein Grossteil der Decodierprobleme würde sich in Luft auflösen und man müsste auch nicht immer die Admins bitten die Dateien erneut freizugeben (was ich hiermit tue)!!

Meine Vorschläge:
1. Decodiersoftware überprüft vor dem decodieren ob die Quelldatei wirklich die richtige Größe hat und decodiert nur dann.
2. Sinnvollerweise sollte man auch noch eine checksum etc einführen um sonstige Fehler zu minimieren.
3. Nach dem decodieren wird die Wiederholsperre nur dann aktiviert wenn die Datei die richtige Größe hat und vielleicht noch durch eine checksum etc sonstige Fehler minimiert werden.
4. Schaffung eines emailverteilers mit dem wichtige Neuerungen (z.B. neuer Decodierer etc) publik gemacht werden.


Wer hat sonst noch Ideen zur Verbessserung?

Übrigens, der FDLM zeigt bei mir ca. 11-12 MB weniger an als die org. OTR-Angabe.

[Koko]

Für einen Reset musst Du in der Shoutbox oder dem Support-Center um einen Reset bitten. Aber bitte nur eines von beiden.

Das geht hier im Forum nicht.

Die meisten Deiner Anregungen sind für die nächste Decoder Generation geplant.

[Franz]

Koko, wann kommt die nächste Generation vorraussichtlich raus?

[Mr. S]

1. Decodiersoftware überprüft vor dem decodieren ob die Quelldatei wirklich die richtige Größe hat und decodiert nur dann.

Geht nicht, ich krieg vom OTR-Server nicht die Dateigröße

2. Sinnvollerweise sollte man auch noch eine checksum etc einführen um sonstige Fehler zu minimieren.

Das wird ungefähr einmal pro Woche vorgeschlagen und das schon seit Beginn von OTR. Na, was ist bisher daraus geworden? Angeblich soll es aber mit der neuen Generation Decoder besser werden.

3. Nach dem decodieren wird die Wiederholsperre nur dann aktiviert wenn die Datei die richtige Größe hat und vielleicht noch durch eine checksum etc sonstige Fehler minimiert werden.

Nicht machbar, das läßt sich zu leicht manipulieren!

4. Schaffung eines emailverteilers mit dem wichtige Neuerungen (z.B. neuer Decodierer etc) publik gemacht werden.

Für meinen Decoder gibt einen RSS-Feed.

Übrigens, der FDLM zeigt bei mir ca. 11-12 MB weniger an als die org. OTR-Angabe.

Die Angaben von OTR sind nicht immer korrekt, daher ist auch der Größencheck sinnlos.

[sandramain]

@Mr. S : Es gibt doch diese Site, wo man sich fileinfos angucken kann. Vielleicht könnte ja der Betreiber ein php-dokument schreiben, dass nur die Dateigröße zurück gibt ....

[george]

Übrigens, der FDLM zeigt bei mir ca. 11-12 MB weniger an als die org. OTR-Angabe.

rechnest du, falls nötig, das ganze auch richtig um? (z.bsp. von KB auf MB die KBs durch 1024 teilen)

[Franz]

@ george:
gut erkannt, hier liegt die Abweichung.

[TheMasterchief]

Wie wäre es wenn man einfach an jede .ortkey Datei immer die gleiche GUID anhängen würde.
Das wäre eigentlich programmtechnisch sehr einfach zu realisieren.
Und man hätte sehr geringe Wahrscheinlichkeit, dass zufällig das abgeschnittene Dateiende die gleiche Endung hat.
Der Decoder müsste nur testen ob die Datei mit der richtigen 128 Bit Zahl endet und fertig und es ist kein online abgleichen der Dateigröße oder ähnliches nötig.
Gegebenen Falls könnte man auch noch 32 mal 0x42 oder so was Ähnliches anhängen da die verschlüsselten Bytes der .otrkey Dateien eigentlich recht gleichverteilt aussehen sollte es sehr unwahrscheinlich sein das so was zufällig auftritt.

Ich hoffe auf diese Weise könnte es auf einfach Art unterbunden werden, das man nicht vollständige Dateien dekodiert was mich auch schon des öfteren gewurmt hat.

[george]

das einfachste, und das ist wohl grad in planung, ist dass wenn der decoder sich den dekodierungs-key holt, er bytheway auch gleich den hash-wert für die datei bekommt. kurz gecheckt - nie wieder stress mit beschädigte dateien.



edit: ok - ist in dem thread auch schon mehrmals erwähnt worden...

[Pody]

Hallo alle miteinander,

sicher ist es gut und sinvoll einen Arbeitstechnisch sicheren Decodierablauf zu erreichen und wenn der auch noch fehler erkennen kann ist das noch schöner,
aber hat sich mal jemand Gedanken um die Auswirkungen bzw. den Ablauf solcher Decodierungen gemacht?

Aufgrund der langen Laufzeit beim Umwandeln habe mal mit kleineren Tools den Ablauf beobachtet und da stellen sich mir einige fragen:

1. Warum muß wärend des Decodierens ständig mit dem Server kontackt gehalten werden? Eine kurze Bestätigung das man zum Decodieren berechtigt ist (Durch übergabe des Key´s) und der Rest könnte ohne Onlineverbindug laufen. Denn wenn jemand seinen Decode-Vorgang versemmelt hilft auch die Verbindung nix.

2. Die Prozesspriorität ist recht gering, ca 10%, wenn ich das richtig behalten habe. Wenn ich einen Film decodiere und ich aus vorsicht nicht noch andere Sachen (Ausser online News oder so) mache, dann könnte das Programm ruhig mehr von der vorhandenen Leistung des Rechners nehmen.

3. Es ist ratsam die Dateien zu verteilen (von c:**. OTRKEY nach D: entpacken), oder wenn genug Ram da ist in den Speicher zu entpacken!
Denn wenn meine Beobachtung mit dem Filemon von Sysinternals (Weil es gut ist von MS aufgekauft) http://www.microsoft.com/technet/sys...s/default.mspx
richtig sind dann produziert ein entpacken einer Filmdatei Pro Sekunde 3222 Zugriffe auf die Festplatte !!! Das ist STRESS für die Platte und auch sicher ein Grund für die Ausführungsgeschwindigkeit. Denn eine lahme Platte oder ein betagtes Rechnersystem hat da schon richtig zu kämpfen.

Also wenn man bei einer neueren Version auf solche begleitumstände rücksicht nehmen würde, hat man schon viel gewonen.
Wenn man zb. eine Filmdatei beim Decodieren in Speicherfreundiche Blöcke teilt und diese im Ram dekodiert...Ich könnte mir vorstellen das das was bring.
Und schonender für die Platte wäre das allemal.

Es ist nicht auszuschließen das ich in manchen sachen unrecht habe oder das ich das falsch deute, aber so stellt es sich mir im moment dar.
Sorry das es so lang geworden ist.

Achja, ich benutze dem OMR Decoder 1.0.0.8

By, Pody

Wer Rechtschreibfehler findet, darf sie behalten !!