Ankündigung: Neuer Decoder

[Monika]

Welches Linux hattest du denn drauf und was für Probleme hattest du?

Außer Spielen braucht man eigentlich fast nichts im Emulator laufen lassen, weil es Linux-Äquivalente gibt.

[cc.sbr@web.de]

hallo,

bin neu hier.

hab mir gerade den Dekoder geladen.
Dann hab icvh die Datei, die auf dem Desktop lag, ausgewählt und auf Dekodieren geklickt.
Da hat er mich dann nach der Email Adresse und das Kennwort gefargt.
Das hab ich eingegeben und nun kommt:

Fehler:Das Dekodieren ist fehlgeschlagen.


Muss ich da was einstellen?

Danke schon mal im voraus

Gruss
Claudio

[NGC-Ollie]

ja: wohin willst du decodieren? also der zielordner sollte nicht C: oder d: o.ä. lauten.

[Monika]

hallo,

bin neu hier.

hab mir gerade den Dekoder geladen.
Dann hab icvh die Datei, die auf dem Desktop lag, ausgewählt und auf Dekodieren geklickt.
Da hat er mich dann nach der Email Adresse und das Kennwort gefargt.
Das hab ich eingegeben und nun kommt:

Fehler:Das Dekodieren ist fehlgeschlagen.


Muss ich da was einstellen?

Danke schon mal im voraus

Gruss
Claudio
Hattest du die Sendung vorher bei OTR aufgenommen?

Ist es vielleicht eine mp4- oder HQ-Datei und du hast dafür nicht genügend GWP?

Tippfehler in E-Mail-Adresse oder Passwort?

Firewall?

[stna1981]

Werden jetzt eigentlich Decodierungen mit dem neuen 1.0.0.20er Decoder mittlerweile gezählt oder immer noch nicht?

[moep]

Sie werden gezählt. Ich denke, dass es egal ist, mit welchem Decoder du decodierst, da dies unter anderem auch im DL-Menü angezeigt wird und somit zentral gespeichert/auslesbar ist.

[stna1981]

Am Anfang wurde es definitiv nicht gezählt, obwohl die Datei im DL-Menü als decodiert angegeben wurde, daher die Frage ;)

[gulliver]

Es gibt jetzt eine Test-Version, welche für Windows 98 kompatibel ist(http://otrforum.com/showthread.php?t=30028). Feedback bitte auch in dem entsprechenden Thread!

[C167]

*antipp*
Linux?

[kopfgeldjaeger]

*antipp*
Linux?
*gegenTürHau*

[C167]

nich doch, dur wirst deine matschbirne noch brauchen *grins* :o

[SGE]

*gegenTürHau*

mein gott, es wird einen linux-decoder geben, wenn er fertig ist.
vom ständigen nachfragen gehts auch nicht schneller.
habt ihr alle keine geduld mehr?

[kopfgeldjaeger]

mein gott, es wird einen linux-decoder geben, wenn er fertig ist.
vom ständigen nachfragen gehts auch nicht schneller.
habt ihr alle keine geduld mehr?
Wenn ich mir nen bisschen verarscht vorkomm, nicht...



Oh yeah, I forgot the usual Disclaim; I'm not a dev, I don't know how to program, I don't know what i'm talking about, and don't turn this into a flame war!!

[Mr. S]

Wenn ich mir nen bisschen verarscht vorkomm, nicht...



Oh yeah, I forgot the usual Disclaim; I'm not a dev, I don't know how to program, I don't know what i'm talking about, and don't turn this into a flame war!!
Jetzt schaltet mal einen Gang zurück und beschränkt euch auf eine sachliche Diskussion! Falls es immernoch Leute gibt, die nicht in der Lage sind die erste Seite zu lesen oder zu verstehen hier nochmal die Zusammenfassung:
Das Verfahren wird geändert
Der Decoder für WinXP ist ein Testprogramm um das Ganze auszuprobieren
Nach dem Feedback gewisser Leute werden Verfahren und Decoder noch überarbeitet
Wenn alles funktioniert wie es soll, gibt es auch Decoder für andere Systeme. Es bringt nix Decoder für alle Systeme zu schreiben wenn das Verfahren nicht funktioniert und/oder noch ein duzend mal verändert wird!
Gewiss, mich stört es auch, dass es so lange dauert aber besser es wird anständig gemacht als so ein Käse wie bei diesem Test.

[C167]

hier wurde es ja auch schon angesprochen, dass es offenbar garnicht so schwer ist, eine Bibliothek in C/C++ zu schreiben, die auf Linux und windows funktioniert.
Meiner Meinung nach laesst sich die Bibliothek ja auf folgendes reduzieren:
- Uebergabe der Optionen
- oeffnen der datei
- in der Datei herumwursteln
- Datei schliessen
- return-wert zurueckgeben
das Eigentliche Decodieren muesste ja auf jedem System funktionieren, die Standard-Bibliotheklen sollten dafuer reichen (denke ich zumindest).
Viel mehr als Datenbloecke herumschieben/verarbeiten kann es ja eigentlich nicht sein...
waere nett wenn sich mal wieder einer der Devs melden wuerde

[C167]

einfach mal wissen wie weit sie sind und evtl einige details...
ich persoenlich habe naemlich langsam das Gefuehl, dass es nicht so wirklich weitergeht

[Taube]

einfach mal wissen wie weit sie sind und evtl einige details...
ich persoenlich habe naemlich langsam das Gefuehl, dass es nicht so wirklich weitergeht

Ist das von Belang? Je öfter man fragt, je langsamer geht es voran. :p

[Mr. S]

einfach mal wissen wie weit sie sind und evtl einige details...
ich persoenlich habe naemlich langsam das Gefuehl, dass es nicht so wirklich weitergeht
Naja, sagen wir es mal so. Es muss fast das ganze System geändert werden. Das neue Format muss nämlich noch überarbeitet werden, das ist nicht optimal und die Server müssen auch umgebaut werden. An der Qualität der Testversion kannst du ja sehen, dass man da für minderwertige Qualität schon recht lange braucht. Bei den systemseitigen Programmen muss das aber zu 100% funktionieren, das dauert natürlich dementsprechend länger. Da wird sich außer mir auch keiner zu dem Thema von OTR-Seite aus dazu äußern!

[fr3ddy]

Da der Thread zu lang ist konnte ich jetzt leider nicht alles durchlesen.

Wie siehts denn mit der Mehr-Kern Unterstützung aus? Stichwort Multithreading in abhängikeit von der CPU Zahl. Im Moment arbeiten viele Leute schon mit zwei Kernen und im nächsten Jahr werden sicherlich schon die ersten Standard PCs mit 4 Kernen kommen.

Ein gut skalierender Dekoder wäre toll und sollte doch realisierbar sein.

Gruß

[NGC-Ollie]

das wär mal total unnötig! die decodierung läuft bei mir nicht mal auf 10% CPU-last und wird nur von der HDD gebremst.

[friendly]

Ich habe jetzt wegen schönen Wetters garnichts durchgelesen.

Sinnvoller dürfte erstmal die Optimierung der Disk-I/O-Vorgänge sein; die restlichen Kerne werden doch eh' dazu gebraucht, gleichzeitig einen Film auf den Monitor auszugeben! ;)

[Mr. S]

Sinnvoller dürfte erstmal die Optimierung der Disk-I/O-Vorgänge sein; die restlichen Kerne werden doch eh' dazu gebraucht, gleichzeitig einen Film auf den Monitor auszugeben! ;)
Das wird zumindestens bei meinem Decoder verbessert. In der Tat ist der IO-Zugriff das Problem. Das wird sich auch nicht ändern, da der verwendete Blowfish für jede verfügbare Festplatte zu schnell ist (außnahme vielleicht wenn man mit 500 MHz decodiert :rolleyes:). Blowfish schafft mehr als 30 MB/s, nur schafft das keine Festplatte diese Menge gleichzeitig zu lesen und zu schreiben. Die schnellen Festplatten schaffen vielleicht 50 MB aber nur lesen und nicht gleichzeitig auch noch schreiben. Ganz zu schweigen davon, das das Verfahren immernoch diese blöde Blockverschiebung hat, womit alle paar Bytes erst mal die Zugiffszeit gewartet werden muss bis der Schreib-Lese-Kopf zu dem nächsten Fragment gesprungen ist. Mit dem neuen Verfahren wird das besser und eine IO-Optimierung wird nochmal zusätzlich Speed bringen. Eine Mehr-Kern-Unterstützung bringt noch nichts. Vielleicht ändert sich das mal wenn es Flash-Speicher mit genügend Geschwindigkeit gibt, aber das dauert noch eine Weile. Das gleiche gilt auch für eine 64-Bit-Optimierung.

[fr3ddy]

Hm komisch, bei meinem Athlon64 3700+ (2,2 GHz) braucht der decoder 100% CPU. Und mit meinem Athlon xp 2600+ geht es auch deutlich langsamer.
Ach ja udma ist auf on...

Ich habe gerade fest gestellt, dass dieses Problem nur unter Linux auftritt, unter XP verhält er sich wie von euch beschrieben.

Damit wird die mehrkern unterstützung natürlich hinfällig :-/

[httpkiller]

ich weiss garnicht, warum so viele über die Dekodier-Geschwindigkeit jammern :confused:

XP 2800+ @2413MhZ , 2 GB DDR-4000 und RAID-System, fürn Standart Film (2 Stunden) brauch der nedmal ganz ne Minute.

Multicore-Optimierung ist meiner Meinung nach NOCH nicht sinnvoll, ich denke, die Mehrzahl der PC-Anwender nutzen immernoch Single-Core Prozessoren (Mich inbegriffen :D)

mfg,

[Taube]

Bedenke, dass nicht jeder Benutzer High-End-PC hat und dafür nutzen möchte! Wir haben einen Linux-Rechner als Router im Keller. Nachttraffic ist bei uns günstiger - was liegt also näher auf der paar hundert Mhz-Mühle als entsprechende otrkeys dann zu laden und bereits dekodiert abzulegen?

[sw2005]

stimmt, mache ich auch oft... nicht dran gedacht. Wenn der RAM nicht ausreicht, ist diese Komfort-Funktion eben deaktiviert (oder gleich vom Benutzer einstellbar)

Andererseits wird auf dem Linux-Router sicher nicht Mr.S's Decoder laufen ;)

[Taube]

Andererseits wird auf dem Linux-Router sicher nicht Mr.S's Decoder laufen ;)

Um ehrlich zu sein blicke ich gerade nicht mehr durch, wessen Decoder auf welchem Betriebssystem in welcher Version für wen was macht. :rolleyes:

[Monika]

Der Decoder von Mr. S ist für Windows.

[Mr. S]

Der Mr. S-Dekoder macht das bereits so, dass er größere Blöcke im RAM decodiert und dann zusammen wegschreibt, wenn man den so einstellt (gibt es irgendwo einen Schieber wie viel RAM der dafür verwenden soll). Es macht dabei kaum Sinn, mehr als 20MB oder so zu verwenden, alles da drüber wirkt sich in der Regel kaum noch aus. Der OMR-Multidecoder macht das dagegen aber noch nicht bzw. verlässt sich darauf das Windows das schon irgendwie hincachen wird, was es auch zu tun scheint, sonst wäre der deutlich langsamer. Was den Decoder langsamer macht als den von Mr. S ist die MD5-Prüfung sowohl vor als auch nach dem decodieren und einige sinnlose Warterei nachdem der Key vom Server geholt vor dem decodieren wird bzw. zwischen zwei dekodiervorgängen. In dem Decoder wimmelt es nur so von sinnlosen sleep()s... Was außerdem meiner Meinung nach absolut keinen Sinn macht ist ein MD5-Check der decodierten Datei, der hier aber durchgeführt wird. (Jedoch nur bei neuen OTRKEYs, die ihr noch nicht habt.). Die Verzögerung die ihr bemerkt beruht schlichtweg auf Wartebefehlen in dem Programm.Ahhh, ich fühle mich geschmeichelt, aber ganz korrekt ist das leider nicht. In der Tat hat mein Decoder diese Speichereinstellung (MsTiFtS hast Recht, ich werde das auf 64 MB beschränken) aber das Ganze ist leider noch ohne Wirkung. Das einlesen von größeren Dateimengen funktioniert erst mit der nächsten Version korrekt. Sleeps sind bei mir auch drin, aber die kann man mit dem Verzögerungsregler ausschalten. Ich bezweifel das Windows da richtig cached, sondern behaupte mal das es eher die Festplatte ist. Bei Windows ist mir eine solche Funktion nicht bekannt.

[JennyMiller]

Der Festplattencache macht zwar sicherlich auch was aus, aber da dieser im Verhältnis zum Windowscache extrem klein ist, wird der Windowscache im Moment sicher den Löwenanteil ausmachen.

Windows ist dafür bekannt, dass es selbst den Cache auslagern kann.


Wenn ich mit 2GB RAM eine 100MB-OTRKEY direkt nach dem Download dekodiere, [...]

Ich denke, der Standard ist bei nicht-Höllenmaschinen eher 512MB bis 1024MB RAM und die OTRkeys bewegen sich auch eher in Richtung 1GB Größe ;)

Wie auch immer, ihr Programmierer werdet das schon richtig machen. Den aktuellen OTR-Dekoder zu verbessern sollte ja nicht schwer sein :D

[Mr. S]

Die Frage ist bloß, wie lange es noch dauern wird bis das neue OTRKEY/OMRKEY-Format fertig ist und dann die entsprechenden Encoder auf den Servern von OTR/OMR laufen. Was die als neuen Decoder machen ist Mr. S und mir reichlich egal, aber das alte OTRKEY-Format ist das Problem.
Vermutlich wird der neue Mr. S-Decoder dann ebenfalls OTRKEY, OMRKEY und YOM dekodieren und sogar YOM enkodieren können, technisch ist das kein Problem, das hängt lediglich davon ab ob Mr. S genug Zeit für solche Features übrig hat. Mal sehen...
Zuerst wird OTRKEY geändert, obwohl OMRKEY auch sehr problematisch ist, aber dazu sind mir noch keine konkreten Änderungen bekannt.
Das neue OTRKEY-Format wird angeblich schon getestet, dürfte also in ein paar Wochen fertig sein. OMRKEY/YOM werde ich einbauen wenn da auch das neue Format eingepackt ist, vorher lohnt sich das nicht und es ist reine Zeitverschwendung die alten Formate zu implementieren.

[Robin Good]

Hi,
danke Mr.S... für die Antwort.

Zutat von Mr. S...:
Falsch! Es wird immernoch IE verwendet, mach einfach mal einen Abhängigkeitscheck und denke mal darüber nach...

Ich weiß nicht, wofür IE im Programm verwendet wird. Kommunikation mit dem Server erfolgt aber ohne IE-Funktionen. Beim Testen habe ich IE off-line eingestellt und d.h. Proxy-Adresse und Proxy-Port in Decoder eingegeben.
Entschlüsselung war reibungslos. Bitte versuch mal einfach zu testen!

Gruß
Robin Good

P.S. My friends, I see the politeness isn't your quality. I'm sorry.

[mercury202]

Außerdem solltest du als Programmierer wissen, dass wenn auf 38 Seiten Leute über bugs berichten, die die verschiedensten Systeme benutzen, und dann einer dabei ist, der keine bugs zu verzeichnen hat, dass nicht heißt, dass die einen oder die anderen Hirngespinste haben, sondern das einfach die wenigsten Fehler auf allen Systemen auftauchen...

[Robin Good]

Hi Monika,

du hast recht, wie immer. Ich meine den zweiten Teil deines Beitrages (habe sofort gelöscht).

Was aber den ersten Teil betrifft, habe ich leider aus diesem Forum so verstanden, dass es hier eher nicht ums Jammern, sondern um Vorurteil geht. Es tut mir leid.

Bestimmt, die Bugs, die wirklich auftreten, müssen besprochen werden.
Nicht aber die Fehler, die nicht existieren. Ich denke, dass OTR-Team Feed-Back braucht. Dafür ist eigentlich dieses Forum.

Viele Grüße
Robin Good

[MsTiFtS]

Hi,
danke Mr.S... für die Antwort.


Ich weiß nicht, wofür IE im Programm verwendet wird. Kommunikation mit dem Server erfolgt aber ohne IE-Funktionen. Beim Testen habe ich IE off-line eingestellt und d.h. Proxy-Adresse und Proxy-Port in Decoder eingegeben.
Entschlüsselung war reibungslos. Bitte versuch mal einfach zu testen!

Gruß
Robin Good

P.S. My friends, I see the politeness isn't your quality. I'm sorry.
Auch wenn der IE nicht zum Keyholen eingesetzt würde, gebraucht würde er dennoch. Ohne installierten IE wird das Programm aufgrund nicht auflösbarer Abhängigkeiten nicht starten, damit rollt man den WINE-Usern schonmal einen recht großen Stein in den Weg. Der IE hat in so einem Programm nichts verloren - gar nichts!

Ich glaube ich kenne die Internals dieses Dekoders deutlich besser als du, und ich kann einwandfrei bestätigen, dass zumindest ein sehr großer Teil der Probleme noch existiert. Dennoch sehe ich, dass sich OTR im Moment auf dem richtigen Weg zu befinden scheint, und das ist absolut lobenswert. Das eigene Konzept über den Haufen zu werfen und sich in den Kernfragen nochmal von Externen neu beraten zu lassen, da gehört schon eine ordentliche Portion Mut dazu.

Ich finde nicht, dass hier ein sonderlich unhöflicher Ton herrscht. (Einige Extremposts jetzt mal ausgenommen.) Ungeduldig trifft die Stimmung hier schon eher. Aber sonderlich höflich finde ich gehst du mit Moep und Mr. S hier grade auch nicht um, da hat Monika absolut recht.

[Monika]

Auch wenn der IE nicht zum Keyholen eingesetzt würde, gebraucht würde er dennoch. Ohne installierten IE wird das Programm aufgrund nicht auflösbarer Abhängigkeiten nicht starten, damit rollt man den WINE-Usern schonmal einen recht großen Stein in den Weg.
Das würd ich gern näher wissen. Bei mir läuft es unter Wine prima (bis auf den Minimierungsbug), ich hab allerdings auch IE unter Wine installiert. Alle anderen hier, die es unter Wine probiert haben, hatten auch keine Probleme. Aber haben die alle den IE installiert? Das macht man ja meist nicht, es sei denn man entwickelt/testet Websites.

[MsTiFtS]

Das würd ich gern näher wissen. Bei mir läuft es unter Wine prima (bis auf den Minimierungsbug), ich hab allerdings auch IE unter Wine installiert. Alle anderen hier, die es unter Wine probiert haben, hatten auch keine Probleme. Aber haben die alle den IE installiert? Das macht man ja meist nicht, es sei denn man entwickelt/testet Websites.
Ich habe das mit WINE jetzt mit dieser Version speziell jetzt auch nicht ausprobiert, aber in jeder OTR unter WINE-Anleitung steht, dass man den IE installiert haben muss bzw. wie das im groben geht. Auch einige Tests etwas älterer Decoderversionen ergaben, dass der IE immer gebraucht wurde, zumindest wenn es mir gelang das Teil überhaupt ans Laufen zu kriegen.

[Mr. S]

Dann empfehle ich wirklich mal die Abhängigkeiten und DLL-Aufrufe zu checken:


winspool.drv: Druckerfunktionen (wozu werden die geladen, man druckt doch gar nichts?)
oledlg.dll, oleaut32.dll, oleacc.dll: OLE-COM-GUI (überflüssige Resourcenverschwendung! COM-GUI durch WinAPI ersetzen braucht viel weniger Ressourcen)
iphlpapi.dll: Netzwerkgeräte und TCP/IP-Informationen auslesen und ändern (wozu?)
wininet.dll: IE-Internetfunktionen

http://otrforum.com/showpost.php?p=67502&postcount=3

[C167]

wie findet man die abhaengigkeiten und lib-aufrufe eigentlich heraus?

[mschafhuber]

Allerdings reicht es völlig aus, den Link einmal hier im Thread zu posten :)
hat sich aber geändert.......

Schon ca. 30mal gedownloadet...................................... .....................................
25.5.2007 1MB Serverlogs................

[C167]

*antipp*
linux?

[MsTiFtS]

Bevor es einen Windowsdecoder für das neue Format gibt wird es sicherlich keinen Linuxdecoder geben. Und für OTRv3-Dateien gibt es noch gar nix, soweit ich weiß ist noch nicht mal das neue Format bzw. der Encoder dafür fertig. Bevor die ersten OTRv3-kodierten Dateien kommen wird es aber sicher zumindest einen Javadecoder, vermutlich auch einen Linux-C++-Decoder geben, wenn auch vermutlich closed-source. Das OTRv2-Format um das es sich bei dem hier angekündigten Decoder ging wird definitiv nie zum Einsatz kommen weil vor der Einführung da noch heftige Mängel festgestellt wurden. Mit OTRv3 sollte das Decodieren dann aber in Rekordzeiten durchführbar sein. Also bitte einfach noch ein bisschen Geduld, bis es soweit ist könnt ihr ja noch problemlos den alten (Linux-)Decoder nutzen.

[Mr. S]

Bevor es einen Windowsdecoder für das neue Format gibt wird es sicherlich keinen Linuxdecoder geben. Und für OTRv3-Dateien gibt es noch gar nix, soweit ich weiß ist noch nicht mal das neue Format bzw. der Encoder dafür fertig. Bevor die ersten OTRv3-kodierten Dateien kommen wird es aber sicher zumindest einen Javadecoder, vermutlich auch einen Linux-C++-Decoder geben, wenn auch vermutlich closed-source. Das OTRv2-Format um das es sich bei dem hier angekündigten Decoder ging wird definitiv nie zum Einsatz kommen weil vor der Einführung da noch heftige Mängel festgestellt wurden. Mit OTRv3 sollte das Decodieren dann aber in Rekordzeiten durchführbar sein. Also bitte einfach noch ein bisschen Geduld, bis es soweit ist könnt ihr ja noch problemlos den alten (Linux-)Decoder nutzen.
Das ist korrekt, ich habe auch darum gebeten OTRv3 erst testen zu dürfen bevor das Format in der Fläche eingeführt wird. So ein Theater wie bei OTRv2 ode so ein Chaos wie bei der letzten GWP-Änderung möchte ich auf jeden Fall vermeiden! Für einen fehlerfreien offiziellen Decoder garantiere ich natürlich nicht. Den Java-Decoder werde ich auch in zwei Varianten anbieten, einmal als Konsolenversion und einmal mit GUI. Bei Java beachten: Java ist langsamer und benötigt mehr Resourcen als C++!

[cl1993]

Wird der Mac-Decoder wieder ein Comandline-Tool werden? Wär ganz gut, denn dann könnte ich mein AppleScript-Programm leicht umstellen... (Dekodiert OTRkey-Dateien per Drang and Drop... :D )

Kann sein das die Frage schonmal gestellt wurde... hab mir jetzt nicht alle 40 seiten hier durchgelesen...

[MsTiFtS]

Wird der Mac-Decoder wieder ein Comandline-Tool werden? Wär ganz gut, denn dann könnte ich mein AppleScript-Programm leicht umstellen... (Dekodiert OTRkey-Dateien per Drang and Drop... :D )

Kann sein das die Frage schonmal gestellt wurde... hab mir jetzt nicht alle 40 seiten hier durchgelesen...Ich habe den kompletten Thread verfolgt aber kann mich nicht an ein Statement dazu erinnern. Ich würde aber davon ausgehen, dass sich OTR da nicht den Aufwand machen wird da wieder ein GUI dafür zu bauen was man nachher nicht wegkriegt. Sollte das dennoch der Fall sein wird es auf jeden Fall einen Java-Commandline- und einen Java-GUI-Decoder geben, mit dem du das dann erledigen kannst.

[cl1993]

Ich habe den kompletten Thread verfolgt aber kann mich nicht an ein Statement dazu erinnern. Ich würde aber davon ausgehen, dass sich OTR da nicht den Aufwand machen wird da wieder ein GUI dafür zu bauen was man nachher nicht wegkriegt. Sollte das dennoch der Fall sein wird es auf jeden Fall einen Java-Commandline- und einen Java-GUI-Decoder geben, mit dem du das dann erledigen kannst.
Ok, danke... (Auch wenn ich Java nicht mag...)