Triggeredupdates’s Weblog

Just another WordPress.com weblog

Archiv für August 2009

QTRdec, ein Frontend für den otrkey-Decoder für Linux

Verfasst von triggeredupdates am August 15, 2009

Viele von euch kennen wohl den ‘kostenlosen’ TV-Aufnahme-Dienst OnlineTVRecoder. Damit dieser Dienst zumindest nicht illegal ist, werden die Aufnahmen in einem eignen Format verschlüsselt, um sicherzustellen, dass nur derjenige die Aufnahme dekodieren kann, der sie auch „in Auftrag gegeben hat“.

Der offizielle Linux-Dekoder besteht aus einer Binärdatei, die man über die Konsole bedienen kann, und einem scheinbar auf die Schnelle zusammengewürfelten PyGTK-Frontend. Daneben gibt es diverse inoffizielle Shell-Skripte zum Schneiden und das auf GTK basierende Tool „OTR-Verwaltung“, mit dem man nicht nur Dekodieren, sondern die Dateien auch verwalten kann, Schneiden, cutlists erstellen und hochladen, etc., etc.

Solche mächtigen Tools sind zwar schön und gut, aber lohnen sich für mich nicht wirklich, da ich OTR hauptsächlich für ein paar Serien nutze, die nach dem Anschauen gleich wieder ins Nirvana verschwinden. Bleibt also nur der kleine Linux-Dekoder, um mal schnell eine Aufnahme zu dekodieren. Allerdings stört es mich unter KDE zunehmend. Neben der Tatsache, dass GTK-Programme unter einer KDE-Oberfläche trotz diverser Einstellungen schrecklich aussehen, braucht das Programm doch ziemlich lange, bis es bereit ist.

Lange Rede, kurzer Sinn: Entstanden ist ein kleines Frontend für den Dekoder, geschrieben in C++ und Qt. Gleich vorneweg: Es ist weder offiziell, noch hat es in anderer Weise etwas mit OTR zu tun, außer natürlich, dass es deren Dekoder zum Dekodieren benutzt.

QTRdec v0.2.1 Im Moment handelt es sich noch um keine fertige Version. Es werden zwar alle gängigen Features des Dekoders unterstützt, es könnten aber noch Fehler im Programm schlummern. Auch ist es bisher nur auf Englisch. Der Quelltext steht unter der GPLv3, dass heißt, ihr könnt unter deren Auflagen den Quelltext benutzen, wenn ihr wollt. Wahrscheinlich will das aber keiner :)

Es gibt keine fertigen Pakete, da ich damit noch kaum Erfahrungen habe und der Dekoder meistens eh irgendwo auf dem Desktop oder im Heimatverzeichnis liegt. Ein Paket wäre daher noch übertriebener Aufwand. Das Kompilieren ist allerdings auch nicht tragisch:

Zunächst muss man, wenn nicht schon getan, die Pakete libqt4-dev und g++ installieren. Vieles davon kann man ggf. nach dem Kompilieren wieder entfernen. Wichtig ist nur, dass man zum Ausführen noch das Paket libqt4-gui installiert hat. Danach in einem Terminal zum Quellen-Ordner wechseln und qmake && make ausführen. Die entstandene Binärdatei „QTRdec“ kopiert man sich in das Verzeichnis des Dekoders und schon kann man frohlockend dekodieren. Nützlich ist es auch sicherlich, die Readme-Datei zu lesen.

Der Quelltext kann hier heruntergeladen werden: http://code.google.com/p/qtrdec/downloads/list

Ich freue mich auf eventuelle Rückmeldungen dazu und hoffe, dass es ein paar Leuten evtl. nutzt.

Veröffentlicht in Linux, Ubuntu, Ubuntuusers | Verschlagwortet mit : , , | 9 Kommentare »

FYI: Firefox-Qt zum Anfassen

Verfasst von triggeredupdates am August 8, 2009

Lange hat man nichts mehr vom Hoffnungsträger aller Firefox-Nutzer und Qt/KDE-Liebhaber in den Medien gehört, doch scheinbar geht die Entwicklung langsam aber stetig weiter.

Immer mal wieder schaue ich nach, ob aus dem Quelltext eine lauffähige Version herauskommt, und heute ist mein Glückstag, denn diese Revision aus mozilla-central lässt sich tatsächlich durchkompilieren und starten. Leider ist der Feuerfuchs mit Qt-Oberfläche noch überhaupt nicht brauchbar, aber das wird sicher noch. Wer sich selbst ein Kompilat erzeugen will, kann nach dieser Anleitung vorgehen.

Und hier noch einzwei Bildschirmfotos:

Firefox-QtFirefox-Qt

Veröffentlicht in Linux, Ubuntuusers | Verschlagwortet mit : , | 6 Kommentare »

Verschleiß- oder Hitzetod, Hitze- oder Verschleißtod?

Verfasst von triggeredupdates am August 7, 2009

Nach Einspielen der Patches gegen den berühmten Harddrive-Killer-Bug ist es sehr ruhig um allerselbigen geworden. Ab und an meldet sich nochmal jemand zu Wort, dass es bei ihm nicht wirkt. Reaktionen darauf gibt es aber kaum. Anfang Januar hatte ich ja über eventuelle Probleme durch die Änderungen der APM-Werte der Festplatten geschrieben – im speziellen bezgl. der Temperatur – dem allerdings auch kaum Beachtung geschenkt, denn da war es ja auch noch kalt.

Die aktuellen Werte lassen mich allerdings aufhorchen:

/dev/sda: TOSHIBA MK1637GSX: 55°C

/dev/sdb: TOSHIBA MK1637GSX: 52°C

Laut dem Datenblatt der Festplatte sollte die Betriebstemperatur 55°C nicht überschreiten. Inwieweit Toshiba da eine Toleranz mit eingerechnet hat, weiß ich nicht und will es auch nicht herausfinden. Testhalber habe ich aber mal bei beiden Festplatten einen APM-Wert von 128 eingestellt und das Resultat nach etwas mehr als 10 Minuten:

/dev/sda: TOSHIBA MK1637GSX: 50°C

/dev/sdb: TOSHIBA MK1637GSX: 48°C

Und nach etwa 30 Minuten:

/dev/sda: TOSHIBA MK1637GSX: 49°C

/dev/sdb: TOSHIBA MK1637GSX: 44°C

Bei der ersten Platte gab es immherin 6°C Abkühlung, bei der zweiten Platte sogar 8°C im quasi Leerlauf. Vielleicht sehe ich die Sache auch zu kritisch, aber bei diesen Werten und ohne die Toleranz zu kennen, bevorzuge ich doch lieber den langsamen Verschleißtod als den plötzlichen Hitzetod.

Veröffentlicht in Linux, Ubuntu, Ubuntuusers | Verschlagwortet mit : , , | 4 Kommentare »