Update zum Navigon Mobile Navigator …

Wie schon auf YouTube als auch hier im Blog kommentiert: bei Navigons Mobile Navigator for Android kann man zwischen der aktuellen Geschwindigkeit, der Entfernung und der voraussichtlichen Ankunftszeit umschalten.

Wie in anderen Navigationssystemen diese Daten gleichzeitig angezeigt zu bekommen, zusätzlich z. B. auch noch die bisherige Durchschnittsgeschwindigkeit, sieht Navigon leider offenbar nicht vor. Dafür implementierte man eine Umschaltung, die man aber nach dem – per »OK« zu bestätigenden – Warnhinweis beim Programmstart unterwegs gar nicht nutzen sollte …
Ich bin noch immer etwas enttäuscht, denn diese Funktionen bot schon der MN4 für PocketPCs vor vielen Jahren; weder waren die Displays jener Geräte größer noch die Prozessoren damals leistungsfähiger. Mir bleibt daher absolut unverständlich, warum Navigon diese Informationen einerseits per Default verbirgt und andererseits nur so umständlich – und latent gefährlich – doch zur Verfügung stellt. Bei Tempo 130 die schmale Zeile auf dem Display zu treffen, ist alles andere als ergonomisch oder einfach :(

Von Pads, Androiden und Restriktionen

Das iPad ist ja nun da (über’m Großen Teich, einige Exemplare sind auch schon nach D, ja sogar OWL, unterwegs), und wenn vielleicht auch nicht für südlich-warme Gefilde geeignet – Betriebstemperatur 0 bis 35° Celsius –, so definitiv ein spannendes Gerät insofern, als es, ähnlich wie das iPhone mit seiner (späteren) Kombination von GPS, Lagesensoren, Touchscreen und schnellem Mobilfunk, eine neue Geräteklasse begründet. Nichts umwerfend Neues – die Technik dahinter konnte man schon vor 5+ Jahren zusammentragen und -stöpseln – aber als Massenmarktgerät eben doch neu und sogar – bei allen Apple-induzierten Einschränkungen – latent innovativ.
Und so wird es auch immer wieder ein Thema auf twitter; wobei hier der Auslöser ja das IPhone war:

@crieger 2010-04-07 22:36:08: Bekommt am Freitag Abend ein #iPhone ausgehändigt, ob mich das vom Blackberry wegbringt?

 

@icedsoul 2010-04-07 22:37:20: @crieger hassu fieber? :-b

 

@crieger 2010-04-07 22:38:59: @icedsoul wegen des blackberrys?

 

@icedsoul 2010-04-07 22:39:52: @crieger ne des iphones wegen du nase :-) warst doch immer so anti.

 

@crieger 2010-04-07 22:41:20: @icedsoul Bin ich immer noch, bekomme es 14 tage für ein Projekt. Intensive Recherche etc… Mal gucken glaube nicht, dass es mich überzeugt

 

@icedsoul 2010-04-07 23:14:11: @crieger :-) sure…

 

@crieger 2010-04-07 23:19:03: @icedsoul Ich werde berichten und bloggen ;) Jeden Tag ein Post :)

 

@icedsoul 2010-04-07 23:20:15: @crieger bin gespannt. ich seh mich jedenfalls nciht mehr bei handys mit tasten :-)

 

@crieger 2010-04-07 23:24:00: @icedsoul Ich hatte mal eines ohne Tasten, von samsung aber es geht nichts über ne Blackberry Qwertz ;)

 

@icedsoul 2010-04-07 23:26:01: @crieger ja da war auch das problem. iphon hat einfach das einzig gute touchscreen… der rest der geräte stinkt halt :-)

 

@_refugee_ 2010-04-07 23:43:51: @icedsoul Ey, hömma… Willste mein Telefon beleidigen oder was? Komm da gleich ma rüba. Diese Multitaskingverweigerer… Ts, ts, ts… ;-)

 

@icedsoul 2010-04-07 23:46:27: @_refugee_ hab mich schon gefragt warum das so lange dauert :-) @wusel schläft wohl schon…

 

@_refugee_ 2010-04-07 23:52:54: @icedsoul Der @wusel hat es vermutlich nicht mitbekommen. Apropos mitbekommen – http://twitpic.com/1dp3cz den hattest Du gesehen, oder? :-)

 

@icedsoul 2010-04-08 00:21:13: @_refugee_ jip :-)

 

@tbals 2010-04-08 01:12:22: @_refugee_ @icedsoul #Multitasking waren doch diese #features wie 50% Akkulaufzeit, langsamen Apps und einer Load von 1.0 beim idlen? ;-)

 

@wusel 2010-04-08 01:20:32: @icedsoul Extensiver Minimalismus ist nicht von Vorteil. #nureinetaste Aber mit dem iBrick bist Du schon korrekt bedient ;)

 

@wusel 2010-04-08 01:23:19: @icedsoul Ich freue mich auf den ersten iPad-Kontakt am Dienstag ;) und ansonsten auf #ADAM – wenn er denn mal kommt. ADAM, Pad done right?

 

@wusel 2010-04-08 01:24:17: (Naja, mit 1024×600 ist der Screen wieder zu klein. Irgendwas ist ja immer :( #ADAM)

 

@_refugee_ 2010-04-08 08:19:16: @wusel Ich glaube heute abend ist auch iPad-Streicheln im Merlin-Store angesagt. Ein Android-Tablet mit den Restriktionen von Android? Nee.

 

@wusel 2010-04-08 09:45:46: @_refugee_ Welche “Restriktionen von Android” meinst Du? Die fehlende Store-Pflicht? Den Layer aus Drecks-Java, der Apps erst ermöglicht?

 

@_refugee_ 2010-04-08 11:57:57: @wusel Mehr so die andere Crux, die man derzeit noch mit Telefonen durchleidet – aktuelle Versionen gibt’s nicht oder nur sehr spät…

 

@_refugee_ 2010-04-08 11:58:39: @wusel Von daher fänd ich Tablets mit MeeGo spannender. Wobei sich die Qualität da noch zeigen muß.

 

@wusel 2010-04-08 12:00:05: @_refugee_ Wobei Du da auch keine Aktualisierungsgarantie hast – siehe N900-Maemo-Version f. N810 oder kein MeeGo-Release für N900 …

 

@_refugee_ 2010-04-08 12:12:52: @wusel Da kannst Du es Dir aber zur Not “selbst” machen. Und Maemo5 auf dem N810 ohne HW-Gfx-Beschleunigung macht aber auch keinen Sinn.

 

@wusel 2010-04-08 12:16:32: @_refugee_ Dann ist der Punkt aber müßig :) Das Magic auf Eclair/2.0 zu bringen, ist ja auch “möglich”: http://is.gd/bjSeB … Dito Hero.

 
Da sich twitter mit 140 Zeichen nicht wirklich für Erklärungen eignet und auch Dienste wie tweetlonger nicht wiklich helfen, fasse ich meine ablehnenden Punkte bzgl. iPad im Folgenden nochmals zusammen und gebe ferner zum Besten, was ich von einem Pad erwarte: Negativ an Apples Gerät finde ich den Verzicht auf Standardschnittstellen wie (micro-)SD, USB, eine (besser: zwei) Kamera(s), die Verwendung eines neuen SIM-Formates beim 3G-Modell (sodaß keine normalen SIMs verwendet werden können) sowie den niedrig auflösenden 4:3-Bildschirm — neben der aggressiven Politik Apples, die Hardware mit iTunes zu verdongeln. iTunes mag ja toll sein, ist aber ein Fremdkörper im Microsoft-Kosmos und für Linux gleich gar nicht verfügbar (davon abgesehen, daß über den Brückenkopf iTunes Apple ja auch schon mal ungefragt weitere Software auf Windowsystemen installiert, durchaus also als Trojanische Software angesehen werden darf). In meinem Haushalt existiert nur ein natives Windowssystem, ein Netbook mit XP Home. Und da möchte ich bestimmt nicht Apple Rechte drauf einräumen, willkürlich Software zu installieren …
Ein weiteres Problem für mich, wenn vielleicht nicht praktisch so zumindest mental, ist die Zwangsbindung an Apples Moralvorstellungen und fragwürdige Behandlung von Anwendungen in deren AppStore. Als Nordeuropäer sind mir barbusige Menschen weder unbekannt noch ein Greuel, vor deren Anblick im Inhalt eines Magazins muß ich nicht durch kalifornische-verklemmte Späthippies geschützt werden. Und auch die chronische Nachzensur einer App, die für Tage bis Wochen verkauft wurde und dann aus dem Store entfernt wurde – trotz vorheriger aktiver Überprüfung durch Apple vor der Einstellung in den Store –, weil sie innovativ mehr Komfort ermöglichte als es andere 08/15-Apps taten, ist für mich untragbar. Und das sind ja keine Einzelfälle, Apple ist der große Diktator in der von Apple geschaffenen iPod/iPhone/iPad-Welt, belohnt wird der – überteuerte – Preise zahlende Kunde mit Zwangsbindungen an bestimmte Mobilfunkanbieter, die hohe Mobiltarife für die Apple-Hardware verlangen müssen, um Apples Umsatzbeteiligung zu verdienen — und natürlich erstklassigem Eye-Candy. Details wie fehlende Unterstützung von MMS – ein weiterer, von Apple ignorierter, herstellerübergreifender Standard – oder fehlendem Cut&Paste-Support sind keine Mankos, sondern … Features.
Aber genug gelästert über Apple — die mit dem iPad sicherlich wieder Erfolg haben werden. Ich suche sowas wie ein iPad schon lange; ein einfach zu bedienendes Gerät für die Couch, worüber z. B. die Hausautomatisation angesprochen werden kann, womit man bequem surfen kann – alle aktuellen Inhalte eingeschlossen, d. h. also heute auch Videos in H.264 kodiert und HD-Auflösung, eingepackt in Flash –, vielleicht spielen (meine Jüngste mag z. B. gerne Jewels oder Mahjongg) — und unterwegs darf das Pad dann als mobile Glotze dienen, gespeist z. B. von einem – möglichst nicht umgerenderten – TV-Mitschnitt (MPEG-2- oder H.264-Transportstream). Seit Sommer 2008 haben wir ein Netbook der 1. Generation (MSI U100 in der Medion-Variante) im Wohnzimmer für diese Aufgaben, alle Geräte davor, mein Nokia N810 eingeschlossen, hatten zu viele Einschränkungen, um wirklich nützlich zu sein. Doch auch das Atom-Notbook ohne GPU-Beschleunigung für HD-Inhalte ist nicht mehr auf der Höhe; der HD-Offensive der Videoplattformen hat die Hardware nur Rechenleistung aus dem Jahr 2000 entgegenzusetzen — also letztlich nix.
Ein anderes Thema ist eine Couch-taugliche Benutzeroberfläche; die Convertibles waren da ein Fingerzeig in die richtige Richtung aus meiner Sicht, allerdings ist es imho schwierig, eine auf Tastatur- und Maus-Bedienung ausgerichtete UI nur mit dem Finger zu bedienen; anders herum, auf einer »Finger-UI« mit Maus/Trackpad und Tastatur rumzumachen, ist tendentiell einfacher (sieht man von Multitouchgesten, dem neuesten Schrei, mal ab) … Insofern setze ich große Hoffnungen in Android als Pad-Oberfläche, den zumindest auf dem Telefon klappt das ganz gut. Ein Problem auf Android-Telefonen aus meiner Sicht – ich spreche hier von HTC Magic und Motorola Milestone – ist allerdings das, was man eigentlich als Vorteil erwarten würde: Multitasking. Für mich seit Amiga-Zeiten eine Grundvoraussetzung zum Arbeiten, bringt die Kombination von fehlendem oder unzureichendem Resourcenmanagement und fehlender OS-Unterstützung des Nutzers in der Kontrolle mehrerer gleichzeitg laufender Anwendungen das von @tbals genannte Benutzerempfingen: »50% Akkulaufzeit und langsame Apps«. Auch diese Probleme hatte schon mein N810 — und mit Flash wird das insbesondere auf Android-Pads spannend werden, denn mittlerweile surfe ich sogar auf dem recht fetten Desktop bzw. Laptop nur noch mit dem NoFlash-Addon (zusätzlich zu AdBlockPlus natürlich), da ohne schon bei wenigen offenen Tabs die gesammte Rechenleistung eines CPU-Cores verbraten wird.
Ich hoffe daher auf Geräte wie das ADAM, wo zielgerichtete Hardware (Dual-Core ARM, HD-Decoding-Hardware) mit einer Infrastruktur (Android-OS plus – hoffentlich – Android Market) gekoppelt wird, die einerseits den Massenmarkt anspricht, dank aber der Option, Android-Programme auch von beliebigen URLs zu installieren, den Nutzer nicht zwingend an den »Geschmack« des Shopanbieters kettet. Und dank der weiteren Schnittstellen – 2x USB, microSD – kann ich den Speicher erweitern, andere Peripherie anschließen und werde entsprechend auch Filme, Musik vom externen Speicher abspielen können — ohne an einen PC gehen zu müssen und diese erst auf mein Pad zu »synchronisieren«. Kurz: ich habe die Freiheit, das – mein – Gerät zu nutzen, wie ich möchte, andererseits eine Plattform, für die auch Entwickler Programme, teils sicher gegen Entgeld, bereitstellen.
Allerdings, und das hat oben @_refugee_ ja angesprochen, krankt Android aktuell unter einem indiskutablen Versionswirrwarr; anders als Apple, die ja der einzige Hersteller für Hard- und Software für ihre Geräte sind, leidet Googles offene Plattform Android unter der Vielfalt von unterschiedlichen Geräten. Und offensichtlich hat Google – wie seinerzeit Microsoft – übersehen, daß für den Erfolg einer OS-Plattform auch die Updatepolitik ausschlaggebend ist. Das aktuelle Problem faßt Golem.de schön zusammen:

Als Google Android vorstellte, war nicht abzusehen, dass die Gerätebesitzer das gleiche Schicksal ereilen würde wie Käufer von Windows-Mobile-Smartphones. Doch genau das ist eingetreten. Beide Käufergruppen halten bald veraltete Geräte in den Händen, denn es mangelt an Firmwareupgrades.
In Kürze liefert Motorola für das Milestone in Deutschland das lang erwartete Update auf Android 2.1 aus. Damit ist das Milestone eines der wenigen Android-Smartphones in Deutschland, für das die aktuelle Android-Version offiziell angeboten wird. Ansonsten verharren die meisten am Markt befindlichen Android-Geräte bei den Versionen 1.5 oder 1.6 von Android. Neuere Versionen bieten die Gerätehersteller oder die Netzbetreiber einfach nicht an.

 

Lt. Golem bedeutete dies auch, daß Anwender »von entscheidenden Verbesserungen ausgeschlossen« würden; persönlich konnte ich das bei meinem noch auf 1.5 verharrenden Magic (1.6 ist verfügbar, aber da ich mittlerweile zwingend den root-Zugriff auf mein Telefon haben möchte, um Datenübertragung per Bluetooth und Screenshots machen zu können – beides unter 1.5 ohne root nicht möglich, und wg. Screenshots habe ich mittlerweile auch mein Milestone mit 2.0 gerootet –, warte ich noch) noch nicht feststellen, habe aber auch keinen Grund, Golems Angaben in Zweifel zu ziehen.
Angeblich habe Google mittlerweile das Problem als solches auch erkannt; leider allerdings spürt man davon bislang nichts und so haben weiter diejenigen Android-Nutzer das Nachsehen, die brav darauf warten, daß Ihr Vertragspartner – i. d. R. der Mobilfunkanbieter – oder zumindest der Hersteller ihnen zeitnah auch die neusten Produktverbesserungen zukommen läßt. Beim Milestone warte ich nicht länger auf o2, und auch beim Magic werde ich wohl auf einen zusammengemixten Image-Cocktail setzen, sobald die gesamte Hardware unterstützt wird …
Ein interessantes Detail am Rande kam hierzu von @o2myhandy via twitter:

@ralfludwig Danke fürs Feedback – hat nichts mit Branding zu tun. Jedes Android Update muss seperat von Google abgesegnet werden

 
Demnach ist einer der bremsendem Spieler hier Google selbst; ähnlich wie Apple ist also auch Google der zentrale Strippenzieher im geschaffenen OS-Universum. Bedenklich, zumal ja Android auf sehr viel Code aus der GPL-/OpenSource-Welt fußt …

Der Etikettenschwindel mit dem Plus: CI+ und HD+

Ich hab’s zugegebenermaßen erst für einen Aprilscherz gehalten, aber augenscheinlich ist der Golem-Bericht keiner (lokale Hervorhebung):

Herausgekommen ist bei den nun konkretisierten Plänen eine Dreiteilung nach der Art des Empfangsgeräts. Ältere Receiver, die über das 99 Euro teure Legacy-Modul von HD+ für die Verschlüsselung der Privatsender nachgerüstet werden können, dürfen Sendungen aufzeichnen und Timeshift benutzen. Ein Vorspulen bei der Wiedergabe von HD+-Inhalten ist verboten. Das gilt auch für die inzwischen verfügbaren und von Elektronikmärkten stark beworbenen “HD+-Receiver”: Aufnehmen und Timeshift ist erlaubt, Vorspulen nicht. Der schnelle Vorlauf bei der Wiedergabe bleibt auch ganz neuen Geräten verwehrt, die den Slot “CI Plus” enthalten. Dabei gibt es dann auch nichts vorzuspulen: Eine Aufnahme von HD+ ist auf diesen Geräten gleich ganz verboten.

 
Damit bestätigt sich, was vorher nur vage sich abzeichnete: das Plus-Zeichen bei CI- als auch HD+ steht für ein Plus an Gängelung, ein Plus an Einschränkungen für den Verbraucher, ein Plus an Kosten — und dementsprechend ein dickes Minus an Komfort, an selbstbestimmtem Medienkonsum, an Wahlfreiheit.
Im Ergebnis kann das für den mündigen Medienbürger nur heißen: HD+? Just say NO! Denn nur eine Abstimmung mit den Füßen, an der Kasse nämlich, wird diesen Trend mittelfristig aufhalten … Einen noch größeren Bogen sollte man natürlich um Geräte mit dem CI+-Slot machen, allerdings wird das wohl leider schwierig werden, da kaum ein Hersteller hier dem Kunden eine Wahlmöglichkeit läßt. Und mit CI+ wird die Gängelung dann perfekt, nicht mal Timeshift-mit-Zwangswerbung ist dann noch möglich — Hallelujah!

yaVDR – erste Eindrücke

Nachdem ich mehrere Anläufe unternommen habe, einen VDR mit DVB-S2-Support und Full-HD-Ausgabe per VDPAU auf Ubuntu-Basis zurechtzustöpseln – und ein ums andere Mal in einer Dependency-Hell mich wiederfand – habe ich nun der jüngst veröffentlichten Version 0.1.1 von yaVDR eine Chance gegeben — und bin auch nach einem Tag noch sehr angetan!
Das, was yaVDR aus der Masse hervorhebt, ist die konsequente Ausrichtung auf einen Zweck: einen Linux-PC mit nVidia-Grafik zur Medienzentrale machen; dafür wird nicht nur ein aktueller (experimenteller) VDR mit (experimentellen) DVB-S2-Treibern in einem per CD oder USB-Stick installierbaren Ubuntu-basierten Image zusammengepackt, nein, auch der (experimentelle) PVR-Zweig von XMBC findet sich hier wieder, mehr noch: per Webinterface kann man zwischen xine, vdr-sxfe und(!) XMBC als VDR-Frontend wählen. Wer XBMC kennt, weiß, daß spätestens letzteres Eye-Candy vom Feinsten verspricht; aber auch das (Full-)HD-OSD der mitgelieferten VDR-Version ist schon sehr nett anzuschauen, kein Vergleich mehr mit dem begrenzten OSD der Full-Featured-Karten (wie sie auch noch mein Wohnzimmer-VDR zeigt):

Auch nett ist, daß man aus dem VDR-OSD heraus zu Firefox, XBMC und ‘nem Terminal wechseln kann. Beenden von XBMC und Firefox startet dann wieder (bei mir) vdr-sxfe als VDR-Frontend; der VDR-Prozeß an sich läuft, wie es sich gehört, in all der Zeit weiter – schließlich soll er ja auch ggf. was aufnehmen. Einziges Manko dieser Lösung – mit OpenBox als leichtgewichtigem Fenstermanager – bei mir: weder bei xterm noch in Firefox ist ein größerer Font wählbar — und die Standardgröße ist schon bei den ca. 1,5 Meter von der Tastatur bis zum 22″-Full-HD-Display an der unteren Lesbarkeitsgrenze, später im Wohnzimmer am 47″-Full-HD-TV werde ich gut 3 Meter vom Display entfernt sitzen, auch da wird’s zu klein sein … Ich habe schon alles erdenklichen Fonts installiert, vermutlich fehlt aber entweder ein Fontserver oder aber OpenBox schlicht die Unterstützung verschiedener Fonts :( Aber vielleicht fixen die Entwickler das ja noch, Version 0.1.1 ist ja auch mehr Beta als was anderes ;)
Ich werde mich jetzt ein bißchen einarbeiten und insbesondere noch eine lirc-Fernbedienungsmöglichkeit eruieren (lirc_ttusbir, ein Modul für ein USB-Dongle von Technotrend mit einem IR-Receiver, bricht auf dieser Hardware leider nachhaltig ins Essen; während es auf einem Medion-Laptop mit Intels Pentium Dual-Core 1a rennt (Ubuntu 9.10), gibt’s auf dem Asus-Board mit dem Athlon(tm) 7750 Dual-Core nur USB-Fehler und einen kernel-Hänger beim Versuch, das Modul wieder zu entladen :(). Bei Bedarf liefere ich auch gerne noch bißchen »Footage« von XBMC-PVR als VDR-Frontend; das macht beim ersten Blick jedenfalls einen super Eindruck, VDR ist soweit integriert, daß man auch Aufnahmen aus der XBMC-Oberfläche heraus starten kann.

How to brick your DockStar, voiding warranty and installing Ubuntu … (Part I)

(Bitte erst bis zum Ende lesen, bevor irgend etwas aus diesem Artikel ausprobiert wird!)
Basierend auf Alexander Hollers Anleitung, aus einem Seagate DockStar eine kleine Version des SheevaPlugs zu machen, dokumentiere ich hier meine Schritte, um meinen DockStar meinen beiden SheevaPlugs (sowie dem NSLU2) möglichst ähnlich zu machen, d. h. Ubuntu-/Debian-basiertes full-blown System, welches hier dann von einem USB-Stick startet (meine Sheevas starten vom NAND-Flash mit UBIFS, /var & Co. liegen ggf. auf einer externen USB-Platte; der NSLU2 startet von einer 1-TB Platte), …
Da Alexander Gentoo präferiert, ich aber keinen neuen Bastelschauplatz aufmachen möchte, habe ich aus dem SheevaPlug Installer das rootfs.tar.gz auf eine ext3-Partition (/dev/sdX2; die erste Partition muß wg. U-Boot VFAT oder ext2 sein (enthält nachher das Kernelimage), was man beides für / nicht möchte) eines 1-GB-USB-Sticks kopiert:

root@greebo:~# fdisk /dev/sdc
root@greebo:~# mke2fs -L /boot -m 2 /dev/sdc1
[...]
root@greebo:~# mke2fs -j -L /dockstar -m 2 /dev/sdc2
[...]
root@greebo:~# mkswap /dev/sdc3
[...]
root@greebo:~# mkdir /mnt2
root@greebo:~# mount /dev/sdc2 /mnt2
root@greebo:~# mkdir /mnt2/boot
root@greebo:~# mount /dev/sdc1 /mnt2/boot
root@greebo:~# cd /mnt2
root@greebo:~# tar --same-owner --numeric-owner -p -zxvf /home/wusel/SheevaPlug/sheevaplug-installer-v1.0/installer/rootfs.tar.gz
[...]
var/local/
root@greebo:/mnt2# tar --same-owner --numeric-owner -p -zxvf /home/wusel/SheevaPlug/sheevaplug-installer-v1.0/installer/modules.tar.gz
[...]
./lib/modules/2.6.30.2/source
root@greebo:/mnt2# cp -p /home/wusel/SheevaPlug/sheevaplug-installer-v1.0/installer/uImage boot/
root@greebo:/mnt2# ls -la boot/
total 5832
drwxr-xr-x 2 root root 4096 2010-03-07 18:44 .
drwxr-xr-x 21 root root 4096 2009-07-23 04:01 ..
-rw-r--r-- 1 wusel wusel 2620504 2009-07-23 04:11 uImage
root@greebo:/mnt2# chown -R root:root boot/
root@greebo:/mnt2# ls -la boot/
total 5832
drwxr-xr-x 2 root root 4096 2010-03-07 18:44 .
drwxr-xr-x 21 root root 4096 2009-07-23 04:01 ..
-rw-r--r-- 1 root root 2620504 2009-07-23 04:11 uImage
root@greebo:/mnt2# cd
root@greebo:~# umount /mnt2

Nett gedacht, aber zu kurz gesprungen; im Mailwechsel machte mich Alex’ auf Hardwareunterschiede zw. SheevaPlug & DockStar aufmerksam, sodaß eine simple Übernahme des Kernels leider ausscheidet. Also sind die weiteren Ausführungen Alex’ zu befolgen, als da wären:

  • Installation of the kernel (Linux)
    Wobei ich hier auf den SheevaPlug-Kernel setze; ich habe also meinen Kernel-Source auf dem Desktop geklont (neben linux-2.6.32.2-SheevaPlug habe ich nun auch ein Verzeichnis linux-2.6.32.2-DockStar). Danach wurden Alex’ Patches runtergeladen (in ein neues Unterverzeichnis DockStar-Patches) und per Hand applied: [EDIT: Auch wenn im Folgenden der 0001-Patch nicht gelistet ist, ist jener wichtig für das weitere Vorgehen im Verlauf dieser Artikelserie. Sorry, hatte ich augenscheinlich zu kopieren vergessen.]

    wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ patch --backup -p1 <DockStar-Patches/0002-MTD-partitons-used-by-the-Seagate-FreeAgent-DockStar.patch
    patching file arch/arm/mach-kirkwood/sheevaplug-setup.c
    wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ patch --backup -p1 <DockStar-Patches/0003-LED-definitions-for-the-Seagate-FreeAgent-DockStar.patch
    patching file arch/arm/mach-kirkwood/sheevaplug-setup.c
    wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ patch --backup -p1 <DockStar-Patches/0004-Change-board-name-for-the-SheevaPlug-to-reflect-the-.patch
    patching file arch/arm/mach-kirkwood/Kconfig
    Hunk #1 succeeded at 27 with fuzz 1.
    patching file arch/arm/mach-kirkwood/sheevaplug-setup.c
    wusel@greebo:~/SheevaPlug/linux-2.6.32.2-DockStar$ ls DockStar-Patches
    0001-ARM-Add-option-CMDLINE_FORCE-to-force-usage-of-the-i.patch
    0002-MTD-partitons-used-by-the-Seagate-FreeAgent-DockStar.patch
    0003-LED-definitions-for-the-Seagate-FreeAgent-DockStar.patch
    0004-Change-board-name-for-the-SheevaPlug-to-reflect-the-.patch
    linux-2.6.33_patches_dockstar.tar
  • Installation of the boot loader (Das U-Boot) sowie Patches for the boot loader (Das U-Boot)
    Hier habe ich die Werte wie von Alex beschrieben geändert, auch wenn ich bislang netconsole nicht genutzt habe. Ich habe U-Boot auf einem meiner SheevaPlugs kompiliert (anders als Alex in seinem Beispiel), dabei fiel auf, daß das Skript »./mkDockStar.sh« hier stolpert; gibt es eine Fehlermeldung wie folgt, den Aufruf in der ersten Zeile des Skriptes von /bin/sh auf /bin/bash ändern:

    Image Type: Kirkwood Boot from NAND Flash Image
    Data Size: 185616 Bytes = 181.27 kB = 0.18 MB
    Load Address: 00c00000
    Entry Point: 00c00000
    Building u-boot.bin.pagesize
    [: 19: Illegal number: $[262144-185616]

Da ich keine Lust hatte, die Box aufzumachen und die serielle Schnittstelle zu bemühen, habe ich das »blparam«-Kommando der PogoPlug-/DeskStar-Installation bemüht¹:

 98 PATH=$PATH:/usr/local/cloudengines/bin/
99 blparam
100 blparam "oldbootcmd=nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000"
101 blparam 'oldbootcmd=nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
102 blparam "bootargs_usb_root=root=/dev/sda2 rw rootdelay=5 rootfstype=ext3"
103 blparam "bootload_kernel=ext2load usb 0:1 0x800000 /uImage"
104 blparam 'bootcmd_usb=usb start'
105 blparam 'newbootcmd=${bootcmd_usb}; ${bootload_kernel}; setenv bootargs ${bootargs_usb_root}; bootm 0x800000'
106 blparam "bootcmd_MLL_yes=setenv mainlineLinux yes; saveenv"
107 blparam "bootcmd_MLL_no=setenv mainlineLinux no; saveenv"
108 blparam "arcNumber=2097"
109 blparam "bootcmd_pogo=run bootcmd_MLL_no; run oldbootcmd"
110 blparam "bootcmd_plugapps=run bootcmd_MLL_yes; run newbootcmd"
111 blparam 'newbootcmd=usb start; ext2load usb 0:1 0x800000 /uImage; setenv bootargs ${bootargs_usb_root}; bootm 0x800000'
112 blparam 'bootcmd=run bootcmd_plugapps'

Leider funktionierte dies nicht, das Schätzchen bootete nicht mehr :( Nun muß also doch der Pegelwandler her und über die serielle Schnittstelle debugged werden …
Wiederbelebung – hoffentlich ;) – in Teil II.
(Redaktioneller Hinweis: Da meine Blogsoftware nicht vorsieht, Artikel zu schreiben und später zu veröffentlichen, trickse ich i. d. R. durch eine Velagerung in die Zukunft um diese Unzulänglichkeit herum; dieser Artikel sollte eigentlich auch die Lösung, also die Reanimierung meines DockStars, enthalten, nur kam ich zeitlich nicht dazu, diesen Teil in der Zeit, die ich den Artikel vorverlegt hatte, auch zu realisieren. Dadurch wurde der Artikel offensichtlich schon von anderen gelesen, und nach der zweiten Bitte auf (Wieder-) Veröffentlichung ist er hier nun also, als Teil I von (geplant) Zweien. Have fun, but: DON’T TRY THIS AT HOME, YOU’LL DEFINITIVELY BRICK YOUR DOCKSTAR AND IT’S UNCERTAIN IF IT’S UNBRICKABLE!)
___

¹ Die Idee stammt letztlich von einem nur noch im Google-Cache vorhandenen pastie.org-NoPaste:

#!/bin/bash
# This script updates the pogoplug uboot enviroment in preparation for running
# plugapps on the pogoplug v1, pogoplug v2 and dockstar.
# This script adds environment variables to make usb booting possible
# This script assumes that it is being run on a pogoplug that has
# firmware at least at rev 2.0.1 with the blparam executable.
# Preparation
mount -o rw,remount /
# Add boot commands
cd /usr/local/cloudengines/bin
./blparam "arcNumber=2097"
./blparam "bootcmd_mtd1_usb=nand read.e 0x800000 0x100000 0x200000; setenv bootargs $(console) $(bootargs_usb_root) $(bootargs_mtdparts); bootm 0x800000"
./blparam "bootcmd_pogo=run bootcmd_MLL_no; run bootcmd_mtd1_mtd2"
./blparam "bootcmd_MLL_yes=setenv mainlineLinux yes; saveenv"
./blparam "bootcmd_MLL_no=setenv mainlineLinux no; saveenv"
./blparam "bootargs_mtd2_root=root=/dev/mtdblock2 ro"
./blparam "bootcmd_mtd3_usb=nand read.e 00x800000 0x02500000 0x200000; setenv bootargs $(console) $(bootargs_usb_root) ; bootm 0x800000"
./blparam "bootcmd_mtd1_mtd2=nand read.e 0x800000 0x100000 0x200000; setenv bootargs $(console) $(bootargs_mtd2_root); bootm 0x800000"
./blparam "bootargs=console=ttyS0,115200 root=/dev/mtdblock2 ro"
./blparam "bootargs_usb_root=root=/dev/sda1 rw rootdelay=10 rootfstype=ext2"
./blparam "bcktopogo=setenv bootcmd run bootcmd_pogo; saveenv"
./blparam "bootcmd_plugapps=run bootcmd_MLL_yes; run bootcmd_mtd3_usb"
./blparam "bootcmd=run bootcmd_pogo"
# Replace rcS
cd /etc/init.d
mv rcS rcS.backup
wget http://plugapps.com/os/pogoplug/full/rcS
chmod 755 rcS
# Write new kernel (2.6.32.7) to the free partition
cd /tmp
wget http://sheeva.with-linux.com/sheeva/2.6.32.7/sheeva-2.6.32.7-uImage
# Now, how do we write it?
# Download and extract Plugbox-1.0.tar.gz to USB drive
touch /tmp/.cemnt/mnt_sda1/plugapps

OpenShot, revisited

Nachdem ich dankenswerterweise @_refugee_ beim Zusammenschneiden des B-Day-Videos für @ifranz über Tastatur und Maus schauen durfte, weiß ich nun, wie weit OpenShot wirklich noch entfernt ist von auch nur ansatzweisem professionellem Videoschnitt … *seufz*
Aber es sind gar nicht die Goodies, die fehlen, wie die Einsetzung eines externen Objektes basierend auf der Bewegung des darunterliegenden Motivs (s. El Burros schwarzer Balken im B-Day-Video). Mit meinen Quelldateien scheitert OpenShot leider schon an den Basics; das folgende Video zeigt leider zu deutlich, was ich meine:

Die Videodatei wurde erstellt mit meiner Kodak Zi8 (leider habe ich erst beim Schnitt feststellen könne, daß es nicht ganz scharf ist). Für diverse Effekte mußte ich natürlich Schnitte setzen, leider kotzen ffmpeg als Backend bzw. OpenShot als Editing Suite ins Essen dabei: (fast) jeder Schnitt beginnt mit einem weißen Frame, im Video als helles Aufblitzen zu sehen. Das will man natürlich nicht; gut, ich bin nicht auf den Kopf gefallen und nachdem »die Großen« ja auch munter nach »Apple Intermediate« (MJPEG?) wandeln, habe auch ich das Quellvideo vom h264-aac-.MOV in ein mjpeg-mp3-.AVI gewandelt. Alles noch mal auf Start und neuen Schnitt probiert — aber halt, was ist das? Das Video läuft nicht mit, nur die Tonspur wird abgespielt, Video hingegen eher gar nicht denn überhaupt außer direkt vom Start auch nur halbwegs tonsynchron abgespielt :( Videoschnitt ohne zu sehen, bei welchem Bild man tatsächlich ist, ist zu optimistisch für mein Alter :(
Ähnliche Probleme habe ich mit den MTS-Files (AVCHD lite) meiner Panasonic TZ7 gehabt — und schlimmere: teilweise – ich weiß nicht, ob das an dem Mixing von 29,97 fps-Clips (Zi8) und 25 fps-Schnipseln (TZ7) lag –, liefen Ton und Bild bei den MTS-Dateien auseinander :(
Ich weiß nicht, ob meine Probleme an den HD-Dateien liegen; in Screencasts finde ich in der Regel nur Beispiele von toll laufendem OpenShots mit SD-Dateien … Aber auch in dem Bereich ist nicht alles Gold, was glänzt :( Denn als ich heute eine Doctor-Who-Folge archivieren wollte (Mitschnitt von BBC HD per VDR dank meiner Schüssel auf Astra 28 Grad Ost im Garten), sperrte sich OpenShot auch gleich mehrfach:

  • Die orginale Datei in OpenShot zu bearbeiten war unmöglich, mit …
    Input #0, mpeg, from '../Doctor_Who_S05E01/all.vdr':
    Duration: 01:15:00.44, start: 30259.218122, bitrate: 10174 kb/s
    Stream #0.0[0x1e0]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR 16:9], 50 tbr, 90k tbn, 50 tbc
    Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 256 kb/s
    Stream #0.2[0x80]: Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s
    Stream #0.3[0x20]: Subtitle: dvdsub

    … mochte OpenShot nicht arbeiten bzw. ich nicht, denn ich benötige die Tonspur 0.2; 0.1 enthält Ton + Bildbeschreibung für Blinde, das möchte man als Sehender nicht als primäre Tonspur. Leider bietet OpenShot keine Möglichkeit, eine Tonspur zu selektieren. (HINT!)
    (Das 1440×1080 ein recht eigenwilliges Format ist – ich kannte bei HDTV bislang nur 1280x720p50 und 1920x1080i50 –, seit mal dahingestellt.)
  • Die mittels …
    ffmpeg -i ../Doctor_Who_S05E01/all.vdr -ab 128k -ar 44100 -vcodec libx264 -acodec libmp3lame -aspect 16:9 -s 720x406 -b 2500k -map 0:0 -map 0:2 -y Doctor_Who_S05E01-SD.avi
    … erstellte SD-Datei (an HD rechnet der eine benutzte Kern des Quadcores noch immer …) wollte ich dann in OpenShot kürzen (6,5 Minunten am Anfang raus, 5 Minuten am Ende) — aber beim Schnitt begann OpenShot mit dem Video immer von 00:00:00, nur der Ton wurde entsprechend der Schnitte positioniert.

Letzteres war – leider – denn auch konsequent dem WYSIWYG-Prinzip folgend das, was OpenShot kodierte:

Ich weiß leider nicht, an welcher Stelle da was versagt; ich habe mal ganz stark ffmepg im Verdacht, aber habe mich zu wenig um OpenShot-Interna gekümmert für auch nur einen educated guess; Fakt ist, daß Videoschnitt mit OpenShot ein Abenteuer bleibt :( Es mag mit vielen Ausgangsdateien schon super laufen — mit so ziemlich nichts, was ich OpenShot vorwarf, wurden OpenShot oder ich glücklich :(