Archiv nach Kategorien: Ubuntu

Yet another tiling extension

Vor einiger Zeit habe ich ja bereits auf Shellshape hingewiesen. Die Kombination aus Gnome-Shell Extension und Mutter-Ersatz bringt echtes Tiling auf den Gnome-Desktop. Zum alltäglichen Einsatz konnte ich mich dann aber doch nicht durchringen: Die starke Unterscheidung der beiden Modi “Tiling” und “Floating” sprach mich nicht sonderlich an und die vielen Tastenkürzel um die jeweiligen Tiles zu vergrößern, zu verkleinern, zu verschieben und zu tauschen fand ich auch nicht übermäßig intuitiv.

Tiling mit gTile

Tiling mit gTile

gTile
Auf der neuen Gnome3-Extension-Seite bin ich dann noch auf gTile gestoßen. Diese Erweiterung erlaubt ebenfalls das überlappungsfreie Anordnen der Fenster – allerdings wird hier das jeweils aktive Fenster durch eine kleine Dialog-Box auf dem Bildschirm angeordnet. Auch ein sehr schöner Ansatz, der etwas einsteigerfreundlicher wirkt, als die Shellshape-Variante.

Mir war aber eher nach einem Ansatz, wie ich ihn unter Ubuntu einmal mit Compiz umgesetzt hatte: Durch Tastenkombinationen wollte ich die Fenster schnell und flexibel beliebigen Ecken des Bildschirms zuweisen können. Durch mehrmaliges Tasten-Drücken – so die Überlegung – würden die Fenster dann in ihrer Ecke verschiedene Größen annehmen. Eine gute Gelegenheit, sich einmal näher mit den Gnome-Shell-Extensions zu befassen.

Ein mit KeyTiling erstelltes Layout

Die verschiedenen Fenster wurden hier bequem mit “KeyTiling” angeordnet.

KeyTiling
Herausgekommen ist dabei “KeyTiling“, eine einfache Gnome-Shell-Erweiterung, die das Arrangieren der Fenster mittels Tastenkombinationen erlaubt. Natürlich sind die damit erreichbaren Layouts letztlich begrenzt; für die meisten Anwendungsfälle sollte es aber genügen. Außerdem unterstützt KeyTiling mehrere Monitore und erlaubt es beispielsweise, ein Fenster schnell auf den nächsten Monitor zu packen und dort nach Wunsch auszurichten.

Die Erweiterung läuft stabil, hat aber noch einen kleinen Pferdefuß: Ich habe bisher nur die Funktion “Main.wm.setKeybindingHandler” gefunden, um globale Tastenkombinationen aus der Erweiterung heraus zu registrieren. Diese Funktion scheint aber auf bestimmte vordefinierte Kombinationen in “/apps/metacity/global_keybindings” beschränkt zu sein. Daher ist es mir bisher nicht gelungen, neue Kombinationen zu registrieren – ich musste bestehende Schlüssel überschreiben, namentlich die Schlüssel “run_command_[1-11]“. Das sollte in der Regel nicht schmerzen, weil benutzerdefinierte Tastenkürzel in Gnome3 diese Schlüssel gar nicht mehr berühren. Dennoch: Bei der Aktivierung der Erweiterung werden die fraglichen Tastenkürzel kurzer Hand überschrieben und auf “KeyTiling” umgebogen.

Außerdem könnten die Fenstergrößen Anlass zur Kritik geben. Momentan nehmen die Fenster in den Ecken wahlweise 1/3, 1/2 oder 2/3 der Bildschirms ein. Eine strikte Aufteilung in Vierteln wäre sicher sinnvoller bezüglich der Kombinationsmöglichkeiten – die resultierende Fenstergröße fand ich aber nicht sonderlich günstig für meinen Bildschirm. Eine Aufteilung in Sechstel würde noch mehr Freiheiten bei der Anordnung der Fenster ermöglichen – dazu müsste der Nutzer aber bis zu 30 Mal eine bestimmte Tastenkombination drücken – nicht gerade erstrebenswert.

Schließlich scheint es in bestimmten Fällen Probleme mit der Positionierung der Fenster zu geben – eventuell ist dies auf Sekundärbildschirme beschränkt, die keine obere Leiste haben, ganz sicher bin ich mir da noch nicht.

Wie auch immer: Dieses kurze und nicht sonderlich unterhaltsame Video zeigt, wie verschiedene Fenster auf dem Desktop angeordnet werden und mittels mehrfacher Tastendrücke unterschiedliche Größen annehmen.

Von echtem Tiling kann, wie ihr seht, keine Rede sein – “KeyTiling” ist eher eine Hilfe, um Fenster nebeneinander anzuordnen.

Die Tastenkombinationen
Zur Zeit sind alle Tastenkombinationen fest im Script eingebaut. Sie können dort aber relativ leicht angepasst werden. Die Belegung stellt sich dabei wie folgt dar:

  • <Control><Alt>KP_1: Fenster unten links anordnen.
  • <Control><Alt>KP_2: Fenster unten anordnen.
  • <Control><Alt>KP_3: Fenster unten rechts anordnen.
  • <Control><Alt>KP_4: Fenster links anordnen.
  • <Control><Alt>KP_5: Fenster auf anfängliche Position und Größe zurück setzen.
  • <Control><Alt>KP_6: Fenster rechts anordnen.
  • <Control><Alt>KP_7: Fenster oben links anordnen.
  • <Control><Alt>KP_8: Fenster oben anordnen.
  • <Control><Alt>KP_9: Fenster oben rechts anordnen.
  • <Control><Alt>KP_0: Zwischen Vollbild- und Normalmodus hin- und herschalten.
  • <Control><Alt>KP_Enter: Fenster auf den nächsten Monitor verschieben.

Wer KeyTiling einmal testen möchte, kann es über Github beziehen. Für Rückmeldungen und Tipps – besonders bzgl. einer besseren Hotkey-Schnittstelle – bedanke ich mich schonmal.

Kleiner Ersatz für nautilus-open-terminal

Da die Erweiterung nautilus-open-terminal schon seit einiger Zeit für Probleme sorgt und Nautilus abstürzen lässt (Fehlermeldung,Bericht bei Chris) und ich mir ohnehin mal die Python-Schnittstelle von Nautilus ansehen wollte, habe ich eine kleine Erweiterung geschrieben, die nautilus-open-terminal ersetzen soll, bis das Original wieder einwandfrei arbeitet.

Die von Chris angesprochenen Probleme mit “Nautilus-Python” scheinen insgesamt darauf zurückzuführen zu sein, dass für Nautilus-Erweiterungen die GTK3-Anbindung jetzt zwingend erforderlich sind. Durch die Ableitung von GObject ließen sich in meinem Fall also die Probleme beseitigen.

Wer sich meine “open-terminal”-Variante einmal ansehen möchte, kann dies bei GitHub tun. Abgelegt wird das Skript im Verzeichnis ~/.local/share/nautilus-python/extensions/, wobei ich das Verzeichnis in meinem Fall erst noch erstellen musste.

Kurztipp: Datei löschen unter Gnome3

Wer unter Gnome3 eine Datei oder einen Ordner in den Müll befördern möchte, wird sich zunächst wundern: Das Tastenkürzel “Entf” zeigt keine Reaktion. Tatsächlich spring Nautilus unter Gnome3 erst durch die Tastenkombination “STRG+Entf” in den Abfallbeseitigungsmodus.

Um das zu ändern, kann kurzzeitig die Option “can-change-accels” mit dem dconf-editor (der unter Umständen noch nachinstalliert werden muss) aktiviert werden. Diese findet sich im Pfad “org.gnome.desktop.interface”. Ist das entsprechende Häckchen gesetzt, wird in Nautilus eine beliebige Datei markiert. Danach wird der Mauszeiger im Menü Bearbeiten auf den Punkt In den Müll verschieben gesetzt – ohne zu klicken. Es kann nun eine neue Tastenkombination festgelegt werden – in unserem Fall durch das Drücken von “Entf” (ggf.  zwei Mal drücken).

Die Option “can-change-accels” kann danach wieder deaktiviert werden.

Fenstertitel ändern

Programme wie “Titlebar Time 2” zeigen unter Windows die Zeit in der Titelleiste des Fensters an. Bei Ubuntuusers kam die Frage auf, wie sich das auch unter Ubuntu umsetzen ließe. Nach einigen Versuchen mit “wmctrl” bin ich bald auf die nützliche Bibliothek libwnck gestoßen, für die es auch eine Python-Anbindung gibt.

Ich habe das Ganze in ein Skript gegossen, das es ermöglicht, die Fenstertitel um beliebige Informationen zu erweitern – etwa die aktuelle IP-Adresse oder die Uhrzeit.

Parameter

Wird das Skript ohne weitere Parameter gestartet, zeigt es die Zeit im aktiven Fenster an. Weiterhin kennt es noch folgende Optionen:

  • -s / –seperator: Es wird eine eindeutige Zeichenkette benötigt, mit der die zusätzliche Information im Fenstertitel vom ursprünglichen Fenstertitel getrennt wird. Mit diesem Schalter kann man die entsprechende Zeichenkette verändern.
  • -a / –all-windows: Normalerweise wird nur der Fenstertitel des aktiven Fenster verändert. Wer die Fenstertitel *aller* Fenster verändern möchte, muss diese Option setzen.
  • -r / –run: Wer statt der Zeit andere Angaben im Fenstertitel zeigen möchte, kann hier entsprechende Befehle ausführen lassen – etwa “date”.
  • -t / –timeout: Dauer zwischen zwei Aktualisierungen in ms. Standard: 10.000 ms.
  • -c / –cache: Wenn eigene Befehle mit “-r” ausgeführt werden, können die Ergebnisse gecacht werden. Standard: 30.000 ms).

Um beispielsweise die aktuelle IP im Fenstertitel anzeigen zu lassen, wäre folgender Aufruf denkbar:

 ./titlechanger.py -r 'curl -s http://www.wieistmeineip.de/|egrep -o "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+"'

Nachteile

(Achtung: Siehe Abschnit “Update”)

Da jeder Zeit Fenster geöffnet und geschlossen werden können, muss das Skript recht häufig nach Veränderungen Ausschau halten. Standard sind hier 250ms.  Das ist kein großes Problem, so lange nur die Zeit angezeigt wird. Sobald aber der Parameter “-r” ins Spiel kommt, sollte man sich vor Augen halten, dass der entsprechende Shell-Befehl alle 250ms ausgeführt wird. Mag das bei “date” noch akzeptabel sein, würde man damit beim Ermitteln der IP mittels einer externen Webseite den Anbieter 4 Mal in der Sekunde mit Anfragen belästigen. Entsprechend wurde im obigen Beispiel der Timeout auf 5 Sekunden erhöht – mit dem hässlichen Effekt, dass neue Fenster im schlimmsten Fall erst nach 5 Sekunden mit der gewünschten Angabe versehen werden.

Etwas mehr Logik im Skript könnte das Problem sicher eingrenzen. Zum Herumspielen und Experimentieren eignet sich das Skript allemal. Darüber hinaus muss jeder selbst abwägen, ob ihm modifizierte Fenstertitel die zusätzlichen Ressourcen wert sind.

Update

In der aktuellen Version des Skript (0.2) wurden viele der o.g. Probleme behoben: Das Skript erkennt, wenn das aktive Fenster gewechselt oder ein neues Fenster geöffnet wurde. Auch vom Programm veränderte Titelleisten werden jetzt erkannt. Deshalb wurde der Standard-Timeout auf 10 Sekunden angehoben.

Weiterhin wurde mit der Option “-c” ein Cache implementiert, der die Ergebnisse von Shell-Kommandos 30 Sekunden vorhält. Damit sollten dann auch Abfragen von Internetseiten kein Problem mehr darstellen.

Abhängigkeiten

Bei einer normalen Ubuntu-Installation sollte die Installation des Paketes

  • python-wnck

ausreichen.

Download

titlechangerV02.py.tar (aktuell)

titlechanger.py.tar (veraltet)

x264 und mencoder: 2nd pass has more frames than 1st pass

Ich beschäftige mich schon seit einigen Monaten immer mal wieder mit dem Kodieren von x264-Videos mit Hilfe von mencoder. Dabei erhalte ich häufig Fehlermeldungen wie die Folgende nach dem zweiten Durchlauf:

Skipping frame!
 
Skipping frame!
 
Skipping frame!
 
Skipping frame!
spudec: Error determining control type 0x17.  Skipping -6 bytes.
x264 [error]: 2nd pass has more frames than 1st pass (145880)
x264 [error]: continuing anyway, at constant QP=22
x264 [error]: disabling adaptive B-frames

Das Problem ist teilweise schwer zu reproduzieren. Die selbe Ausgangs-DVD (ISO) läuft unter OGMrip (ein mencoder-Frontend) ohne Probleme durch, bei händisch zusammengestellten mencoder-Commandlines tritt das Problem häufig, aber auch nicht immer auf.

Weil es im Netz dazu wenige Informationen gibt, wollte ich die an dieser Stelle einfach mal zusammentragen:

1. x264-Devs: Foren-Beitrag 1, Foren-Beitrag 2
2. OGMrip-Devs: Foren-Beitrag1 Foren-Beitrag 2
3. mencoder-Devs Mailinglist-Nachfrage

Es sieht also so aus, als ob es sich dabei in erster Linie um ein mencoder-Problem handelt, das aber wohl vorwiegend (oder ausschließlich?) im Zusammenhang mit x264 auftritt.

Folgende mögliche Abhilfen scheint es zu geben:

  • Generell ist unbedingt darauf zu achten, dass der erste und zweite Durchlauf keine unterschiedlichen Filter oder andere unterschiedliche Einstellungen verwenden, die sich auf die Anzahl der Frames auswirken könnten.
  • Bei OGMrip scheint man das Problem mit der x264-Option “nombtree ” umschiffen zu wollen. Laut x264-Devs hilft das nur bei älteren x264-Versionen, da diese mit dieser Option toleranter auf falsche Frame-Zahlen reagieren. Unter Lucid konnte ich das Problem mit der Option ‘nombtree’ aber auch beseitigen!
  • Anscheinend tritt das Problem auch in Abhängigkeit der anderen verwendeten x264-Einstellungen auf. Folgendes Profil ist beispielsweise sehr fehleranfällig:
    Profil: Normal
     
    "subq":"5",
    "frameref":"2",
    "bframes":"3",
    "b_pyramid":"strict",
    "pass":"!!REPLACE_PASS!!",
    "threads":"auto",
    "turbo":"1"

    Dieses wiederum nicht:

    Profil: Schnell und hässlich
     
    "subq":"1",
    "frameref":"1",
    "bframes":"0",
    "b_pyramid":"strict",
    "pass":"!!REPLACE_PASS!!",
    "threads":"auto",
    "no-8x8dct",
    "me":"dia",
    "partitions":"none",
    "no-weightb",
    "aq-mode":"0",
    "subme":"0",
    "trellis":"0",
    "weightp":"0",
    "turbo":"2"

    Ausschließen konnte ich dabei lediglich einen Zusammenhang mit der Turbo-Einstellung: Das erste Profil führt also auch zu Fehlern, wenn Turbo (wie im zweiten Profil) auf 2 gesetzt wird.

  • Die x264-Devs empfehlen einen Umstieg auf ffmpeg (da sie das Problem ja bei mencoder vermuten).
  • Es gibt Indizien (Bug-Report) dafür, dass der Fehler mit der Option 8x8dct zusammenhängt. Dies würde auch erklären, warum mein zweites Profil (das diese Option deaktiviert) durchläuft. Allerdings bezieht sich dieser Fehler auf auftretende Segfaults, die ich bisher noch nicht beobachten konnte.

Ich persönliche halte mich erstmal an die Lösung mit “nombtree”, habe aber nochmal eine Fehlermeldung bei mencoder eingereicht und bin gespannt, was die dort dazu meinen. Falls ihr selbst Erfahrungen damit gemacht habt oder ähnliche Probleme auch bei anderen Codes oder sogar anderen Programmen beobachtet habt, würde ich mich über Rückmeldungen freuen – die Vielzahl der Möglichkeiten macht es schwer, den Fehler allein aufzuspüren.

Images erstellen mit ddrescue

Einige Klassiker und ihre Schwächen

Nicht regelmäßig aber doch immer mal wieder ist man in der unschönen Situation, eine defekte CD, DVD oder gar Festplatte kopieren zu müssen. Wenn man ein Image des ganzen Mediums anlegen möchte, gibt es zunächst einmal das Tool dd. Von der Sicherung defekter Medien mit dd ist allerdings abzuraten: Zum einen ist dd nur sinnvoll zu verwenden, wenn verschiedene Parameter richtig gesetzt werden – ansonsten bricht dd beim ersten Fehler ab oder schreibt unbrauchbare Images. Zum anderen bietet dd aber schlicht einige Features nicht, die man bei der Datenrettung haben möchte: So lässt sich zwar angeben, wie viele Bytes jeweils in einem Rutsch gelesen werden sollen – wenn die Quelle aber defekte Sektoren hat, wird man diese Zahl eher gering ansetzen wollen. Dies führt aber dazu, dass der Auslesevorgang unnötig verlangsamt wird. Setzt man die Anzahl der gelesenen Bytes aber zu hoch, wird im Falle eines Lesefehlers auch gleiche diese (hohe) Anzahl an Bytes als defekt behandelt – es werden somit weniger Daten gerettet als möglich wäre. dd kann also nur schnell oder langsam – eine Unterscheidung zwischen defekten und lesbaren Sektoren gibt es nicht (ich bitte im Zweifelsfall um Verbesserung).

Eine Lösung ist das Programm dd_rescue (der Name des Paketes in den Paketquellen lautet ddrescue). Dieses Programm kopiert ein Medium, indem es zunächst große Blöcke einliest und kopiert – das ist schnell. Tritt nun ein Fehler auf, fällt dd_rescue in den Fehler-Modus zurück, in welchem lediglich kleine Blöcke gelesen werden – das ist langsamer, stellt aber sicher, dass nicht unnötig Daten als “defekt” verworfen werden. Treten über längere Zeit keine Fehler mehr auf, setzt dd_rescue die Blockgröße wieder hoch und beschleunigt somit die Datenrettung erneut. Damit eignet sich dd_rescue schon deutlich besser zur Rettung defekter Medien, ist aber – für sich genommen – noch nicht ganz optimal: Stellt man sich vor, dass eine Festplatte in der Mitte eine große Anzahl defekter Sektoren enthält, wird dd_rescue zunächst die lesbaren Daten am Anfang der Platte kopieren und dann viel Zeit dafür aufwenden, die defekten Sektoren in der Mitte im langsamen Fehler-Modus zu kopieren. Erst danach werden die lesbaren Daten am Ende der Platte kopiert. Es wird also viel Zeit dafür aufgewendet, möglicherweise ohnehin nicht mehr verwertbare Daten aus defekten Sektoren zu kopieren. Auf Grund der mechanischen Beanspruchung wird die Platte aber vielleicht schon beim aufwändigen und kleinteiligen Kopieren der defekten Sektoren endgültig das Zeitliche segnen. Die lesbaren Daten am Ende einer defekten Platte werden so unnötig gefährdet. Diese konzeptionelle Schwäche können erfahrene Nutzer eventuell umgehen, indem sie dd_rescue händisch mehrere Male laufen lassen und jeweils unterschiedliche Start-Positionen angeben oder die Rettung u.a. rückwärts laufen lassen. Auch zusätzliche Skripte wie dd_rhelp könnten das Verhalten von dd_rescue in dieser Hinsicht optimieren. Selbst der Autor von dd_rhelp empfiehlt aber inzwischen ein anderes Tool:

Antonio Diaz’ Programm ddrescue (ohne Unterstrich) aus dem Paket gddrescue ist eigentlich nichts anderes als eine konsequente Neukonzeption von dd_rescue, die die Funktionalität bietet, die dd_rescue nur in Ergänzung mit dem Skript dd_rhelp hatte: ddrescue liest zunächst das defekte Medium in großen Blöcken aus und schreibt die ausgelesenen Daten in das angegebene Ziel. Anders als dd_rescue liest ddrescue aber zunächst schnell über die defekten Sektoren hinweg und notiert das in einer Logdatei. Erst nachdem das ganze Medium so durchlaufen wurde, schaut sich ddrescue die defekten Sektoren erneut an: Es unterteilt die großen defekten Bereiche in mehrere kleine Bereiche und versucht dann diese kleinen “Häppchen” zu kopieren.

Durch dieses Vorgehen verwendet ddrescue zunächst seine Zeit darauf, die noch vorhandenen und lesbaren Daten eines Mediums zu retten. Erst am Ende dieses Vorgangs schaut sich ddrescue die womöglich ohnehin nicht mehr zu rettenden Daten an. Dieses Vorgehen kann gerade beim Kopieren defekter Festplatten ein enormer Vorteil sein: Jede Lesevorgang beansprucht die Mechanik zusätzlich und vermindert die Chance, wirklich die gesamte Festplatte auslesen zu können. Daher bietet es sich an, statt lange über defekte Sektoren zu rödeln zunächst die lesbaren Daten zu kopieren!

ddrescue hat aber noch andere Vorteile: Durch die Log-Datei kann eine Rettung jeder Zeit einfach abgebrochen und später fortgesetzt werden. Richtig genial (wenn auch sicher eher selten benötigt) ist dabei der Umstand, dass ddrescue auch ein funktionsfähiges Images aus mehreren defekten Datenträgern erstellen kann: Aus zwei DVDs mit identischem Inhalt kann ddrescue also ein funktionsfähiges Image erstellen! Auch im Alltag ist diese Funktion aber durchaus hilfreich: So kopiere ich meine defekten und verschmutzten DVDs zunächst mit ddrescue auf die Festplatte. Wenn dabei einige Datenbereiche nicht gelesen werden konnten, kann man seine DVD jetzt aus dem Laufwerk nehmen, (aggressiver) reinigen und es erneut versuchen: Durch die Logdatei “weiß” ddrescue genau, welche Daten beim ersten Durchlauf nicht kopiert werden konnten und schaut sich nur diese Bereiche auf der DVD erneut an. Bevor man seine DVD also mit Gewalt, Wasser und Schmierlappen bearbeitet: Erstmal das auslesen, was noch da ist und in einem zweiten Durchlauf die Lücken füllen.

Benutzung

ddrescue ist denkbar einfach zu benutzen. Beachten sollte man nur, dass man die Log-Datei bei jeder Verwendung selbst angeben muss. Gibt man keine Log-Datei an, wird auch keine angelegt und viele nützliche Features von ddrescue bleiben unzugänglich. Einen einfach Durchlauf startet man wie folgt:

sudo ddrescue -n /dev/sr0 rettungsimage.iso logdatei.log

/dev/sr0 ist dabei durch das zu rettende Laufwerk / Medium zu ersetzen. Das Image wird (naheliegend) in die Datei “rettungsimage.iso” geschrieben, das Log in “logdatei.log”. Dabei ist natürlich darauf zu achten, dass für jede Rettung eine eigene Logdatei verwendet wird.

Da ddrescue in seinem Log notiert, welche Blöcke defekt sind und welche defekten Blöcke nicht kopiert werden konnten, würde ddrescue bei einem weiteren Durchlauf erstmal gar nichts machen – im Log steht ja, dass die verbliebenen Blöcke nicht kopiert werden konnten. Um ddrescue zu einem neuen Versuch zu bewegen, müssen zunächst die defekten Sektoren als “ungetestet” markiert werden, um im Anschluss alle ungetesteten Blocks einem erneuten Test zu unterziehen:

sudo ddrescue -RT /dev/sr0 rettungsimage.iso logdatei.log

Jetzt wird ddrescue nur die vormals defekten Blöcke neu auslesen – und vielleicht retten können.

Fazit

Sicher lassen sich viele der beschriebenen Funktionen auch mit dd_rescue, dd_rhelp und sogar dd erreichen, wenn man die Tools gut zu bedienen weiß, viel Erfahrung im Umgang damit hat oder sich entsprechende Skripte geschrieben hat. ddrescue besticht aber dadurch, dass es all dies aus einer Hand bietet und keine (u.U. langsamen) Skript-Erweiterungen benötigt. Für eine einfache Datenrettung sind keine zusätzlichen Angaben durch den Benutzer nötig und die Überlegung, zunächst erstmal alle lesbaren Daten zu retten bevor man die defekten Sektoren auf Überlebende abklopft, ist sicher in sehr vielen Fällen die sinnvollere Strategie als das sequentielle Vorgehen.

Weitere Informationen

gibt es…

Hinweis
stfischr hat mich auf meine vorschnelle Editierung des Artikels hingewiesen, weswegen ich die ursprüngliche Version wiederhergestellt habe.
In der vorherigen Version des Artikels hatte ich behauptet, dass eine Rettung zunächst mit dem Schalter “-n” angestoßen werden sollte und erst in einem zweiten Durchgang darauf verzichtet werden könne. So wie sich die Sache mir jetzt darlegt, ist das nicht zutreffend und ein Durchlauf ohne irgendwelche Schalter erfüllt bereits seinen Zweck. An dieser Stelle nochmal besten Dank an stfischr für die Korrektur!

Archos Vision und Ubuntu

Der neue MP3-Player im Hause hört auf den schönen Namen “Archos Vision A14VG” und ist ein eher kleiner und leichter Vertreter seiner Zunft. Nachdem mir im Laden versichert wurde, dass sich das Gerät ganz normal ins Dateisystem einbindet, musste ich hier aber feststellen, dass genau das nicht der Fall ist.

Allerdings wurde das Gerät prinzipiell als Laufwerk erkannt, es gab einen neuen Eintrag unter “/dev/sdb” was darauf schließen ließ, dass etwas mit der Formatierung / Partitionierung des Players nicht stimmte. GParted bestätigte diese Vermutung, so dass ich mit dd eine Sicherheitskopie von /dev/sdb angefertigt und den Archos Vision mit Fat32 neu formatiert habe.

Wie erwartet legt das Gerät beim nächsten Start automatisch die erforderliche Verzeichnisruktur an, so dass in dieser Hinsicht keine Probleme entstehen. Danach wurde der Archos ohne Probleme eingebunden und ließ sich mit Musik bespielen.

Ich übernehme natürlich keine Gewähr dafür, dass Neuformatierung euren Player nicht in einen (sehr leichten) Briefbeschwerer verwandelt. Aber für mich war das Problem damit behoben.

Abstürzende Mediaplayer

Unter verschiedenen Linux-Distributionen kann es unter bestimmten Umständen dazu kommen, dass Mediaplayer abstürzen, wenn sie in den Vollbildmodus geschaltet werden. Teilweise passiert das sogar, wenn man das Fenster des Mediaplayer nur vergrößert.
Üblicherweise spuckt die Konsole eine Fehlermeldung wie diese aus:

BadAlloc (insufficient resources for operation)

Das Problem tritt anscheinend nur in Verbindung mit Compiz auf: Das Abschalten der Fenstereffekte kann das Problem also beheben. Wer auf wackelige Fenster & Co nicht verzichten möchte, kann das Problem beheben, indem er die Videoausgabe verändert.

Für den VLC:
Unter Extras->Einstellungen->Video die Option Ausgabe auf “X11-Videoausgabe” ändern.

Für Totem und viele mehr:
Programme, die auf GStreamer basieren (Totem etwa), lassen sich über das Programm gstreamer-properties konfigurieren. Im Reiter Video wählt man als Plugin im Bereich Default Output “X Window System (Kein XV)”.

Danach sollten die Videos in den genannten Programmen problemlos mit Compiz harmonieren.

Upload aus dem Kontext-Menü

Dieses Skript lädt die ausgewählten Dateien auf einen FTP Server. Angepasst werden müssen:
FTP-Server: Der zu nutzende FTP-Server
Server: Der gleiche Server – über HTTP
sowie
BENUTZERNAME (selbsterklärend).
Das Passwort wird jeweils vorher abgefragt. Wie zuvor wird das Paket zenity benötigt, ebenso das Paket wput.

#!/bin/sh
 
paths=$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
selected=$NAUTILUS_SCRIPT_SELECTED_URIS
cur=$NAUTILUS_SCRIPT_CURRENT_URI
 
if ! PASS=$(zenity --entry --hide-text --text "Bitte geben Sie das Passwort ein:" --title "Und das Passwort?"); then
  exit;
fi
 
for x in $selected
do
	name=$(echo $x|sed 's/file:\/\///')
	timestamp=$(date +%s.%N)
	#lastchar=$(echo $name|tail -c 5)
	nn=$(echo $name|awk -F/ '{print $NF}')
	output="$timestamp-$nn"
	wput "$name" ftp://BENUTZERNAME:$PASS@FTP-SERVER/bilder/$output
	error=$?
	uri=http://SERVER/bilder/$output
	if [ $error != 0 ]
	then	
		zenity --info --text "Fehler beim Hochladen der Datei $name" --title "Fehler"
	else
		zenity --info --text "Datei $name erfolgreich hochgeladen\nUrl:\t $uri" --title "Abgeschlossen"
	fi
 
done

Wie schon zuvor gilt: Abzulegen ist das Ganze in einer ausführbaren Datei im Verzeichnis ~/.gnome2/nautilus-scripts.

FourCC mit Nautilus-Skript ändern

#!/bin/sh
 
paths=$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
selected=$NAUTILUS_SCRIPT_SELECTED_URIS
cur=$NAUTILUS_SCRIPT_CURRENT_URI
 
fourcc=$(zenity --entry --text "Geben sie den neuen FOURCC ein")
 
for x in $selected
do
    name=$(echo $x|sed 's/file:\/\///')
    cfourcc -u $fourcc $name
done

Abzulegen ist das Ganze in einer ausführbaren Datei im Verzeichnis ~/.gnome2/nautilus-scripts. Benötigt werden die Pakete cfourcc und zenity