Compyblog

Dann gab es da noch den Fehler im Google-Telefon, der jede Eingabe ausführen wollte. Aufgefallen ist das dadurch, dass jemand eine Kurzmitteilung mit dem Wort 'reboot' verschicken wollte, und sich wundern durfte, warum sein Telefon genau den ausgeführt hat. Natürlich ohne Rückfrage. Dagegen ist der Fehler in iPhone und iPod Touch ja fast harmlos, der durchgeführt wird, wenn man sich auf einem der Geräte ein bestimmtes Video ansieht. Aber wie sagt man so schön über bestimmte Betrübssysteme aus dem Hause Kleinstweich: "Jeder Boot tut gut".

Die folgende Fehlermeldung wollte ich euch nicht vorenthalten:

Exception in thread "Java indexing" java.lang.IllegalArgumentException: Document path **path unknown** must be relative to **path unknown**

Ähm, ok. MAch ich doch glatt.

Irgendwas ist ja immer: Gerade hat sich mein Rechner eine ganze Weile beharrlich geweigert, mich am KDE anzumelden. Warum, weiß ich immer noch nicht. Dafür weniger einfach behebbar ist das Problem, dass die Suse-RPMs für den Firefox momentan wohl defekt sind. Jedenfalls deutet wohl die Meldung "Could not find compatible GRE between version 1.9.0 and 1.9.0." darauf hin, dass es ein Problem zwischen dem Firefox und dem Xulrunner gibt. Beide stammen aber aus dem entsprechenden Repository, so dass ich mal behaupte, es liegt nicht an mir. Aber immerhin läuft der 'offizielle' Firefox, den ich mir im Rahmen des Download Day gestern Abend noch heruntergeladen habe. Aber irgendwas ist ja immer.

Heute, pünktlich zu meinem Feierabend konnte ich etwas bewundern, was ich schon lange nicht mehr gesehen hatte: Einen Windows-Bluescreen. Glücklicherweise war es nicht mein Rechner, der mit diesem farbenfrohen Ereignis auf sich aufmerksam machen wollte, sondern der Rechner eines Kollegen, der darauf aufmerksam machen wollte, dass ein PAGE_FAULT_IN_NONPAGED_AREA (oder so ähnlich) aufgetreten sei. Den Bluescreen mit integriertem Speucherdump habe ich dann auch noch meine Aufwartung gemacht, aber ich bin dann doch nicht geblieben, bis die gesamten 2 GB an physischem Speicher auf der Festplatte verewigt waren. Wie überaus unschade, dass keiner meiner hiesigen Rechner solch blau beleuchtete Abstürze fabriziert.

Heute durfte ich für ein Problem rund um Windows den Ersatz-Hilfsadmin geben. Aus betrieblichen Gründen waren Hauptadmin und Hilfsadmin den Tag über beschäftigt, so dass ich mich um das Problem bemühen durfte, dass manche Kollegen bestimmte Netzlaufwerke nicht verbinden konnten bei der Anmeldung. 

Viel konnte ich dabei allerdings nicht helfen, weil sich recht schnell herausgestellt hatte, dass es sich wohl um ein Netzwerk- oder DNS-Problem handelte, bei dem ich ohne die Unterstützung der offiziellen Administratoren nicht weiterkommen konnte.

Windows-Probleme, ausgerechnet mir, der ich zuhause doch Windows komplett abgeschafft habe.

Armer, kranker Mac.

Im zweiten Teil des Podcasts für diese Woche beschäftige ich mich mit meinem Mac, der böse Festplattenprobleme entwickelt hat. Was genau, und warum ich darüber genau unbegeistert bin, erzähle ich in dieser Teilfolge. Musik gibt es dazu von Opened Paradise mit dem Titel 'Opened Paradise'.

Länge: 36:27, 33,3 MB.

Feedback hier oder bei Podster ist übrigens immer noch ausdrücklich erwünscht. Bei iTunes könnt ihr den ComPod inzwischen auch ganz einfach abonnieren.

Heute habe ich mal bei Gravis angerufen, um mich zu erkundigen, wie es meinem MacBook Pro geht. Ja, das Gerät sei in Berlin, und die bisherige Festplatte sei tatsächlich schadhaft, sagte mir der freundliche Gravis-Angestellte. Jetzt wartet mein Mac auf eine neue Festplatte, für die es keine konkrete Lieferfrist gibt. Wenn die Platte angekommen ist, wird es aber auch noch mehrere Tage dauern, bis das Gerät wieder zu mir zurückkommen kann.

Das heißt, ich werde noch (mindestens) eine Woche unter Windoofs leiden müssen. Nein, das gefällt mir nicht.

Seit Freitag ist mein MacBook Pro bei Gravis. Seitdem bin ich wieder unfreiwilliger Nutzer von Windows. Jetzt zeigt sich erst, wie schnell ich mich auf den Mac eingestellt hatte. Das fängt schon bei Kleinigkeiten an, wie der Tatsache, dass ich durch lange Listen immer per Strg-Pfeiltaste (was auf dem Mac der Kombo FN-Pfeiltaste=Bild hoch/Bild runter entpricht) navigieren will, oder mich schon mehrfach gewundert habe, warum Windows Dateien nicht kopiert hat. Aber auf Alt-C reagiert der Explorer nicht, im Gegensatz zum Mac, der mit Apfel-C sehr wohl etwas anfangen kann.

Auch in Sachen Podcast-Abo habe ich einen Rückschritt hinnehmen müssen, weil das Windows-iTunes meinen Mac-iPod zwar erkennt, aber nicht verwenden kann. Gut, dass ich meinen bisherigen Haupt-iPod weiter als solchen verwenden kann, auch wenn mir iTunes erstmal ein Software-Update verpasst hat. Scheinbar vertrögt sich der Rockbox-Bootloader nicht mit der iPod-Software 1.3.

Insgesamt vermisse ich meinen Lieblings-Mac doch schon ziemlich, und spiele mit dem Gedanken, dem MacBook, was ich hier noch habe (was aber weder vom RAM, noch von der Festplatte in der gleichen Liga spielt) demnächst mal einen Leoparden zu verpassen.

Okay, nach dem, was ich im Netz gerade gefunden habe, bin ich scared as hell.

Mein MacBookPro ist gerade zwei Mal hintereinander eingefroren beim Versuch, die neuesten Updates einzuspielen. Beimn Reboot im Verbose-Modus (Apfel-V sei Dank) kam dann die Meldung disk0s2: 0xe0030005 (UNDEFINED).

Okay, der Rechner ist dann weiter gestartet, aber laut diversen Seiten im Netz ist die Meldung ein Zeichen für ganz ernsthafte Probleme. Wie es aussieht, sollte ich mein Backup der Mac-Platte schnell noch aktualisieren, weil ich das schätzungsweise sehr dringend brauchen kann. Morgen habe ich nur leider überhaupt gar keine Zeit, aber übermorgen werde ich den Rechner dann ganz dringend zum Gravis tragen, damit er dort  möglichst schnell Hilfe bekommen kann.

Heute hat ein Kollege, der hier besser namenlos bleiben soll, es geschafft, größere Teile der Anwendungsentwicklung bei meinem Arbeitgeber lahmzulegen. Wie er das geschafft hat? Nun ja, er hat wohl irgend etwas an einer Datenbank-Tabelle tun wollen, und dabei gescheitert. Danach hat er dann DROP TABLE-Anweisungen abgesetzt, und damit die Tabelle effektiv beseitigt.

Nun wäre das im Prinzip kein großes Problem, gibt es doch mehrere Entwicklungsebenen, die die gleiche Tabelle vorhalten. Aus mir unbekanntem Grund hat der Kollege sich aber nicht nur an einer Ebene versucht, sondern an mindestens drei verschiedenen Ebenen. Ein Backup hat er zwar gemacht, aber aus unerfindlichen Gründen hat er verschiedene Ebenen in eine Datei geschrieben, und vor jedem Schreibvorgang die Datei gelöscht. Ja, die Daten sind weg. Nein, sie waren nicht übermäßig wichtig.

In unserem Projekt ist der Vorfall zuerst dadurch aufgefallen, dass unser Datenbank-User, den unsere Anwendung nutzt nicht mehr berechtigt war, besagte Tabelle zu lesen. Eine Weile später war der gesamte Datenbankzugriff gesperrt, als die Datenbänker versucht haben, noch soviel von den Daten wiederherzustellen, wie möglich war. Viel war das allerdings für die Tabelle, die wir verwenden, nicht. Hinterher war die Tabelle leer.

Ich habe mich aber zurückgehalten, und dem Kollegen nicht für seine gründliche Arbeit gratuliert, auch wenn das wohl angemessen gewesen wäre.

Ganz offensichtlich wurde meine neueste DLL-Änderung noch nicht auf dem Test-WTS installiert. Damit funktioniert die 'Fenster anordnen'-Funktionalität nicht, weder im Standalone-Fenster, noch unter dem Telefonie-Client. Das erste Fehler-Ticket zur Funktionalität unter dem Telefonie-Client habe ich ja noch beantwortet, aber beim zweiten Ticket zur Funktion ohne Telefonie ging es dann noch schneller, das abzuhaken. Einfach darauf verwiesen, dass das Problem die selbe Ursache hat, und als erledigt markiert. Hofentlich wird die aktualisierte DLL heute Nachmittag installiert, dann kann ich morgen gleich selbst testen, ob sie korrekt funktioniert.

Dieser Fehler war aber nicht mein schnellstgelöstes Ticket. Den Platz hält weiter ein Ticket, was ich selbst eingestellt hatte, um einen Fehler und dessen Lösung zu dokumentieren.

Mehr Hintergrundinformationen zu dem DLL-Problem gibt es hier und hier.

Nachdem vor einer Stunde mein DSL-Modem alle paar Sekunden neu synchronisiert hat, habe ich zu einer Notlösung gegriffen und einfach meinen Splitter gegen ein zweites Modell (was ich hier zufällig rumliegen hatte) ausgewechselt. Seitdem hat meine Fritz-Box nur noch ein Mal synchronisiert, und zwar nachdem ich die Kabel eingesteckt hatte. Hoffentlich ist meine DSL-Anbindung so etwas stabiler.

Okay, wie es aussieht, wirft Podshow beim Hochladen eienr MP3-Datei den USLT-Frame (=Unsynchronized lyric/text transcription) schlicht weg. Dabei scheint es auch egal zu sein, ob der Text offiziell deutsch oder englisch sein soll. Das finde ich nun ziemlich unpraktisch, um es mal höflich auszudrücken.

Nebenbei habe ich herausgefunden, dass iTunes die Shownotes für Podcasts in einem TDES-Frame parkt, den ich komischerweise nicht mit id3v2 für Linux schreiben kann. Ich vermute mal, dass es sich dabei um eine Title Description handeln könnte. Für meinen Touch-iPod wäre es mir aber sehr viel sympathischer, wenn iTunes einfach bei nicht vorhandenem oder leerem USLT den Inhalt des TDES auch als USLT-Frame ablegen würde. Dann könnte der Ersteller der Datei selbst bestimmen, ob er spezielle Notizen eintragen, oder iTunes im RSS-Feed mit den Daten versorgen will. Aber da müsste ich wahrscheinlich erstmal auf His Steveness einwirken.

Aus einem mir völlig unklaren Grund zeigt iTunes mir bei den drei Teilen der neuesten Podcastfolge keine Lyrics an. Das ist umso eigenartiger, als die Lyrics in den MP3-Dateien, die ich hochgeladen habe, noch enthalten sind. Ich versuche gerade herauszufinden, ob das Problem in iTunes oder irgendwo auf dem Server versteckt ist. Komischerweise funktioniert die Lyrics-Anzeige bei Chaosradio nämlich, und das auch auf dem iPod Touch.

Wer (wie ich) in diesen Tagen mal das Problem hat, dass sein BOINC für mehrere Minuten nicht reagiert, nachdem es neu gestartet wurde, sollte mal einen Blick in die diversen slots-Verzeichnisse werfen. Eventuell liegt da ein Verzeichnis 'minirosetta_database' rum. Beim Starten versucht der BOINC-Client das Verzeichnis und alle darin enthaltenen Dateien zu entsorgen, was wegen Read-Only-Attribut nicht funktioniert. Dummerweise meint der Client, für jede einzelne Datei erstmal 5 Sekunden warten zu müssen, bevor er einen weiteren (natürlich erfolglosen) Löschversuch unternimmt. Dadurch sind in meinem Fall 20 Minuten draufgegangen, in denen der BOINC Manager sich mit dem CoreClient nicht verbinden kann, und der CoreClient auch keine Tasks startet.

Verursacher des überflüssigen Verzeichnisses ist offensichtlich das Rosetta-Alpha-Projekt 'ralph@home'. Eine mögliche Lösung gibt es zwar auch schon, aber die ist heute erst eingecheckt worden, was bedeutet, dass sie weder in den BOINC-Versionen bis einschließlich 5.10.35, noch in der zur Zeit nicht offiziell freigegebenen Version 6.1.6 enthalten sein kann.

Eine manuelle Lösung besteht darin, erstmal zu schauen, ob auch nirgendwo ein rosetta Mini laufen sollte, den Client zu stoppen, und das störende Verzeichnis selbst zu löschen (oder zu verschieben). Danach startet BOINC dann auch wieder in der gewohnten Geschwindigkeit.