Rediscover Your Music on a Rant

The new Amarok 2.2.1 is great. Editing metadata finally seems not to disturb Amarok’s stability and doesn’t make the collection scanner choke and eat endless amounts of memory. And finally I can use it as the coolest „ambient“ music player again: Party mode is back. Err, okay it was back before – BUT: it finally works. Not to forget to mention its performance has vastly improved. To conclude these words: Yeah, it’s finally back on my desktop. Thank you, dear Amarok team. Great job!

But of course my increased usage puts the spot on all the bad things I start to discover. It’s my contribution to an ongoing rant on Amarok. There are some things I hate. And I really hate them. At least there seems to be no more show-stoppers now (or I didn’t discover them yet). Here is what I hate:

The Redesign of the Toolbar

That is really annoying. What did you guys think when you moved the playlist buttons to the middle? This makes in no way sense to me, because:

• I have my Amarok OSD in the top center of the screen – exactly where the buttons are. Changing the track covers the buttons. I fixed this by changing to the slim toolbar but I miss the big buttons then (which I hated when they first came up btw).
  
• It is waste of screen real estate. Come on? We are all going to have widescreens. And what do you guys do? You make a redesign targetted to good old 4:3 times: Less width, more height. The now-ultra-long progress bar looks ugly. The new layout has no place for important and/or useful buttons and info texts which could’ve been put there otherwise. In the end it’s totally counter-productive to the 3-column widescreen layout of Amarok. Please change that.
  

Strange Bugs

Many new bugs have been introduced, some old annoying bugs still remain:

• You cannot remove track numbers from the metadata. Once set, they will always remain there. Trying to remove them and tabbing to the next field simply make the numbers reappear. Clicking on „save“ while still in the field also doesn’t help – it’s just ignored and reset to the previous value. Does nobody use the metadata editor that it is treated such poorly?
• Using the metadata editor often results in Amarok to freeze for some seconds (the sound however continues to play, so it’s not that annoying).
• The playlist still has strange ideas of what should be grouped together and what not – most often when you remove a track from the playlist.
• ALL MY SONGS ARE ZERO SECONDS LONG?! No, I can’t believe that! BTW: The progress bar shows interesting timing information because of that. I first thought this was one of the hard-to-understand inventions of the developers before I realized that it is directly connected to the zero-second long tracks. See the above screenshots.
• Removing the current played track from the playlist makes Amarok jump to the start of the playlist instead of stepping to the „next“ song. It’s annoying. I step into that pitfall over and over again (removing a track and skipping to next song afterwards). Argh!
• I’m pretty clueless about how the replay-gain feature works. Where’s the automatic gain scanner and volume adjustment I so much loved in Amarok 1.4? I have the suspicion that this setting simply does nothing. My collection has replay-gain tags but songs come out of my speakers at surprisingly (and disturbing) different volume levels. I consider that non-working and thus a bug.

Final Words

You lucky guys: I’m still hoping. No wrong… I’ve got hope again. Seems you are finally concentrating on fixing bugs instead of inventing strange new features. Hmm, oh well – wrong again. Your new toolbar is a strange new invention. At least you fixed some annoying bugs. Yeah, probably in the end, perhaps, maybe you rock… Keen on the next release.

Basic Apache Performance Tips

Anyone mass-hosting virtual domains on apache knows the problems. Over the time I collected some basic and important performance tips which I want to give back to the community in aggregated form. Sorry, that I don’t remember all sources of information – so I will mention none. Google will help you. Here’s the list:

SecurePoint Appliances: Paßwort zurücksetzen

Aktuelle SecurePoint-Appliances bringen nicht mehr die Standard-Linux-Umgebung mit Befehlen wie „passwd“ und ähnlich mit sich. Hier das Paßwort zurückzusetzen gestaltet sich als schwierig; hinzukommt, daß die kleineren Appliances keinen Monitor- und Tastaturanschluß besitzen und zudem von CompactFlash booten. Der serielle Anschluß gibt zwar die Linux-Konsole aus, jedoch erst, wenn der Kernel läuft. Um die Paßwörter der Datenbank ändern zu können, muß man jedoch die Appliance im Restore-Mode booten – außer man möchte seine Konfiguration verlieren. In letzterem Fall kann man natürlich per Rescue-Image neu installieren.

Das wollte ich allerdings nicht (war relativ aufwändig und gewachsen). Der Trick war, die CF-Karte auszubauen und in einen USB-Kartenleser einzubauen. Als nächstes benötigt man VirtualBox. Man richtet nun in VirtualBox ein virtuelles Festplatten-Image mit Verweis auf ein echtes Device ein. Das geht allerdings nicht über die GUI. Deshalb wechselt man ins Verzeichnis ~/.VirtualBox/VDI und gibt nun dort folgenden Befehl ein:

VBoxManage internalcommands createrawvmdk -filename "SecurePointDisk1.vmdk" -rawdisk /dev/sdc -register

„/dev/sdc“ ist hier durch das Device der eingelegten CF-Karte zu ersetzen. Da dies in der Regel nur als „root“ zugreifbar ist, muß man entweder VirtualBox als root starten (würde ich nicht machen) oder den Eigentümer des Devices mittels „chown“ auf den eigenen User umbiegen (würde ich empfehlen). Wichtig ist: Keinesfalls die CF-Karte irgendwie mounten!

Nun legen wir eine virtuelle Maschine über die VirtualBox-GUI an. Dort verbinden wir den „Primary Master“ mit der eben angelegten „SecurePointDisk1″. Weiter dürfen keine IDE-Geräte verbunden werden – auch keine CD. Das Image booten wir nun. Nun geht es größtenteils nach Leitfaden von SecurePoint weiter:

Im Grub-Menü muß der zweite Menüpunkt („change configuration“) gewählt werden. Aber bitte noch nicht starten, sondern erst mit Tastendruck auf „e“ editieren. Am Ende der Kernelzeile müssen wir den Primary Master auf den Secondary Master umbiegen, da sich dieser nicht in VirtualBox verbinden läßt, SecurePoint hier aber die CF-Karte erwartet. Dazu ergänzen wir folgendes:

„ide0=0×1e8,0×3ee,14″ (brauchen wir gleich noch einmal)

Nun eine Leerzeile am Ende der Liste anfügen und in dieser Ctrl+X drücken. Das Image bootet nun. Der Name der zu bootenden Konfiguration ist „none“. Den Namen der anderen Konfiguration bitte notieren – wir brauchen ihn gleich. Wahrscheinlich heißt sie „wizard“. Nun die Konfiguration „none“ booten. Die Appliance ändert die Boot-Parameter und startet neu. Diesmal den ersten Grub-Menüpunkt booten – nicht vergessen, wieder den Parameter „ide0=…“ zu ergänzen.

Am Ende des Boot-Vorgangs dauert es ggf. ein paar Sekunden, bis die Netzwerk-Geräte konfiguriert sind – kurz warten also, es stört sonst die Eingabe. Jetzt mit User „admin“ und Paßwort „insecure“ anmelden. Man befindet sich nun auf der CLI.

Hier kann mit dem Befehl „config load“ die richtige Konfiguration geladen werden, das Paßwort nach Anleitung von SecurePoint mit „change user“ geändert werden (für „admin“) und die Konfiguration anschließend gespeichert („config save“) und als aktiv gesetzt („config set“) werden.

Jetzt kann die Appliance mit „reboot“ neu gebootet werden und wir lassen sie zum Test einmal komplett in VirtualBox hochfahren (bitte wieder „ide0=…“ ergänzen) und versuchen uns einzuloggen. Alles sollte nun wieder klappen und wir können VirtualBox beenden und die Karte wieder im Gerät einbauen.

Ruby-Scripte mittels FCGI unter Lighttpd ausführen

Im Netz habe ich nach einer längeren Google-Recherche endlich einen universellen FCGI-Wrapper für Ruby-Scripte gefunden. Meistens stößt man nur auf Rails-Lösungen, aber das war einfach Overkill in diesem Fall. Ich wollte einfach nur ein kleines Script, daß Query-Parameter einem Kunden zuordnet und mittels ActiveRecord in eine Tabelle schreibt. Anschließend sollte ein ActionMailer noch eine Mail versenden. Gestoßen bin ich letztenendes auf folgende Seite:

FastCGI Ruby dispatcher:

There was always Ruby on Rails, but I didn’t want an application server, just applications. To that end, I created a very lightweight FastCGI server that executes Ruby scripts referenced by lighttpd directly in a binding context that only imports the CGI object for the request. (Derrick Pallas)

Also genau das, was ich haben wollte. Funktionierte auch auf Anhieb prima. Aber nur der erste Aufruf liefert die Parameter wirklich an mein Script aus. Beim zweiten Aufruf bleibt der Parameter-Hash leer. Das ist der Codeschnippsel bisher:

#!/usr/bin/env ruby

puts cgi.header

require 'yaml'
require 'rubygems'
require 'active_record'
require 'action_mailer'

[...]

ActiveRecord::Base.logger = Logger.new(STDERR)
ActiveRecord::Base.colorize_logging = false

config = YAML.load_file('.../database.yml')
ActiveRecord::Base.establish_connection(config['...'])

params = cgi.params.select { |q,| %w{system keyword udh smstext absender time client}.include? q }
params = Hash[*params.flatten]

[...]

Einige Dinge hab ich jetzt mal bewußt weggelassen und nur das grundsätzliche Gerüst übergelassen. Sobald ich den Bug – falls es einer ist – gelöst habe, erscheint hier nochmal Feedback. Außerdem stellt sich mir noch die Frage, ob der FCGI-Wrapper so in dieser Weise wirklich einen Performance-Gewinn darstellt. Immerhin läd er die FCGI-Klasse im Voraus und hält einmal geöffnete Scripte als MMap-Objekte bereit. Der eigentliche Boot-Vorgang des Scripts (ActiveRecord initialisieren) wird aber jedes Mal ausgeführt. Hier ist Rails dann eben doch spezialisierter.

Mehrere Rails-Anwendungen pro VHost auf Lighttpd

Wer es schonmal versucht hat, Ruby on Rails unter Lighttpd zum Laufen zu bekommen, wird wissen, daß dies im Prinzip super einfach ist. Sobald man aber eine Rails-Anwendung in einem Unterverzeichnis der Domain laufen lassen möchte, bekommt man gewaltige Kopfschmerzen. Alle googlebaren Tricks führen entweder dazu, daß man beim Deployment Code ändern muß, böse Hacks in den Routen vornehmen muß oder an Stellen Hack’s einbaut, die nicht nötig sind.

Sogar Lighttpd selbst bringt einen solchen Hack mit, der beim Request das Prefix von der URL entfernt und dem Rails-Dispatcher so vorgauckelt, er würde im Hauptverzeichnis laufen. Dies führt zwar dazu, daß die Routen richtig erkannt werden, dafür muß bei allen Links in den Templates das Prefix manuell ergänzt werden. Kategorie: Buh! *thumbsdown* Die Idee war für mich gestorben.

Der nächste Hack führt eine Variable ein, die je nach Situation im Rails-Quellcode entweder gesetzt oder eben wieder gelöscht wird, um den Routen-Generator und den Routen-Parser zu überlisten. Auf so einen Blödsinn hatte ich keine Lust.

Nach dem Studium des Quellcodes fand ich heraus, daß es eine Variable RAILS_RELATIVE_URL_ROOT gibt, die man im Environment selbst setzen kann und die unter Apache sogar per Autodetect durch Rails selbst gesetzt wird. Weil Lighttpd aber etwas anders funktioniert, ist das dort nicht einsetzbar.

Anders gesprochen: Wenn ich also diese Variable händisch setze, müßte Rails ja damit klar kommen. Ist leider nicht so, Rails weiß überhaupt nichts davon, daß diese Variable gesetzt ist, wenn man den dokumentierten Weg für die Einstellungen des FCGI-Servers geht:

9 fastcgi.server = (
10   ".fcgi" => (
11     "localhost" => (
12       "min-procs" => 1,
13       "max-procs" => 5,
14       "socket" => approot + appname + "/tmp/lighttpd.socket",
15       "bin-path" => "/usr/bin/ruby " + approot + appname + "/public/dispatch.fcgi",
16       "bin-environment" => ( "RAILS_ENV" => "production", "RAILS_RELATIVE_URL_ROOT" => "/" + appname ))))

Dies ist wegen einer schlecht dokumentierten Eigenschaft des FCGI-Protokolls zum Scheitern verurteilt, da der Rails-FCGI-Dispatcher zum Zeitpunkt der Ausführung keinen Zugriff auf diese Variable mehr hat. Der Trick ist, die Variable aus dem „bin-environment“-Array herauszunehmen und mit dem Lighttpd-Modul „mod_setenv“ zu setzen. Der komplette Code-Schnippsel für die Rails-Konfiguration in Lighttpd sieht dann wie folgt aus:

5 server.error-handler-404 = "/" + appname + "/dispatch.fcgi"
6 alias.url = ( "/" + appname => approot + appname + "/public" )
7 index-file.names = ( "index.html", "dispatch.fcgi" )
8 setenv.add-environment = ( "RAILS_RELATIVE_URL_ROOT" => "/" + appname )
9 fastcgi.server = (
10   ".fcgi" => (
11     "localhost" => (
12       "min-procs" => 1,
13       "max-procs" => 5,
14       "socket" => approot + appname + "/tmp/lighttpd.socket",
15       "bin-path" => "/usr/bin/ruby " + approot + appname + "/public/dispatch.fcgi",
16       "bin-environment" => ( "RAILS_ENV" => "production" ))))

Den etwas umständlichen „bin-path“-Aufruf führe ich so aus, damit sich Grsec und PaX im Kernel eines Hardened-Linux nicht über Ausführungsrechte in einem potentiell unsicheren Verzeichnis beschweren. Andere Lighttpd-Rails-Beispiele im Netz starten hier direkt den FCGI-Dispatcher ohne den Interpreter explizit anzugeben. Die Variablen „approot“ und „appname“ sind vorher entsprechend zu besetzen. Auch „server.document-root“ sollte noch richtig gesetzt werden (passiert bei mir in einer seperaten Config-Datei und fehlt hier deshalb).

Aufgaben organisieren mit KMail

Durch den RSS-Feed der Anwendung basKet Note Pads bin ich auf das alternative Selbstorganisierungsprinzip Gettings Things Done (kurz GTD) gestoßen, das von David Allen erfunden wurde. Im Gegensatz zur Aufgabenorganisation nach Prioritäten folgt es einigen einfachen Prinzipien, durch das über das Schicksal einer Aufgabe schnell und effektiv entschieden wird, statt sich lange Gedanken über die Zuordnung zu einer Prioriät und Kategorie zu machen. Ich fand die Idee sehr interessant und habe mir zunächst das basKet-Demoarchiv dazu heruntergeladen. Da ich in der Firma allerdings Aufgaben größtenteils per E-Mail kommuniziere, habe ich mir überlegt, wie ich das GTD-Prinzip auf ein E-Mail-Programm abbilde – in meinem Fall auf KMail.

Neue Version des Last.fm Players 1.3.0.58

Nahezu für alle Platformen parallel ist vor einigen Tagen die neue Version 1.3.0.58 des Last.fm Players aufgetaucht. Die Version wartet auf mit einer aufgeräumteren Oberfläche, verbesserter Benutzerführung und einem bugfreieren Abspielen der Musikstreams – bedeutet: weniger Aussetzer, weniger Verbindungsprobleme, bessere Fehlermeldungen. Der Player bedient sich jetzt außerdem umfangreicher den deutschsprachigen Inhalten der Webseite und viele neue nützliche Funktionen verbergen sich hinter Drag&Drop-Aktionen und neuen Rechtsklick-Kontextmenüs. Nützlich finde ich außerdem, daß man jetzt mit einem Schieberegler wählen kann, ab welcher Spieldauer zwischen 50-100% ein Titel nun „gescrobbelt“ (also ins Profil eingetragen) werden soll. Leider könnte die Webseite nach wie vor einen Performance-Schub gebrauchen, aber der neue Player nimmt einem viel Klickerei durch die Webseite ab, die vorher nötig war. Dafür gibt es ein *thumbsup*.

Frets on Fire – voll geil

Neulich ist mir bei Zappi ein Artikel unter die Nase gekommen, der mich auf das Spiel Frets on Fire aufmerksam gemacht hat. Jetzt kam ich mal dazu, das auszuprobieren. Und was soll ich sagen? Voll lustig. Man klemmt sich die Tastatur kopfüber unter den Arm und greift mit den Fingern vorn an die F-Tasten und schon kann man E-Gittarren-Klänge raushauen. Das ganze ist grafisch ganz nett aufbereitet und wenn die Punktmultiplikatoren über den Bildschirm flashen, gibt es jedesmal ein Erfolgserlebnis. Noch stelle ich mich zwar etwas ungeschickt an, aber es fesselt. Ich kann das nur weiterempfehlen.

Wenn KDE nicht drucken möchte…

… und einen dabei nur mit folgender Fehlermeldung beglückt:

Der MIME-Typ application/postscript ist als Eingabeformat nicht unterstützt. (Dies kann z.B. eintreten, falls ein anderes Warteschlangensystem als CUPS und bei der Seitenauswahl ein anderes Format als PostScript verwendet wird.) Möchten Sie, dass KDE die Datei in ein unterstütztes Format umzuwandeln versucht?

dann sollte man einmal im Kontrollzentrum einen Blick in die Druckerprofile wagen. Dort ist ein Profil als Standard ausgewählt, dieses sollte man bearbeiten. So sieht das aus:

Bei mir war fehlerhafterweise z.B. der Enscript-Textfilter eingetragen (warum auch immer). Dieser akzeptiert nur bestimmte Eingabeformate, deshalb kann KDE den MIME-Typ application/postscript auch nicht hineinfüttern. Wenn man diesen entfernt, das ganze speichert und Ok klickt, sollte man danach in der Anwendung drucken können. Prüft ggf. noch einmal in den erweiterten Druckeinstellungen, ob dort der Filter noch da ist. Vielleicht habt ihr auch mehrere Profile eingerichtet und müßt nur das richtige auswählen und zum Standard machen.

MySQL server has gone away

Heute habe ich festgestellt, daß PHP (bzw. die Funktion mysql_error()) diesen Fehler ausgibt, wenn man eine Tabelle mit großen Blob-Daten füllen möchte – z.B. Bilder oder Downloads. Ob man große Daten besser im Dateisystem ablegt und nur den Dateinamen in der Tabelle, oder die Daten direkt in der Tabelle, sei mal dahingestellt. Fakt ist, daß der MySQL-Server es meist erlaubt, derlei große Queries zu verarbeiten. Das Problem ist eigentlich der Client, der per Default auf 1MB-Häppchen beschränkt ist. Um das zu beheben, sollte man in der my.cnf einfach max-allowed-packet höher setzen – präferabel auf irgendwas etwas größer als die PHP-Einstellung für max-post-size.

Hintergrund der Veranstaltung war eine Bilddatenbank, die die Originalbilder in der DB vorhält und für jede abgerufene Zoom-Stufe eine Cache-Kopie auf dem Dateisystem ablegt, die von einer Reinigungsroutine bei Nichtgebrauch irgendwann wieder weggeräumt wurde. Wurden die Originalbilder größer als 1MB, „has the MySQL server“ auf einmal „gone away“. Hat mir einige Kopfschmerzen bereitet, da die Fehlermeldung keinen Hinweis auf Query- oder Packet-Size gab.