Fernsehen unter Linux ist echt eine Wissenschaft für sich, aber ich wollte es mal wagen. Zum Einsatz kommt ein von Windows 10 befreiter MSI Cubi N sowie eine DVBSky S960 für den Satellitenempfang. Da ich den Rechner nicht ausschließlich zum Fernsehempfang benutze, habe ich mich für ein normales Debian Jessie entschieden, auch der für blinde Nutzer vollständig zugänglichen Installation wegen. Vielleicht werde ich es irgendwann auch noch mal mit einem meiner momentan arbeitslosen Raspberrys versuchen. Das System war binnen kurzer Zeit eingerichtet, wobei ich es mit einigen Backport-Paketen nachrüsten musste, da es z. B. Treiberprobleme und Anzeigeschwierigkeiten im X-Server gab. Auch die Firmware für die DVBSky-Box musste händisch nachinstalliert werden. Hier habe ich mich am OpenELEC-Firmware-Repository bedient und die Dateien dvb-demod-m88ds3103.fw sowie dvb-demod-m88rs6000.fw nach /lib/firmware kopiert. Zwar werden vom Hersteller ebenfalls Linux-Treiber angeboten, diese müssen jedoch selbst kompliliert werden, sofern ich die eher dürftige Dokumentation richtig verstanden habe.
Kleiner Tipp am Rande: Fehlende Firmware-Module lassen sich sehr bequem mittels Isenkram herausfinden und unter Umständen sogar automatisch nachinstallieren, sofern es sich nicht um proprietäre Software aus non-free oder von Drittanbietern handelt. Isenkram ist in den Debian-Paketquellen zu bekommen.
Die DVBSky-Box funktionierte problemlos, was ich mit einer hoffnungslos veralteten, aber zum Teil noch funktionierenden Channels.conf herausfinden konnte (Kann sich noch jemand an TM3 oder das ORB-Fernsehen erinnern?). Eine eigene Channels.conf zu erstellen schlug jedoch zunächst fehl:
steffen@Steffen-TV:~$ scan /usr/share/dvb/dvb-s/Astra-19.2E > ./channels.conf
scanning /usr/share/dvb/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ERROR: cannot parse'[CHANNEL]'
ERROR: cannot parse' DELIVERY_SYSTEM = DVBS'
ERROR: cannot parse' FREQUENCY = 12551500'
ERROR: cannot parse' POLARIZATION = VERTICAL'
ERROR: cannot parse' SYMBOL_RATE = 22000000'
ERROR: cannot parse' INNER_FEC = 5/6'
ERROR: cannot parse' INVERSION = AUTO'
ERROR: initial tuning failed
dumping lists (0 services)
Done.
Eine Suche nach Möglichkeiten, diesen Fehler zu beheben, brachte wenig Resultate, bis auf den Tipp, es doch mal mit W Scan zu versuchen. Hier ist die Syntax zwar etwas komplexer, jedoch funktionierte der Sendersuchlauf auf Anhieb.
w_scan -fs -s S19E2 -E0 -X > channels.conf
Dieser Befehl startet einen Suchlauf nach allen frei empfangbaren Radio- und Fernsehprogrammen auf der Satellitenposition Astra 19,2° Ost, und gibt sie in einer Channels.conf-Datei aus, welche sich z. B. in Me TV, MPlayer oder jedem beliebigen Xine-Frontend nutzen lässt. Die Liste sollte jedoch zunächst sortiert werden, da sie sonst ziemlich unübersichtlich wirkt.
Als Nächstes werde ich verschiedene Programme für den Fernsehempfang austesten. Eine ähnlich komfortable Software, die es mit DVBViewer unter Windows aufnehmen kann, darf ich wahrscheinlich nicht erwarten, auch was die Einrichtung angeht. Derzeit nutze ich Me TV, was aber schon seit mehreren Jahren nicht mehr weiterentwickelt wird, bisher allerdings am unproblematischsten einzurichten war und sich auf die grundlegenden Dinge des Fernsehvergnügens beschränkt. Durch die Senderliste blättern, hin und wieder eine Aufnahme anfertigen. Auch spielt hier natürlich die Zugänglichkeit mit Orca eine große Rolle, was bei eher visuell orientierten Tools nicht immer selbstverständlich ist. Was müssen diese Blinden aber auch Fernseh gucken? :)
Dokumentationen sind gut, eigene Kreativität beim Umsetzen der Anweisungen ist aber auch nicht verkehrt - so jedenfalls meine Erfahrung des gestrigen Abends. Kopfzerbrechen bereitete mir da der ProFTPD-Server, welcher unter Debian Jessie offenbar recht seltsame Voreinstellungen mitbringt.
Ein neuer Server, ein neues Debian, ansonsten aber dieselben Software-Komponenten mit weitgehend identischer Konfiguration, das machte die Migration der Daten relativ einfach. Dann natürlich die vielen Kleinigkeiten und Tweaks, die man sich besser irgendwo notieren sollte, um sie beim nächsten Umzug wieder zur Hand zu haben. Manchmal treten jedoch auch neue Probleme auf, von denen vorher nie eine Rede war. So geschehen, als mich eine Freundin, die bei mir Webseiten und Dateien hostet, darauf aufmerksam machte, dass sie während FTP-Uploads Verbindungsabbrüche erleidet, welche die angefangenen Übertragungen komplett zurücksetzen, sodass sie mit dem Hochladen wieder von vorn anfangen muss. Bei großen Dateien und einer schmalen Bandbreite ist das natürlich ärgerlich. Also kurz gecheckt, ob auf dem Server alles in Ordnung ist. "AllowStoreRestart" war in "/etc/proftpd/proftpd.conf" wie erwartet auf "on" gesetzt, Netzwerkprobleme beim Server waren ebenfalls nicht erkennbar. Kurz noch mit einer eigenen Datei getestet, ob "AllowStoreRestart" tatsächlich greift, dann die Sache mit einem "liegt halt an deiner Verbindung" abgehakt, wie es sich für einen guten Hobby-Admin eben gehört, dessen Fußvolk ohnehin alle Probleme selbst verursacht. :)
Tja, wenn da diese "penetranten" User nicht wären. Die Verbindungsabbrüche blieben, also habe ich im Weltnetz nach möglichen Ursachen und Lösungen geforscht. Jemand schlug vor, ganz einfach die Timeout-Einstellungen auf 0 zu setzen, sodass der Server die Verbindung geöffnet hält. Hmm, wann er unter der Last hunderter offener TCP-Verbindungen wohl zusammenbrechen würde? Nein, das war also keine Option.
Der ausschlaggebende Hinweis kam dann jedoch von meiner Freundin, die dadurch von jeglicher Mitschuld freigesprochen war, sieht man mal davon ab, dass die Verbindungsabbrüche durch ihr wackliges WLAN passierten. Entscheidend zur Problemfindung war, dass nur jene Dateien, die korrekt während des Uploads pausiert wurden, auf dem Server erhalten blieben und später fortgesetzt werden konnten. Wurde eine Verbindung aber unerwartet unterbrochen, verschwanden die bisher hochgeladenen Daten vom Server, und man musste von vorn anfangen. Dies konnte ich zweifelsfrei reproduzieren, also ging die Suche jetzt zielgerichtet weiter.
Fündig wurde ich recht schnell in der ProFTPD-Dokumentation. Die Option "DeleteAbortedStores" sah ganz danach aus, als könnte sie mir weiterhelfen, aber:
The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded HiddenStores files if the transfer is stopped via the ABOR command rather than a connection failure.
Diese Option war also nur im Zusammenhang mit der Option "HiddenStores" verwendbar und zudem standardmäßig deaktiviert, wollte man der Dokumentation glauben. "HiddenStores" wiederum sorgt dafür, dass Dateien temporär als versteckte Dotfiles hochgeladen werden, erst nach vollständigem Upload werden sie umbenannt. Ebenfalls eine Option, die standardmäßig deaktiviert ist - und es auf meinem Server auch war, was ich während des Transfers beobachten konnte.
Nun, es vergingen weitere grüblerische Minuten, bis ich mich dann dazu durchringen konnte, diese eigentlich unsinnig erscheinende Option dann doch einfach mal auszuprobieren. Also in der ProFTPD-Konfiguration die Option "DeleteAbortedStores" hinzugefügt und auf "off" gesetzt. Siehe da, nach einem Neustart des Dienstes funktionierten die Uploads wieder so, wie sie sein sollten. Offenbar war die Dokumentation in diesem Punkt schon etwas veraltet, wie ich wenig später herausfand, als ich eine leicht abgewandelte Formulierung in der Dokumentation des Mod_xfer-Moduls fand:
The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded files if the transfer is stopped via the FTP ABOR command (as opposed to a connection failure). By default, DeleteAbortedStores is off; however when HiddenStores is enabled, then DeleteAbortedStores is automatically enabled as well.
Hier greift "DeleteAborted"Stores" also nicht ausschließlich im Zusammenhang mit "HiddenStores". Durchaus denkbar, dass sich inzwischen entgegen der Dokumentation auch der Standardwert dieser Option geändert hat. Welchen Sinn es haben könnte, diese Option auf "on" zu setzen, ist mir aber schleierhaft.
Fall erledigt, Freundin wieder glücklich. Das nächste Mal überlege ich mir aber schlagkräftigere Argumente, damit endlich wieder der User die Schuld tragen kann! :)
Screen-Reader-Nutzer unter Linux dürfen sich freuen: Gestern wurde Version 1.0 der Voxin-Sprachausgabe veröffentlicht. Hierbei handelt es sich um die Linux-Portierung der von IBM entwickelten Text-To-Speech-Engine ViaVoice, die inzwischen zwar nicht mehr weiterentwickelt wird, sich jedoch nicht zuletzt durch den vom JAWS-Bildschirmleser bekannten Ableger Eloquence immer noch großer Beliebtheit erfreut. Da viele der zeitgemäßeren kommerziellen Sprachausgaben für Linux nicht verfügbar sind, ist Voxin momentan somit eine zwar proprietäre, aber eine der besten Alternativen zur quelloffenen eSpeak. Sie kann in Verbindung mit Speech-Dispatcher als Sprachausgabe mit Orca verwendet werden und ist auch im Audio-Desktop Emacspeak nutzbar.
Voxin wird von Oralux betreut, einer Non-Profit-Organisation, die sich für die Zugänglichkeit quelloffener Software einsetzt. Die Sprachausgabe an sich kann dabei nicht weiterentwickelt werden, wird aber an aktuelle Distributionen angepasst. Version 1.0 erschien nach einer längeren Pause und bringt unter anderem Unterstützung für Debian Jessie und Ubuntu 15.10/16.04 mit, außerdem wurde die Integration in 64-Bit-Systeme optimiert.
Möchte man LibreOffice unter GNOME deinstallieren, um es gegen die aktuellste Version auszutauschen oder ganz einfach nur loszuwerden, stößt man sehr bald auf ein gravierendes Problem:
sudo apt-get purge libreoffice*
Paketlisten werden gelesen...
Abhängigkeitsbaum wird aufgebaut....
Statusinformationen werden eingelesen....
Paket »libreoffice-filter-binfilter« ist nicht installiert, wird also auch nicht entfernt.
Paket »libreoffice-filter-mobiledev« ist nicht installiert, wird also auch nicht entfernt.
Paket »libreoffice-help-en« ist nicht installiert, wird also auch nicht entfernt.
[...]
Die folgenden Pakete werden ENTFERNT:
gnome* libreoffice* libreoffice-avmedia-backend-gstreamer* libreoffice-base*
libreoffice-base-core* libreoffice-base-drivers* libreoffice-calc*
libreoffice-common* libreoffice-core* libreoffice-draw*
libreoffice-evolution* libreoffice-gnome* libreoffice-gtk*
libreoffice-help-de* libreoffice-help-en-us* libreoffice-impress*
libreoffice-java-common* libreoffice-l10n-de* libreoffice-math*
libreoffice-report-builder-bin* libreoffice-sdbc-firebird*
libreoffice-sdbc-hsqldb* libreoffice-style-galaxy* libreoffice-style-tango*
libreoffice-writer* mythes-de* mythes-de-ch* mythes-en-us* python3-uno*
unoconv*
0 aktualisiert, 0 neu installiert, 30 zu entfernen und 1 nicht aktualisiert.
Wie man sieht, deinstalliert das Entfernen von LibreOffice scheinbar auch den Gnome-Desktop. Wird die Deinstallation fortgesetzt, passiert zunächst jedoch nicht viel. LibreOffice wird deinstalliert, ebenso das Paket GNOME. Hierbei handelt es sich allerdings nur um ein sogenanntes Metapaket, also ein virtuelles Paket, das zur Installation mehrerer Pakete genutzt wird. Deinstalliert man also das Paket GNOME, wird nicht der gesamte Desktop sofort deinstalliert, sondern die von diesem Paket abhängigen Pakete zunächst als Ballast im System gekennzeichnet, der sich theoretisch mit dem Befehl "sudo apt-get autoremove" entfernen lässt.
Paketlisten werden gelesen...
Abhängigkeitsbaum wird aufgebaut....
Statusinformationen werden eingelesen....
Die folgenden Pakete werden ENTFERNT:
argyll cheese file-roller finger firebird2.5-common firebird2.5-common-doc
firebird2.5-server-common fonts-lyx fonts-opensymbol fonts-sil-gentium
fonts-sil-gentium-basic gedit gedit-common gedit-plugins gir1.2-gdata-0.0
gir1.2-goa-1.0 gir1.2-gucharmap-2.90 gir1.2-rb-3.0 gnome-color-manager
gnome-documents gnome-games gnome-nettool gnome-sudoku gnome-video-effects
hamster-applet iagno icedtea-netx icedtea-netx-common iputils-tracepath
libdiscid0 libfbclient2 libfbembed2.5 libgpod-common libgpod4 libhyphen0
libmythes-1.2-0 libnatpmp1 libsofia-sip-ua-glib3 libsofia-sip-ua0 lightsoff
lp-solve media-player-info openjdk-6-jre python-wnck quadrapassel rhythmbox
rhythmbox-data rhythmbox-plugin-cdrecorder rhythmbox-plugins seahorse
simple-scan sound-juicer swell-foop telepathy-rakia transmission-common
transmission-gtk uno-libs3 ure xdg-user-dirs-gtk xfonts-mathml
Spätestens hier sollte man abbrechen, möchte man sein Desktop-System nicht nahezu unbrauchbar machen. Wie also verhindern, dass die Pakete via autoremove entfernt werden? Im Grunde ganz einfach: Man markiert die betreffenden Pakete als manuell installiert. Hierfür ist der Befehl "apt-mark" zuständig. Um mir die Schreibarbeit etwas zu erleichtern, habe ich zunächst mit
sudo apt-get -s autoremove > ./Paketliste.txt
eine Simulation des Autoremove-Vorgangs in eine Textdatei umgeleitet. Diese wird dann mit einem Texteditor so bearbeitet, dass lediglich die Zeilen mit den zu entfernenden Paketen darin stehen, alle weiteren Zeilen darüber und darunter werden gelöscht. (Ja, vermutlich geht das auch einfacher über dpkg, dieser Befehl war jedoch nicht auf die Schnelle zu finden.) Um die Pakete nun als manuell installiert zu markieren, genügt der Befehl:
sudo apt-mark manual $(cat '/Pfad/zur/Paketliste.txt')
Die betreffenden Pakete sind nun nicht mehr als automatisch installiert gekennzeichnet und sind via "apt-get autoremove" auch nicht mehr entfernbar. Somit hätten wir LibreOffice also ohne Probleme aus Gnome entfernt.
In manchen Einstellungs- und Programmfenstern kommt es vor, dass sich der Screen-Reader Orca nicht unterbrechen lässt, wenn man sich beispielsweise mit der Tab-Taste durch die Bedienelemente eines Fensters bewegt. Das hat zur Folge, dass man sich jedes Bedienelement bis zum Ende vorlesen lassen muss, ob man will oder nicht. Bei bereits bekannten Programmfenstern gelangt man auf diese Weise nur sehr langsam zum Ziel, sofern keine braillezeile zusätzlich zur Sprachausgabe zur Verfügung steht. Ganz zu schweigen davon, dass dieses Verhalten des Bildschirmlesers einem ziemlich auf die Nerven gehen kann.
Verantwortlich hierfür ist ein Bug im Zusammenhang mit der Clutter-Grafikbibliothek, der in neueren Gnome-Versionen offenbar schon behoben ist, nicht aber bei der in Debian Wheezy enthaltenen Version 3.4.2. Ein Update aus neueren Paketquellen könnte in diesem Fall helfen. Wer jedoch sein System möglichst stabil halten und nicht auf Testing-Pakete zurückgreifen möchte, kann sich mit folgendem Workaround behelfen.
- Ein Terminal im aktuellen Benutzerverzeichnis öffnen
- mkdir -p ~/.config/clutter-1.0
- cd ~/.config/clutter-1.0
- Mit dem Editor eurer Wahl eine leere Datei namens settings.ini anlegen und Folgendes eintragen:
[Environment]
EnableAccessibility=false
- Die Datei abspeichern und das Terminal wieder schließen
Auch wenn mit dieser Anweisung die Clutter-Zugänglichkeit vorübergehend ausgeschaltet wurde, kann Orca nun die Programmfenster wieder korrekt vorlesen und ist bei Bedarf auch zum Schweigen zu bringen. Testen lässt sich das beispielsweise in den Systemeinstellungen (Anwendungsmenü -> Systemwerkzeuge -> Einstellungen -> Systemeinstellungen).
Artikel-Feed (RSS) dieser Tag