Mit der unter GPLv3 lizenzierten App Clementine Remote lässt sich das zuhause laufende Clementine über ein Android-Gerät fernsteuern. Da bei mir fast immer Musik läuft ist dies sehr praktisch.
Die Musik selbst lässt sich über die App nicht hören, aber die läuft schließlich wenige Meter entfernt über die Anlage
Voraussetzungen
Man benötigt eine aktuelle, noch nicht freigegebene Version des Clementine-Players, Entwicklersnapshots für Windows, Mac und Ubuntu sind im Bereich “Hacking” unter www.clementine-player.org/participate verlinkt. Eine Anleitung zum Kompilieren gibt es hier.
Konfiguration auf dem Desktop …
Zuerst stellt man Clementine entsprechend unter “Tools -> Preferences -> Network Remote” ein.
Hier ist der Port 5500 voreingestellt, verwendet wird TCP. Je nachdem, ob der eigene Rechner direkt von außen erreichbar ist, sollte man hier einen Haken setzen bei “Accept non public clients only”, damit Verbindungen aus nicht privaten Netzen abgelehnt werden.
Zur “Absicherung” hat man die Möglichkeit, eine maximal 5-stellige PIN zu vergeben.
Die angegebene (lokale) IP-Adresse benötigt man später noch.
Praktischerweise gibt es hier direkt Link und QRCode zur App im Google Play Store. Alternativ lädt man sich die App direkt auf der Projektseite herunter (links unter Downloads).
Konfiguration für Clementine Remote
… und auf Android
Nun startet man die App auf dem Android-Gerät und gibt die IP-Adresse ein, die auch in der Konfiguration des Clementine-Players zu sehen ist.
Clementine Remote – Verbinden
Beim Verbinden wird eine eventuell vergebene PIN abgefragt.
Clementine Remote – PIN
Das war es schon.
Möglichkeiten der App
In der Startansicht werden Cover, Titel, Album, Künstler und Länge angezeigt
Clementine Remote – Infos zum aktuellen Stück
Zugriff auf alle aktuell geföffneten Playlisten
Clementine Remote – Playlists
(Hier fehlt mir noch die Möglichkeit, direkt in der Playlist zu einer bestimmten Stelle vorzuspulen, um ein Stück besser “antesten” zu können.)
Suche in Playlisten
Navigation zum nächsten, vorherigen Stück, Play/Pause und Sprung zu bestimmter Position
Änderung der Abspielreihenfolge; zufällig über Titel/Alben/alle/deaktiviert
Änderung der Wiederholung: Titel/Album/Playlist/keine
Seit das Android-Gerät bei mir ist, reicht der normale Newsreader (Akregator) nicht mehr aus. Man wünscht sich die Möglichkeit, sowohl auf dem Desktop als auch auf dem Android dieselben Newsfeeds zu lesen; möglichst nicht doppelt.
Mein Favorit war zu Beginn die noch nicht fertige News-App für ownCloud, da es für diese in Zukunft eine Integration in Akregator geben soll. Im Test hat sich die App leider als noch unbrauchbar erwiesen.
Die Idee war dann, dass es ein Web-basierter NewsReader sein soll, den man selbst hosten kann. Da viele Menschen gerade eine Alternative für den in Zukunft wegfallenden Google Reader suchen, gibt es diesbezüglich genügend Lesestoff, z. B. unter www.adminswerk.de/selbst-gehostete-google-reader-alternativen/.
Habe von den erwähnten Projekten selfoss und rsslounge ausprobiert. Selfoss war anscheinend etwas überfordert von der Anzahl der Feeds (~170) und hat diese nicht zuverlässig aktualisiert. Bei rsslounge war auch irgendwas, aber ich erinnere mich nicht mehr.
Auch wurde Tiny Tiny RSS (ttrss) erwähnt (zuerst nur im Kommentar und später auch im Artikel selbst(?)); habe zuvor immer mal wieder diesen Namen gelesen, dachte aber es einer der vielen Online-Dienste mit vorgegebenem Server. Erst später, als es bei F-Droid eine Aktualisierung für den offiziellen ttrss Clienten gab, habe ich gemerkt, dass man sich selbst einen Server aufsetzen kann. Für diesen Newsreader habe ich mich schließlich entschieden.
In Kurz: Herunterladen (hier), entpacken, MySQL- oder PostgreSQL-Datenbank einrichten und “http://server/pfad/zu/ttrss/install/” aufrufen.
Nach der Installation meldet man sich mit dem Benutzernamen “admin” und dem Passwort “admin” an, ändert das Passwort und legt einen neuen Benutzer für die tägliche Verwendung an.
Es wird vom Projekt empfohlen php-apc auf dem Server zu installieren.
Habe mich für Crontab entschieden, da ich keinen dauerhaft laufenden Dienst mag. Empfohlen wird der Update-Daemon.
Konfiguration
Ab hier erfolgt die Konfiguration nur noch mit dem neu erstellen Benutzerzugang.
Damit die Android-App funktioniert muss man den Zugriff auf die API pro Benutzer unter “Preferences” aktivieren.
Import
Der Import der in Akregator exportierten OPML-Datei erfolgt unter “Preferences” -> “Feeds” -> “OPML”. Die Struktur bleibt erhalten.
ttrss mit importierter OPML-Datei
Um nach dem Import nicht auf den nächsten Cron-Aufruf warten zu müssen, ruft man ttrss einmalig direkt auf der Konsole des Servers auf:
php /pfad/zu/ttrss/update.php --feeds
So sieht man auch direkt, welche Feeds abgeholt werden.
Verwaltung
Unter “Preferences” -> “Feeds” kann man sich z. B. inaktive Feeds anzeigen lassen und diese direkt löschen. Über Drag’n'Drop lassen sich Feeds strukturieren.
Benutzung im Browser
Mit [n] springt man zur nächsten Nachricht und mit [p] zur vorherigen. Die Liste aller Tastenkürzel gibt es rechts oben im Drop-Down-Menü unter “Keyboard shortcuts help”.
Bei Verwendung von Firefox bietet es sich an unter “Preferences” -> “Feeds” die “Firefox integration” zu aktivieren. Beim Abbonieren eines neuen Feeds kann man ttrss direkt als Ziel auswählen.
ttrss Firefox Integration
Leider gibt es im Vergleich zu einem Desktop-Programm keine Benachrichtigungen im Systray, doch dank der Anpinnen-Funktion von Firefox residiert ttrss ganz links und leuchtet leicht bläulich, wenn es neue Nachrichten gibt. Das reicht aus, da der Browser immer geöffnet ist.
ttrss in Firefox angepinnt
So sieht der Newsreader in Firefox aus:
ttrss in Firefox
Fehler
Manchmal werden funktionierende Feeds rot gekennzeichnet und ttrss zeigt einen Fehler an; nach einem Neuladen des Feeds mittels Doppelklick funktioniert es wieder. Habe noch nicht herausgefunden womit das zu tun hat.
Die App TTRSS-Reader hat ein paar Probleme mit der Synchronisation der Feeds – manchmal hilft nur ein Restart der App damit neue Nachrichten auftauchen oder gelesene verschwinden.
Hier die offizielle App:
Offizielle ttrss App auf Android – Übersicht
Offizielle ttrss App auf Android – einzelne Feeds
Beide Apps lässt sich so einstellen, dass Bilder entweder gar nicht angezeigt oder direkt beim Start der App vorgeladen und zwischengespeichert werden.
Fazit
Eine ständig laufende Anwendung weniger, umfangreiche Konfigurationsmöglichkeiten und Zugriff von mehreren Geräten aus.
Bin von Tiny Tiny RSS begeistert
Man benötigt zwar einen Server, aber den hat man oft sowieso schon für andere Dienste.
In der Manpage von sshd sind im Abschnitt AUTHORIZED_KEYS FILE FORMAT Möglichkeiten aufgelistet, öffentliche Schlüssel nur unter bestimmten Bedingungen zu erlauben oder gewisse Dinge zu erzwingen.
Besonders interessant ist das letzte Beispiel, bei dem bei einem bestimmten Zertifikat ein definiertes Kommando ausgeführt wird.
Jetzt gibt es auch Screenshots von Plumble in der Galerie. Das ist der am weitesten entwickelte Mumble-Client für Android und wird immer noch aktiv weiterentwickelt; weitere Informationen zu Plumble gibt es im Wiki.
Per Voreinstellung werden in der .bash_history nur die letzten 500 Befehle gespeichert; das ist für meine Bedürfnisse viel zu wenig, schließlich möchte man sich auch noch Befehle von vor mehreren Wochen ins Gedächtnis holen. Glücklicherweise gibt es diesbezüglich ein paar Einstellungen für die Bash(siehe “man bash”),die entsprechenden Variablen fangen mit ”HIST” an.
Anzahl der zu speichernden Befehle
HISTSIZE - Anzahl der Zeilen, die über z. B. den Befehl history angezeigt werden und über [Strg+R] abrufbar sind.
HISTFILESIZE - Anzahl der Zeilen, die in die .bash_history eingetragen werden können; ist das Limit erreicht, werden die jeweils ältesten Einträge gelöscht.
Nicht alles speichern
HISTIGNORE - Muster, die nicht in die History aufgenommen werden. Die ausgeschlossenen Kommandos sind dann in der laufenden Bash nicht mehr erneut abrufbar mit [Pfeiltaste hoch]. So kann man z. B. alles mit task (TaskWarrior) aus der History ausschließen, da hier gerade am Anfang viele Befehlszeilen entstehen.
HISTCONTROL – Hier kann man folgende Dinge einstellen:
ignorespace – Befehle, die mit einem Leerzeichen beginnen, werden nicht gespeichert.
ignoredups – Befehle, die gleich zum vorherigen Befehl sind, werden nicht gespeichert.
erasedups – Alle vorherigen Befehle, die gleich zum aktuellen sind, werden entfernt, bevor in die .bash_history geschrieben wird.
Datum und Uhrzeit
HISTTIMEFORMAT - Ist diese Variable gesetzt, wird zusätzlich zu jedem Kommando ein Unix-Timestamp in die .bash_history geschrieben. Die Zeit wird im hier angegebenen Format zu jedem Befehl angezeigt. Hierfür kann man alle Variablen aus “man 3 strftime” verwenden.
Ergebnis
Meine .bashrc beinhaltet jetzt unter anderem die folgenden Zeilen:
Weiß noch nicht, ob es negative Auswirkung hat, so viele Befehle zu speichern, aktuell stehen erst ca. 9400 in der History. Vielleicht reichen auch die letzten 20000 Befehle schon aus
Habe vor ein paar Tagen eher zufällig gesehen, dass man auch unter Linux auslesen kann, wieviel Speicher der Grafikkarte aktuell verwendet wird. Bisher kannte ich das nur unter Windows und fand es schade, dass es unter Linux nicht geht.
Mit dem Kommandozeilen-Tool “nvidia-smi” hat man auch unter Linux über die NVidia Management Library Zugriff auf diese Daten:
nvidia-smi – NVidia System Management Interface
Bei dieser Ausgabe waren 9 virtuelle Desktops unter LXDE mit zwei Bildschirmen eingestellt und es waren mehrere Fenstern auf fast jedem Desktop geöffnet; zusätzlich lief ein Video.
Mumble 1.2.4 wurde zwar noch nicht freigegeben, aber große Änderungen sind bis zur Freigabe nicht mehr zu erwarten. Außerdem ist die Oberfläche bereits komplett ins Deutsche übersetzt (bis auf zwei Strings, von denen man nur einen sehen kann), sodass nichts dagegen spricht, aktuelle Screenshots für die verschiedenen Betriebssysteme zu erstellen. Einzig im Mumble-Hauptfenster stimmt der Versions-String noch nicht, aber das lässt sich verkraften. Unter Windows und Mac steht hier sowas wie “1.2.3-xxx” und unter Linux “Compiled Sep 15…”.
Für Linux und Windows kann ich die Screenshots selbst erstellen. Aus Ermangelung eines Mac-Rechners muss ich jedoch immer jemanden finden, der Screenshots auf diesem System erstellt. Auch dieses Mal hat sich wieder Sebastian bereit erklärt, dies zu erledigen, vielen Dank dafür
Für alle drei Systeme wurden gleiche/ähnliche Screenshots erstellt und befinden sich in derselben Reihenfolge in den jeweiligen Alben.
Habe außerdem die Alben für Mumble in der Galerie etwas umstrukturiert: Es gibt jetzt nicht nur pro Betriebssystem ein Album mit Screenshots von Mumble, sondern pro Version UND Betriebsystem. So können Screenshots aller zukünftigen Mumble-Versionen auf den verschiedenen Systemen vorgehalten werden.
Man kann argumentieren, dass sich die Screenshots seit 1.2.3 kaum verändert haben, das stimmt jedoch nicht ganz; es gibt auch in der Oberfläche von Mumble viele kleine Änderungen. Außerdem möchte ich eine saubere Trennung der verschiedenen Versionen in der Galerie haben
