Archiv verlassen und diese Seite im Standarddesign anzeigen : Vorschläge zur Verbesserung der Decodiersoftware
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.
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.
Koko, wann kommt die nächste Generation vorraussichtlich raus?
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
05.02.2007, 07:35
@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 ....
Ü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)
@ george:
gut erkannt, hier liegt die Abweichung.
TheMasterchief
08.02.2007, 20:45
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.
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...
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/sysinternals/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
:D Wer Rechtschreibfehler findet, darf sie behalten !! :D
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.
Die Priorität de Prozesses kannst Du mit dem Taskmanger oder Process Explorer (von Sysinternals) selber einstellen. Auf hoch eingestellt, geht es etwas schneller.
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!
So etwas ähnliches hat Mr. S schon geplant, ist aber im jetzigen Decoder noch nicht implementiert.
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.
Ja, am schnellsten geht es mit einer RAM Disk. Auf dem USB Stick dauert das natürlich viel länger, aber beides schont die Festplatte. Aus obigen Gründen mache ich das de-codieren nie auf der Festplatte.
Achja, ich benutze dem OMR Decoder 1.0.0.8
Dann empfehle ich einen Upgrade auf die neuste Version!
Aber eine lösung für das festplattenproblem wäre schon schön...
Meine persönliche Lösung dazu, habe ich ja oben schon gepostet!
Hallo,
wenn man das so alles liest dann kan man sich ja nur auf die neue Version freuen. Ich werde das Entpacken in´s Ram mal mit einer kleineren Aufnahme probieren. Denn mein Noti ist zwar mit 1024 bestückt, aber man kennt das ja, nicht alles ist unser auch wenn es so aussieht.:p
Die Sache mit der Priorität hatte ich schon probiert, ich denke das da die Platte der Bremsklotz ist, den den Schub den ich erwartet hatte hat es nicht gebracht.
Kann man eigenlich die zu entpackende Blockgröße bei einem Aufruf über die Kommandozeile verändern?
Ja, am schnellsten geht es mit einer RAM Disk. Auf dem USB Stick dauert das natürlich viel länger, aber beides schont die Festplatte. Aus obigen Gründen mache ich das de-codieren nie auf der Festplatte.
Naja das mit dehm USB Stick hätte ich mir auch Sparen können.
2Std30min für 1GB Decodiern!Decoder von MR S
edit: sind dann 3,5Std geworden
Naja das mit dehm USB Stick hätte ich mir auch Sparen können.
2Std30min für 1GB Decodiern!Decoder von MR S
Das liegt an dem Datendurchsatz Deines Sticks. (Alt oder billig) Bei mir dauert das ca. 15 - 30 min, je nachdem, was gerade sonst noch auf dem Rechner läuft und damit kann ich leben. :)
Das liegt an dem Datendurchsatz Deines Sticks. (Alt oder billig) Bei mir dauert das ca. 15 - 30 min, je nachdem, was gerade sonst noch auf dem Rechner läuft und damit kann ich leben. :)
Neu und Teuer Heute erst gekauft 23MB/sLesen 16MB/sSchreiben der fehler bei mir liegt warscheinlich daran das ich 4 Dateien gleichzeitig decodiere?
hab nur 8% Processor auslastung
Die Dateien werden meines Wissens nacheinander dekodiert, auch wenn mehrere Dateien ausgewählt wurden. Daran kann es also nicht liegen.
Die Dateien werden meines Wissens nacheinander dekodiert, auch wenn mehrere Dateien ausgewählt wurden. Daran kann es also nicht liegen.
Falsch.
bei 4 Markierten Dateien öffnen sich auch 4 Decoderfenster und in allen 4 Decoderfenstern schreitetet die Prozentzahl sowie der Fortschrittsbalken fort.
Danke für die Info. Ich benutze noch immer den alten OTR Downloader 1.4.0.0 (der bei mir absolut keine Dekodier-Probleme macht!), und der dekodiert nacheinander. :)
Danke für die Info. Ich benutze noch immer den alten OTR Downloader 1.4.0.0 (der bei mir absolut keine Dekodier-Probleme macht!), und der dekodiert nacheinander. :)
Ich Decodiere jetzt auch nur noch nacheinander.
geht insgesamt tatsächlich schneller(1Std bei 1GB Dateien)
Gleichzeitiges decodieren (gestern 3,5Std bei 1GB Dateien)
Ps ausschließlich auf dem USB Stick(OTRKEY+AVI)
Ja so werde ich es machen,Aber Mr,S kann ja trotzdehm die Speicherverwaltung
in dehn Decoder ein bauen.
Der Stick hat 53,05€ bei Amazon gekostet!
Es wäre außerdem gut wenn Ihr die Software-Versionsnr auf Decodiersoftwaredownloadseite angeben würdet, denn so könnte man schnell erkennen ob die eigene Version die neueste ist. Dies würde auch unnötige DL ersparen!
Gruß FRANZ
P.S: ansonsten weiter so, es hat sich die letzte Zeit einiges Positives bewegt!
Ganz besonders hervorzuheben sind die Bildqualitätsverbesserungen!! Toll !!!:)
Ja so werde ich es machen,Aber Mr,S kann ja trotzdehm die Speicherverwaltung
in dehn Decoder ein bauen.
Der Stick hat 53,05€ bei Amazon gekostet!
Mr. S wird das auch machen. Wenn das noch länger mit dem neuen Decoder dauert, bringe ich mal noch ein Release für den alten raus.
Mr. S wird das auch machen. Wenn das noch länger mit dem neuen Decoder dauert, bringe ich mal noch ein Release für den alten raus.
Das ist doch ein Wort. ;) Ich freue mich schon drauf!
Danke. :)
Partymaus
14.05.2007, 15:43
Hallo,
was haltet ihr eigentlich von einer Vorschaufunktion (des bereits runtergeladenen Teils)?
Ich fände es super, wenn ihr einen Downloadenden Dekoder bauen könntet.
oder ein Plugin für den Free Download Manager, mit dem man direkt mit dem anschauen beginnen könnte, nach dem ein paar MB runtergeladen sind.
Partymaus
14.05.2007, 15:45
Also ich lade auf dem einen Rechner runter und dekodiere auf den anderen.
Da mein WLAN nicht das schnellst ist, dauert eine Sendung (350 MB) knapp 3 Minuten zu dekodieren.
Eine größere Datei entsprechend länger.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.