Monthly Archives: January 2010

FF 3.6 behebt Flacker-Problem unter Opensuse 11.2

Posted on by

Viele haben ja die neue Opensuse 11.2-Version gelobt – u.a., weil der Firefox-Browser so gut in den KDE4-Desktop integriert wurde.

Meine Begeisterung hielt sich allerdings 2 Monate in Grenzen. Zwischen ein und derselben FF Version 3.5.x (z.B. 3.5.6) unter Opensuse 11.1 (x86_64) und Opensuse 11.2 (x86_64) gab/gibt es nämlich auch sehr unangenehme Unterschiede. Als Entwickler von Web-Formularen fiel mir besonders auf, dass wann immer DIVs mit “overflow:auto” im Spiele waren, der Seitenaufbau sehr imperformant und “wackelig” vonstatten ging. Z.T. unter Flackern und kurzzeitigem Auftauchen von in der Position versetzten Geisterbildern des DIV-Inhalts.

Eine frische Test-Installation von Opensuse 11.2 auf einer Maschine, auf der auf einer anderen Partition auch Opensuse 11.1 installiert war, ergab, dass das Phänomen seien Ursache allein in den unterschiedlichen Opensuse-Versionen hatte. Es war nicht Gnome, nicht KDE abhängig, tauchte für dieselbe FF-Version nicht unter Opensuse 11.1 auf und hatte auch nichts mit Grafikkartentreibern zu tun. Genauer habe ich es leider nicht analysieren können.

Verschwunden ist das Problem nun mit FF 3.6. Ganz generell ist diese Browserversion auch deutlich performanter geworden.

Tja, man sieht: Im Opensource-Geschäft gibt es Etliches, was einen als professionellen Anwender nur den Kopf schütteln läßt. Aber im Unterschied zu MS Windows hofft man hier nicht vergebens, und es lohnt sich immer wieder, Fehler an die Entwickler zu melden.

https://bugzilla.mozilla.org/show_bug.cgi?id=537392

Flackern beim Seitenwechsel im MS IE – Nachtrag

Posted on by

In einem der letzten Blog-Beiträge ging es um das Flackern des MS IE beim Seitenwechsel. Dort hatte ich zwei Tricks aufgeführt, mit denen man ohne Serveränderungen in manchen Fällen – leider nicht immer – eine Verbesserung herbeiführen kann.

In diesem Beitrag möchte ich kurz auf die Behandlung von MS IE-Flackern bei der Integration von Hintergrundsbildern für die gesamte Webseite eingehen. Da gibt es eine Geschichte, die es sehr verständlich macht, warum viele Webseiten-Entwickler den MS IE verfluchen.

Also – wie lädt man typischerweise Hintergrundsbilder für die gesamte HTML-Seite? Im -Tag per css-Anweisung. Typischerweise haben dann viele Seiten einer Domain dasselbe Hintergrundsbild und einen im wesentlichen gleichen Aufbau – es ändern sich beim Seitenwechsel nur ganz bestimmte BEreiche der Seite. Dann will man natürlich, dass ein Seitenwechsel sanft vor sich geht und der Hintergrund nicht flackert. Das Hintergrundsbild und alle anderen unveränderten Seitenelemente sollen beim Seitenwechsel statisch angezeigt, nicht neu aufgebaut oder neu geladen werden. Wozu gibt es schließlich den Browser-Cache …

Leider wird man aber beim MS IE in Abhängigkeit von der MS IE-Version feststellen, dass es dort bei Seitenwechseln, bei denen sich das Hintergrundsbild und wesentliche Anteile der Webseite (Grundaufbau) nicht ändern, dennoch zu Flackern kommt. Der Hintergrund wird kurz weiß, das Bild wird neu geladen. Das passiert ggf. nicht immer aber, doch sehr häufig. Wenn man genauer forscht, wird man feststellen, dass das Flackern besonders häufig oder immer bei Seiten auftaucht, bei denen zusätzlich zu den Hintergrundsbildern Flash-Elementen oder Javascript-Anteile vorkommen.

Deshalb sind ggf. zwei Tricks zu kombinieren, um das Flackern weg zu bekommen:

Fall 1) Es wird kein Javascript in der Webseite benutzt

Dann hilft es, das Hintergrundsbild nochmals (also zusätzlich zum Hintergrund im <BODY>) in einem DIV zu laden, das man per z-Index unter den gesamten übrigen Inhalt der Webseite legt. Hierzu benötigt man natürlich einen übergeordneten DIV-Container, in dem man das DIV für das Hintergrundsbild und ein DIV für den gesamten übrigen Inhalt absolut positioniert und übereinander legt.

Fall 2) Es wird Javascript benutzt, z.B. um Flash-Objekte in die Seite zu integrieren

Wir verwenden z.B. SWFObject und entsprechendes Javascript, um Flash zu integrieren. Es hat mich viele Tests gekostet, bis ich herausfand, dass allein schon das Einfügen eines Tags

<script type=”text/javascript”></script>

(also ohne jeden Code !) oder gar eines Tags

<script language=”JavaScript” src=”script/swfobject2.js” type=”text/JavaScript”></script>

im Header der HTML-Datei bereits ein Flackern beim Seitenwechsel zwischen Seiten mit Hintergrundsbildern auslöst. Für den Bruchteil einer Sekunde wird der Hintergrund weiß, das Bild wird neu geladen. Selbst wenn in der HTML-Seite keinerlei Javascript-Code ausgeführt wird. Unglaublich nicht ? Noch unglaublicher ist aber der Trick, der beim MS IE hilft:

Man kopiere den gesamten Script-Kram, soweit es die Logik der Seite zulässt, an das Ende des HTML-Codes und zwar unmittelbar vor das Ende des abschließenden </BODY>-Tags. Das ist zwar ungewöhnlich, aber kein Browser meckert einen formalen Fehler an. Und siehe da, auf einmal hört auch im MS IE das Flackern auf.

Das läßt tief blicken, in welcher Weise die Javascript-Engine in den MS IE integriert ist – Entschuldigung bei MS ist das ja eh eine Extrawurscht und nix Normales (JSCRIPT).

Leider kann es in einigen Fällen so sein, dass Javascript-Code zwingend vor dem Laden der übrigen HTML-Elemente ausgeführt werden muss. Dafür habe ich auch keine echte Lösung parat. Aber in vielen Fällen hilft der beschriebene Trick.

Überflüssig anzumerken, dass man den ganzen Quatsch so nicht braucht , wenn
man Firefox benutzt. Gott sei Dank hat ja nun Firefox zumindest in Deutschland dem MS IE den Rang abgelaufen.

Opensuse 11.2, Audio, Encoding, K3b

Posted on by

Nachdem mich

  • Schwierigkeiten mit der generellen Audio-Einrichtung unter Opensuse 11.2 (x86_64) mit einem Mix aus KDE3 und KDE4-Programmen
  • und zusätzliche Schwierigkeiten mit der “Ogg Vorbis”- und “MP3”-Kodierung unter K3b

auf einem Opensuse 11.2-System eines Bekannten kurzzeitig an den Rand einer Krise getrieben haben, hier ein paar Hinweise, die u.U. auch anderen helfen können:

1) Reagieren die diversen Audio-Programme überhaupt auf das richtige Laufwerk ?

Der Betreffende hatte 2 Laufwerke – einen DVD-Writer und ein normales DVD-Laufwerk. Blöderweise war der Writer unter “/dev/sr0” und das normale DVD-Laufwerk, das er regelmäßig zum CD- und DVD-Abspielen verwendet, unter “/dev/sr1” ansprechbar. Natürlich legt Opensuse bei der Installation “/dev/cdrom” und “/dev/dvd” aber auf “sr0” !

Und da – also bei /dev/sr0 – suchen dann fast alle KDE-Programme die Audio-CD – idiotischerweise auch dann, wenn man z.B. KSCD nach dem Einlegen einer CD in “/dev/sr1” über das Kontextmenü des Gerätemanagers startet. Na ja, es gibt ja intelligentere Programme, die da mehr checken – aber wenn man KDE verwenden will, dann muss man halt vorsorgen.

In Fall des Bekannten half im Rahmen der Tests zunächst ein Softlink

ln -s -f /dev/sr1 /dev/cdrom

Dann stellt man aber (erwartungsgemäß) fest, dass diese Linkzuordnung den nächsten Reboot nicht überlebt. Statt dessen ziehen Udev-Regeln bzgl. der Block-Devices. Um also die Zuordnungen permanent zu machen, muss man Dateien in “/etc/udev/rules.d” editieren. Im vorliegenden Fall ist die Datei

“70-persistent-cd.rules”

die richtige. Die Einträge für das fragliche System sehen z.B. wie folgt aus:

# CDDVDW_SH-S223F (pci-0000:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”cdrom1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”cdrw”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”dvd1″, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-0:0:0:0″, SYMLINK+=”dvdrw”, ENV{GENERATED}=”1″

# DVD-ROM_SH-D163B (pci-0000:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-1:0:0:0″, SYMLINK+=”cdrom”, ENV{GENERATED}=”1″
SUBSYSTEM==”block”, ENV{ID_CDROM}==”?*”, ENV{ID_PATH}==”pci-0000:00:1f.2-scsi-1:0:0:0″, SYMLINK+=”dvd”, ENV{GENERATED}=”1″

Ferner gibt es andere Programme (wie z.B. xine), die ihre eigenen (nicht über KDE zentralisierten) Einstellungen für das Audio- oder Video-Laufwerk etc. haben wollen. Ggf. dort direkt das richtige Laufwerk einstellen.

Auch in den KDE 4 “System Settings” gilt es, unter “Erweitert-> Audio CD” die richtigen Einstellungen zu treffen.

2) Umstellung auf Pakete aus dem Packman-Repository

Wenn man mit MP3 arbeiten will, müssen Lame und zugehörige Bibliotheken installiert sein. Ferner lohnt es sich, viele der Audio-Programme vom Packman-Repository zu installieren. Mehr sage ich nicht – wegen der Rechte muss jeder selber wissen, was er tut und wie er zu einer entsprechenden Lizenz kommt.

Ich selbst nehme eh’ immer “Ogg Vorbis” und fahre sehr gut damit. Aber wenn es denn halt MP3 sein soll, dann ist die Installation der Packman-Programme angesagt !

Wenn man gleich alles Wesentliche auf einen Streich umstellen will,
dann zeige man sich in Yast das Repository an – und zwar über den Reiter “Anzeigen” und dort unter “Installationsquellen”. Nach einem Klick auf das Packman Repository Icon in der Liste findet man im oberen rechten Yast-Bereich eine gelb markierte Option “Switch system packages to the version in this repository”. Ein Klick auf diese Option vereinfacht die Paket-Umstellung erheblich und markiert alle relevanten Programme für ein Update aus dem Packman Repository. In gewisser Weise stellt dieses Vorgehen dann auch eine Konsistenz der Packman Pakete untereinander her!

Essentiell sind in jedem Fall die libxine1-Bibliotheken, im Besonderen die “libxine1-codecs”.

3) Ist der User den richtigen Gruppen zugeordnet?

Als nächstes sollte man untersuchen, ob der betreffende User den richtigen Gruppen zugeordnet ist. Unter Opensuse 11.2 fehlt ggf. die Zuordnung zu den Gruppen “audio” und “cdrom”. Dies war im vorliegenden Fall eine Mindestvoraussetzung, um ältere KDE3-Programme wie KSCD unter Opensuse 11.2 zum Arbeiten – sprich zum Abspielen von Audio-CDs zu bewegen.

Natürlich müssen in solchen Programmen – soweit einstellbar – auch die Optionen für “Digitale Extraction” und das richtige Soundsystem gesetzt sein.

Gerüchten zufolge soll bei einem Einsatz anderer älterer KDE3-Programme auch die Zuordnung zur Gruppe “disk” helfen. (Ich glaube das aber nicht – außerdem wären mir bei Letzterem auf einem Mehrbenutzersystem die Risiken zu groß).

Das ganze Thema mit fehlenden Rechten gab es beim ersten Release von Opensuse 11.1 schon mal. Nach meiner Erfahrung lohnt es sich jedenfalls, bei Problemen im Audio-Bereich mal versuchsweise die Rechte umzusetzen und danach systematisch das Minimum der notwendigen Rechten zu identifizieren. Wer weiss, was alles in Opensuse 11.2 so passiert – ich habe bei Paket-Updates aus dem Opensuse Update-Repository jedenfalls schon ein paar Mal die Meldung gesehen, dass Verzeichnis-Rechte umgesetzt wurden.

Achtung: Nach dem Umsetzen userspezifischer Rechte für Systemgruppen zur Sicherheit neu booten.

Zwischenergebnis

So, hat man an diesen drei Fronten alles in Ordnung, dann laufen normalerweise die üblichen Audio-Progrämmchen KSCD (KDE3 und KDE 4), amarok 1.4 (Packman), amarok (2.x für KDE 4 – ab KDE 4.4 auch mit Equalizer !), xmms, asunder, sound juicer, MPlayer, Kaffeine (KDE 3), KAudioCreator (KDE 3), Audex, etc. und werkeln so vor sich hin – sowohl beim Abspielen der Audio CDs als auch bei der Extraktion mit anschließender Enkodierung in “Ogg Vorbis”, MP3 und anderen Formaten.

4) Enkodierung mit Kb3

K3b stellt eine sehr einheitliche und praktische Oberfläche nicht für das Brennen von CDs sondern auch zum Auslesen derselben und der Umwandlung der Tonspuren in digitale Audioformate zur Verfügung. Unter diesem dach kann man zudem auf einfache Weise die wichtigsten Einstellungen der Enkoder in sehr übersichtlicher Weise vornehmen.

Ein erster Test mit K3b aus dem Packman Repository zeigt denn auch, dass ein Auslesen und ein Enkodieren unter Ogg Vorbis anstandslos funktionieren. Ganz anders sieht es aus, wenn man eine MP3-Enkodierung vornhmen will. Hier erschien auf dem System meines Bekannten eine Meldung der Art

“command failed: lame -h –tt %t –ta %a –tl %m –ty –tc – %f”

Bei anderen Einstellungen des Enkoders und der sonstigen Ausleseparameter (z.B. Ziel-Verzeichnisse) können die lame-Optionen auch anders aussehen. Also das Problem trieb mich bald zum Wahnsinn, nachdem händische Kodierungsversuche per Kommandozeile, aber auch KAudioCreator, Audex
und Asunder problemlos arbeiteten. Allein konnte ich das Problem auch nicht lösen; die Lösung fand ich dann in einem Forum unter der Adresse

http://www.linuxquestions.org/questions/slackware-14/having-some-trouble-w-k3b-and-encoding-with-lame-640386/

Ich gebe einfach die Hinweise des Forumteilnehmers “lennoni” wieder, die unter K3b für Opensuse 11.2 (x86_64) auch zum Erfolg führten. Allerdings muss man gegenüber dem Vorschlag des Forums eine Modifikation vornehmen :

a) Start k3b and insert audio CD (allow cddb lookup)
b) click “Start Ripping”
c) select MP3 (lame) as filetype
d) Click the config cog beside this
e) highlight the Mp3 (lame) and click edit
f) check your command line (mine is lame -h -V2 –tt %t –tn %n –ta %a –tl %m –ty %y –tc %c – %f )

[ Original suggestion of lennoni: g)check both “swap byte order” and “write wave header”, then OK, OK]

g) Suggestion of RM [03.01.2010]: check “write wave header”, only, then OK, OK !
(Hint: MP3-files with “swapped byte order” will not be playable in most MP3 players ! My K3b worked, i.e. extracted and encoded without a checked “swap byte order”. )

h) Save settings!! (RM-Hinweis: Über ein kleines Icon links unten in K3b !)
i) Start ripping

Yeah, great lennoni ! Thx, thx !

Dann geht’s auch mit MP3. Auch, wenn man das als normaler Linux-Sterblicher gar nicht braucht ! Blöd allerdings, wenn der mobile Player für die Hosentasche oder das neue Handy mit Gigabytes an Audiospeicher kein “Ogg Vorbis” versteht. Aber sowas kauft ein Linuxer ja gar nicht …..

Nachtrag 04.01.2010

Musste mir heute nochmal genauer angesehen, wie Amarok die MP3-Dateien verarbeitet, die mit den obigen Einstellungen von K3b (“write wave header”) erzeugt wurden. Dabei musste ich leider feststellen, dass die Tracknr. nicht richtig erkannt wurde. Das kann man zwar über die Metadaten der erfassten Dateien manuell korrigieren. Grundsätzlich ist die Reaktion von Amarok aber ein Hinweis darauf, dass K3b offenbar Probleme damit hat die CDDB-Daten bzw. CD-Daten korrekt zu verarbeiten und weiterzureichen. Möglicherweise hängt damit auch der Fehler zusammen, der nach dem Lame-Aufruf durch K3b auftritt. Das ist jedenfalls eine Fehlermeldung an die K3b-Entwickler wert.