Category: Geeks & Co.

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 :(

Ich gab’s ja zu, theoretisch ist mir die Abhängigkeit von Google ja bekannt und sie ist nur virtuell minder schlimm als die Abhängigkeit, in die man sich mit einem Apple-Gerät begibt. Allerdings geht »don’t-be-evil«-Google subtiler vor.
Klar, beim Start eines Android-Gerätes wird man dezent darauf hingewiesen, daß ohne Account bei Google die Erfahrung keine Schöne sein wird. Und auch im Betrieb fällt gelegentlich auf, daß man ja doch deutlich mehr in Richtung Google preisgibt, als man gemeinhin preisgeben wollen würde. Dazu eine Anekdote am Rande von Dienstag, Einkauf im Getränkemarkt:
Verkäuferin: Haben Sie auch die Deutschland-Card?
Ich: (etwas energischer als geplant) NEin.
V: Oh, das war deutlich. (grinst leicht)
I: Naja, irgendwann ist auch mal gut mit den ganzen Plastikkarten ….
V: Ja, ich hab’ sie auch nicht. Muß ja nicht jeder wissen, was ich alles zum Essen einkaufe …
Eigentlich ein wahres Wort. Und daß ich bei jedem Start der Google-Suche Google meinen Standort mitteile, ist eigentlich auch nicht meine Idee gewesen — die Macht der Voreinstellungen … Allersdings fällt die Abhängigkeit in der Regeln ja gar nicht auf; wir geben Google Real-Life-Data, im Gegenzug dürfen wir deren Dienste (frei) nutzen.
Aber heute bekam meine schone Android-Google-Welt einen Dämpfer, ja fast den Todesstoß: »Google Konto vorrübergehend deaktivert« beschied man mir, als ich mich per Web bei Google-Mail anmelden wollte; meine Androiden monierten nur ein angeblich falsches Passwort — was irgendwie nicht stimmen konnte.
Warum, wieso, weshalb: Google verrät’s nicht. Und außer einem Ausrufungszeichen in der Android-Statuszeile gibt es keinen weiteren Hinweis, Googles Dienste stellen die Funktion stillschweigend ein. Die Entsperrung war simpel; nur die Frage bleibt, was ich getan haben soll. Schließlich kann ich ein Verhalten nur dann ändern, wenn ich darum weiß, daß es unerwünscht ist …
Einen ziemlich faden Nachgeschmack hat diese Aktion seitens Goggle bei mir hinterlassen; einfach *schnipps* so von elementaren Diensten wie dem Kalender abgeschnitten zu sein, das saugt.

Der eine oder andere Follower mag’s mitbekommen haben, vor ein paar Nächten lieferte ich mir mit Teymour aka @icedsoul src=”http://blogdoch.net/images/twitter_image_icedsoul-2_thumb.png” float=”left”/> ein kleines Zwiegespräch auf twitter (ein nahezu vollständiger Abzug unten; da twitter nur den Rückwärtsbezug kennt, fehlen ggf. mehrteilige Antworten, auf die nicht »nach oben« geantwortet wurde) über Sinn und Unsinn von Apple, iPad, WePad, auferlegten Fesseln durch Apple vs. Rechten des Geräteeigentümers, … Nein, twitter eignet sich nicht wirklch dafür — aber offensichlich hatten wir beide ein Mitteilungsbedürfnis ;)
Heute morgen nun kam ein Tweet von @pixelpipe rein, der mich wieder einmal darin bestätigte, in Apple keinen vertrauenswürdigen Geschäftspartner zu sehen. Denn Apple hat Pixelpipes iPhone-App gekickt:

Another app pulled from the iPhone App Store, this time it’s Pixelpipe

March 27, 2010 · 5 Comments

After over a year in the iPhone App Store and a half dozen separate approved submissions, Apple has unfortunately decided to remove our application from the store. While I admit we were cutting some corners to provide functionality outside the API we were not using any private APIs & just being creative with-in the bounds of the of the public media directory.
What were we doing wrong? Simply scanning the contents of the DCIM directory to create a list of the photos & video. This provided our users with the capability to quickly multi-select any media from their photo gallery for upload instead of the one at a time functionality provided with-in the official API.
What makes this most unfortunate though is the fact it was another developer that complained about the functionality we were providing outside the official API, Apple was forced to react to the complaint & remove our application.[…]

 
Sofern ich das richtig verstehe, bietet also Apple keinerlei API an, um mehrere Mediendateien in einem Rutsch zu selektieren und einer Anwendung App zur Bearbeitung zuzuführen — schon das würde mich ja nerven, aber wer mit einer Maustaste klarkommt, klickt vielleicht auch gerne öfter … Anyway; @pixelpipe hat offensichtlich drum herum programmiert, sodaß deren App benutzerfreundlich arbeiten kann — was einem anderen App-Autoren mißfiel und der sich bei Apple beschwerte; daraufhin kontaktierte Apple @pixelpipe und forderte mit Fristsetzung von einer Woche eine Codeänderung, anderenfalls würde man die App aus dem Store schmeißen.
Mag das auch alles formal seine Ordnung haben, dieser Vorfall zeigt wieder einmal, warum ein geistig normal denkender Mensch sich nicht auf die Apple-Plattform einlassen dürfte: wenn es Apple gefällt, gibt es ggf. die Lieblings-App nicht mehr. @icedsoul argumentiere sinngemäß, daß natürlich Apple das Recht habe zu entscheiden, was auf deren Produkt an Apps laufen dürfe, und eben auch, was nicht:

@icedsoul 2010-03-27 02:55:26: @wusel naja seltsame einstellung. deren produkte dürfen auch deren regeln haben. und klar gibts alter. aber halt selten so gute.

 
Das sehe ich halt differenzierter; mit Apples App-Store, dem von Apple so konzeptionierten einzigem »legalen« Weg, Software, »Apps«, aufs iPhone zu bekommen, maßt sich Apple an, auch nach dem Verkauf der Hardware »iP…whatever«zu kontrollieren und zu bestimmen, was auf meinem Eigentum, dem Apple-Gerät nämlich, an Software installiert werden kann und was nicht. Ich denke, kein normaler Computernutzer würde sich von seinem OS-Hersteller vorschreiben lassen, welche Software er installieren darf und welche nicht; nicht zuletzt würden sicherlich die Kartellbehörden hellhörig, würde z. B. Microsoft aktiv die Installation von Firefox behindern.
Qualitätssicherung ist das eine; zensurmäßige Bevormundung der Kunden eine andere und dem Anschein nach tendiert Apple doch eher zu letzterem Verhaltensmuster :( Denn die Entfernung der @pixelpipe geschah augenscheinlich nicht wegen Nichtfunktion, sondern weil einem App-Mitbewerber es nicht gefiel, daß die Pixelpipe-App innovativ war.
Nunja. Apple und ich werden in diesem Leben wohl keine Freunde mehr; eigentlich schade, diese Wandlung des (gefühlten) damaligen Paulus’ Apple zum heute gefühlten Saulus miterleben zu müssen.
Hier nund der twitter-Austausch :)

Hachja. Nun wollte ich gestern »mal eben schnell« ein kurzes Video für die Großeltern zusammenklicken, welches deren Enkelin auf einer Schulaufführung zeigt — während der moderne Erwerbstätige ja flexibel zu sein hat, stellen mit zunehmendem Alter 300+ km Entfernung, zumal ohne adäquate Bahnanbindung, doch einen Hinderungsgrund dar, mal eben vorbeizukommen. Nunja, wozu gibt es DSL und/oder DVD, und schließlich rockt – für ein freies und kostenloses Tool – OpenShot ja die Hütte …
Nun, ich muß mein Urteil revidieren/konkretisieren: generell ist OpenShot ein feines Stück Software, unrund an vielen Ecken noch, aber imho auf dem richtigen Weg und weiter als vieles andere, was ich in dem Bereich gesehen habe. (Daß man chroma keying nicht auf einen Bereich beschränken kann, stört wahrscheinlich echt nur Leute wie mich, die keine Studioaufnahmen machen …)
Allerdings kotzt, Verzeihung, OpenShot 1.1.0 auf Ubuntu 9.10 ganz massiv ins Essen, wenn es MTS- (MPEG Transport Stream) Dateien meiner Panasonic TZ7 (AVCHD Lite, 1280x720p50, H.264-Video mit AC3-Audio) verarbeiten soll. Stimmt die Synchronität von Audio und Video bei komplett verwendeten Dateien noch meistens, ist ein Ton-Bild-Versatz beim Schnitt die Regel, die gelegentlich trotz Schnitt in OpenShot synchron bleibende Schnipsel bestätigen :(
Notgedrungen reencode ich die MTS-Dateien nach AVI — ja, leider reencode (ffmpeg -i $basename.MTS -vcodec libx264 -vpre hq -b 15M -bt 1M -threads 0 $basename.mp4), da ein simpleres Umpacken (mencoder $basename.MTS -ovc copy -oac copy -o $basename.avi) zwar von mplayer noch abgespielt wird inkl. Video, in OpenShot aber nur noch ein ziemliches fettes Audio-File ist. Any hint appreciated …
Warum das? Nun, mit den Mitteln von OpenShot – Bildschirm und Kopfhöhrer – Synchronität wiederherzustellen grenzt an eine Sisyphus-Aufgabe, zumal bei schlecht erkennbaren Lippenbewegungen. Da ist selbst das Reencode von x264 nach x264 mit 2 Frames pro Sekunde besser investierte Zeit …
Insofern möchte ich auch @_refugee_ nahelegen, beim angekündigten Test auf die unterschiedlichen Eingangsformate und deren Bearbeitbarkeit mit OpenShot ein Auge zu haben. (In meinem, final 20 Minuten langen, Zusammenschnitt gab es rd. einmal je halber Stunde Bearbeitungszeit einen Crash von OpenShot; ganz offensichtlich macht das Handling von x264-Streams zumindest in MTS-Containern noch massiv Probleme :( Ah, und apropros: OpenShot kennt kein Autosave; wer also MTS-Container beackert tut gut daran, häufiger seinen Bearbeitungsstand selbst zu speichen. Und keine Bange, wenn nach einem Crash & Reload des Projektes der Positionszeiger nicht mehr sich mitbewegt: einfach ‘n Schnipsel hinten anhängen, danach tat’s zumindest bei mir wieder …)

Über die Vorschläge von YouTube zu meinen von ifranznation gefeatureten – danke dafür, @ifranz – 4-Navi-Video bin ich auf ein Video gestoßen, welches suggeriert, Navigon Mobile Navigator 7 for Android würde, wie jede 08/15-Navilösung auch, Entfernung zum Ziel und voraussichtliche Ankunft (ETA, estimated time of arrival) anzeigen.
Das lies mir ja keine Ruhe, denn für mich ist das eine Pflichtfunktion; klar, neben dem intelligenden Vorschlagen der Fahrtroute unter Zuhilfenahme möglichst vieler aktueller Informationen (Stichworte: IQ Routes, TMC, Verkhersdichtemessungen). Zur Routengüte kann ich aus dem überwiegend staufreien Gütersloh wenig sagen, das würde erst eine längere Tour mal wieder zeigen können (jemand Lust auf ‘n Trip nach Amsterdam, Luxemburg oder Hamburg? ;)); aber daß Mobile Navigator 7 (MN7) wirklich nur die aktuelle Geschwindigkeit (lt. GPS), anzeigen soll, nicht aber – für mich in Autos ohne »Bordcomputer« eigentlich die interessantesten Größen – Durchschnittsgeschwindigkeit, Restentfernung zum (nächsten Zwischen-) Ziel, errechnete Ankunftszeit, hat mich ja schon vorher irritiert (vielleicht hat sich’s bei Navigon noch nicht so ganz rumgesprochen, aber ‘n Geschwindigkeitsmesser und -anzeiger ist in jedem Auto verbaut). Umso verwunderter war ich beim Betrachten der (Standbild-) Abbildungen in besagtem Video, daß dort genau diese Werte angezeigt wurden:

Alles nur ein Fake? Die gleichen Bilder finden sich auch im Produktdatenblatt, wobei auffällt, daß die Statuszeile Android-untypisch dunkel ist — wie auch auf dem Hintergrundbild zur Android-App. Alles nur geshopt?
Leider geben Navigons Produktseiten auch keine wirklichen Informationen preis, ob z. B. die Live-Services oder die »lustigen Stimmen« auch für MN7 for Android funktionieren:

Bitte beachten Sie:
– Es handelt sich bei diese Stimmen nicht um Text-to-Speech-Stimmen
– Dieses Produkt ist nicht für Via Michelin Geräte verfügbar

 
Gut, aus der Reihe »Via Michelin« ist MN7 for Android nicht … Mein vorläufiges Fazit also: tendentiell eine erwachsene Navigationslösung für Android, nicht so verspielt wie Motorolas Motonav (beim Milestone als Evaluationsmuster dabei – statt eines öden Pfeils kann man sich da 3D-Objekte zur Repräsentation seines Fahrzeugs aussuchen …), welches zudem mit laufenden »die Route wird neu berechnet«-Ansagen stört, fährt man nicht wie vorgesehen. Grafisch ebenfalls in meinen Augen angenehmer als CoPilot 8, welches mir von der Bedienoberfläche vorkommt wie das Erstlingswerk eines GUI-Designers, Abschlußklasse 1989 …
Aber leider kommt MN7 ohne], meiner Meinung nach, essentielle Navigationsfunktionen, wie der Anzeige der errechneten Ankunftszeit oder restlichen Entfernung zum Ziel — liebe Navigon, mit Verlaub: dem verantwortlichen Produktmanager solltet Ihr die Chance eröffnen, anderen Firmen zu schaden. Daß für eine Always-on-Gerätegattung wie Android keine Live-Dienste vermarktet werden (kein Hinweis darauf im MN7-Programm oder auf der Produkthomepage) ist denn auch nur konsequent — wer schon keine Ankunftszeitprognosen mitteilen mag, dem liegt kaum etwas daran, das seine Kunden optimal ans Ziel kommen :( Schade. Also doch – vergeblich, s. Kommentar #25? – auf TomTom hoffen?

Das Wetter wird besser, und nachdem Christian vorlegte, bin ich Montag mal ein bißchen durch Gütersloh gekurvt, mit 3 Navis an der Windschutzscheibe und dem Audi-Festeinbau. Ich mache die Nachbearbeitung solcher Spielchen ja nach wie von unter Linux – dank wiederum Christian Hinweis auf OpenShot vor zwei Wochen –, und das läuft alles andere als rund¹; verglichen mit dem LiVES-Krampf zuvor, ist OpenShot 1.1.0 aber reinstes Zuckerschlecken :-)

Aber in diesem Artikel wollte ich den Fokus auf Navigationssoftware für Android, in Konkurrenz zu klassischen Navigationsgeräten, legen. Und nein, Unterschiede lassen sich beim Rumzuckeln im verkehrsberihigten Bereich nicht wirklich herausarbeiten. Spannend wäre sowas auf einer längeren Strecke – vorzugsweise mit Staus –, aber mal eben Gütersloh-München nur für Navi-Spielereien? (Ok, wer derlei wirklich möchte, für den kann gerneauf Anforderung einen Paypal-Sponsoring-Button bereitstellen :-)) Gut, was kann man denn auf die Schnelle testen? Innerorts ist sicherlich die Rechtzeitigkeit und Genauigkeit von Anweisungen ein Thema; ein anderes ist das Verhalten, wenn der Fahrer dem Vorschlag nicht folgt. Und wenn man es ernsthaft betrachten wollte, wären auch Bewertungen der vorgeschlagenen Routen ein Muß …
Ich gedenke, etwas anders vorzugehen. Ich habe durch Zufall eine nette Route gefunden, wo von einem Startpunkt aus der Weg zu einem lokalen Einkaufszentrum schnell durch ein verwinkeltes Wohngebiet führen kann. Dies werde ich dieser Tage noch mal separat anfahren, und wenn mir jemand eine Befestigungsmöglichkeit der Zi8 im Wageninneren aufzeigt, wird das ggf. auch etwas spannender durch verschiedene Kameraperspektiven …
Was mich allerdings schon bei ersten Versuchen mit Navigon Navigator 7 on Android erschreckt hat: das neueste Produkt hat ganz offensichtlich die ältesten Karten, siehe Video ab 03:30 Minuten. Hier möchte Navigon Mobile Navigator 7 noch in die Straße reinfahren, die seit Abschluß des Baus des 2. Kreisels der Neuenkirchener Straße – seit etlichen Jahren also – eine Einbahnstraße in die entgegengesetzte Richtung ist. Medion (2007) und Audi (Kartenmaterial noch aus 2006) haben relativ altes Kartenmaterial. Jenes für CoPilot (2009) und Navigator 7 (2010) wurde deutlich später heruntergeladen — umso unverständlicher ist mir ein solcher Schnitzer. (Und wenn das schon in der provinziellen Medienhauptstadt Gütersloh ungenau ist, was darf man dann für andere Gegenden erwarten?)
Was mir im direkten Vergleich auffiel: Kartendarstellung und Anweisungen des Medion-Gerätes ähneln sehr dem Audi-Navi (Bedienung ist natürlich grundlegend anders, Audi: Drehknopf in Mittelkonsole, Medion: Touchscreen), ob es da gemeinsame Wurzeln gibt? Für PDAs war um 2003 herum die Medion-Version des »Navigator« ein leicht modifizierter »Mobile Navigator« von Navigon.
Von der Bedienung (Audi ausgenommen, da kein Touchscreen) finde ich das Navigonsystem am praktischsten, wo die Auswahl, wie man es aus dem Web kennt, mit zunehmender Länge der Eingabe immer kleiner wird, man kann also i. d. R. nach »Gütersl« etwas weiter unten auf »Gütersloh« tippen. Die physische Tastatur des Motorola Milestone verstärkt dieses gute Gefühl noch, muß man sich nicht am Treffen von winzigen Kästchen auf dem Bildschirm versuchen. Medion hingegen hat seinerzeit eine alphabetische Anordnung der Tasten auf seiner Bildschirmtastatur gewählt, das ist fast so bescheiden wie die Zehnertastatur in Wählscheibenanordnung seinerzeit beim Nokia 3650 …
Einen Sonderweg in der Bedienung geht klar CoPilot; wenn man nur dieses Anwendung nutzt, mag man sich in der eigenwilligen Bedienung vielleicht zurechtfinden, ich mag die CoPilot-GUI nicht, finde sie unnötig anders und kompliziert, unintuitiv.
CoPilot ist es auch, welches verschiedenen Stimmen anbietet und auch einen deutlich anderen Satzbau verwendet als da Gros des Navigationssysteme; für Navigons Mobile Navigator 7 habe ich leider keine Option gefunden, eine andere als die ewig-gleiche Frauenstimme auszuwählen.
Auch bei Zusatzdiensten zeigt sich CoPilot 8 fortschrittlicher, zumidnest kann man dort welche auswählen — leider werden (mir zumindest) keine Verkehrsinformationen angeboten; auch bei Navigon vermisse ich einen solche Option. Überhaupt sind die Einstelloptionen beim Navigon Mobile Navigator sehr übersichtlich — dem Anschein nach ist es als reines Onboardsystem konzipiert, ohne die Vorteile des always-on nutzen zu wollen oder zu können.
Zur Routenfindungsqualität kann man, wie gesagt, so auf die Schnelle nicht viel sagen. Was gelegentlich auffält, auch im Video oben, ist, daß beim Verlassen des Weges ein System eher den Fahrer »zurück auf die Planstrecke« lotsen will, das andere hingegen eher die Änderung hinnimmt und eine konvergierende Route vorschlägt. Und die Grenze, ab wann so oder so verfahren wird, scheint bei jedem System anders zu sein.
Kurzum, als Zwischenfazit: Navigon Mobile Navigator 7 scheint ein solides Produkt zu sein, wie man es vom »alten Hasen« auf diesem Gebiet auch erwarten durfte. Das Fehlen jedweder Onlineoptionen, insbesondere die Nutzung von Verkehrsinformationen via Internet, finde ich allerdings weder zeitgemäß noch der Plattform Android angemessen. TMC mag nicht der Hit sein; aber daß ich trotz always-on-Navigationsgerät noch dem Verkehrsfunkt lauschen müssen soll, finde ich doof. Auch vermisse ich Anzeigen von Reststrecke und voraussichtlicher Ankunftszeit am (nächsten Zwischen- sowie dem End-) Ziel. In den spärlichen Einstellungen habe ich, denke ich, wohl nichts übersehen …
____

@DerWesten Es bleibt die Frage: Wer vertritt Politikern gegenüber die Interessen der Netzgemeinde? Von wem fühlt ihr euch vertreten? #pc10 #lobbyarbeit ×