Früher war alles besser – bei Druckern jedenfalls

Ja, es ist mal wieder Zeit für einen Rant-Post – „frisch“ aus dem Entwurfsordner vom März 2022.

Anlass dafür ist ein Drucker, aber nicht irgendeiner, sondern ein durchaus nicht billiger HP LaserJet M234sdwe. Früher hatte man Drucker, die konnten drucken. Heute ist das aber so etwas von out, denn warum soll ein Drucker drucken können, wenn er auch eine App haben kann?

Nun aber der Reihe nach:

Der bisher von mir verwendete Drucker gab leider den Geist auf. Ausdrucke wurden ein Glücksspiel und beim Scannen gab es Streifen. Da ich viel scanne, störte mich letzteres natürlich besonders.

Die Suche nach einem Ersatz stellte sich als schwierig heraus, da das Gerät folgende Eigenschaften haben sollte:

  • Gute Treiberunterstützung für Linux
  • (Monochrom-)Laser, um die Nachteile von Tinte zu vermeiden (Eintrocknen bei zu langer Nicht-Benutzung)
  • Duplex-Druck
  • Netzwerkunterstützung
  • am besten kein HP, weil zwei weitere – aufgrund meiner damaligen positiven Erfahrungen empfohlene – Multifunktionsgeräte von HP in meinem Umfeld mittlerweile ebenfalls das Zeitliche gesegnet haben

Letztendlich stellte sich heraus, dass die bessere Treiberunterstützung (bei neueren Distributionen für das gewählte Modell bereits von Haus aus) und die gewünschten Funktionen in der Kombination nur bei HP in Form des oben genannten Geräts zu haben waren.

Nach Lieferung des korrekten Geräts – der erste Händler hatte sich leicht vertan und einen sdne statt einem sdwe geliefert, der nicht über WLAN verfügt¹ – war die Einrichtung komplizierter als früher: Das kleine Display des Geräts bot keine Informationen zur Eingabe des WLAN-Kennworts, die Anleitung faselte etwas vom Eingeben von 123.hp.com in die Adressleiste des Browsers, was im vom Drucker aufgespannten WLAN natürlich nicht aufrufbar war. Ein Webinterface war aber auch unter der IP-Adresse des Druckers nicht zu finden (der Normalnutzer wird eher kein nmap zur Einrichtung verwenden ). Selbst ein Eintrag in die Hosts-Datei mit dem Drucker-IP brachte keine Abhilfe (ich dachte an einen Schutz, der den Host-Header überprüft).

Letztendlich stellte sich heraus, dass ich viel zu kompliziert gedacht hatte: Hinter 123.hp.com steckt eine Website, die einem die für die jeweilige Plattform geeignete App empfiehlt. Dummerweise führt der Link auf die für Linux gedachte Seite zu einem 404er.

Mit der Android-App ging es relativ schnell. Das Marketing-Geblubber von irgendwas mit HP+ und Instant Ink war schnell weggeklickt und anschließend die App gelöscht, nachdem sie dauernd in den Benachrichtigungen die Einrichtung eines Kontos bei HP forderte – Der Drucker funktioniert ja!
Oder?

Einige Zeit später weigerte sich der Drucker zu Drucken. Das Betriebssystem meldete keine Probleme mit der Verbindung zum Drucker. Scannen funktionierte, folglich funktionierte die Verbindung zum Netzwerk. Als dann ein Druck auf die i-Taste einen Ausdruck hervorbrachte – das Drucken an sich also funktioniert, war ich dann doch etwas ratlos.

Letztendlich brachte ein genauerer Blick auf jenen Ausdruck die Erklärung:

Printer setup incomplete
Your HP+ printer must be set up using the HP Smart app. Visit 123.hp.com to download the app and complete the guided setup.
Any pages you have printed were intended for setup and have been exhausted. If you completed setup, turn your printer off for at least a minute, then turn it back on. Wait a few minutes to let your printer status refresh and try to print again.
Visit hp.com/plus-support for additional setup help.

Da fühlte ich mich von HP dann doch sehr getrollt. Also die App wieder installiert, ein Konto auf einen nichtssagenden Namen mit einer ebenso nichtssagenden E-Mail-Adresse eingerichtet und dann lief es wieder.
Ganz großes Tennis!

Kennt jemand Drucker, die ihre Kernfunktionalität noch ohne Mucken beherrschen?

–––
¹) Das WLAN erwies sich als nicht ganz so praktisch. Beim Scannen zahlreicher (100te) Seiten nacheinander brach die Verbindung ab und baute sich dann binnen etwa einer Minute wieder auf. Andere Geräte zeigen ein solches Verhalten nicht oder nur sehr kurz.
Ich weiß jedenfalls, warum ich Kabel soweit möglich Funk bevorzuge!

Warum man Freigaben eher nicht in ein Home-Verzeichnis mounten sollte… 🤦️

… wenn man gedenkt, ein Backup des Home-Verzeichnisses zu machen.
Kürzlich habe ich nämlich via sshfs eine Freigabe in mein Home-Verzeichnis eingehängt. Ein Mount-Point ist schnell erstellt, schließlich ist /home/julius meins 😉️. Und irgendwann mache ich dann ein Backup und wundere mich, wieso zum Geier das so lange dauert und stelle dann fest, dass das borg backup auch den Server mit sichert und der Datentransfer über das Internet halt einfach lange dauert. Immerhin war das nicht der Server, auf dem das Backup liegt, das wäre bestimmt witzig geworden.

Interessante Details zum Raspberry Pi 4

Wie bei meinem letzten Beitrag zu unterthematisierten Details des der neuen Version des Einplatinencomputers gehe ich hier wieder auf ein paar Dinge ein, die ich für interessant erachte, die aber nicht im Rampenlicht der Berichterstattung stehen…

  1. Die analoge Audioausgabe für die Klinkenbuchse wird weiterhin über PWM generiert (Quelle: Schaltplan des RPi 4). Wer bessere Audioqualität braucht, muss sich also weiterhin ein HAT anschaffen oder einen der nun zwei vorhandenen HDMI-Ausgänge benutzen.
  2. Der analoge Composite-Video-Ausgang an der Klinkenbuchse steht weiterhin zur Verfügung. Allerdings kann dieser nicht parallel zu den HDMI-Ausgängen benutzt werden (Quelle: Blogpost zum Release von Raspian Buster).
  3. Der Boot-Prozess wurde geändert. Statt der GPU, die erst im weiteren Verlauf des Boot-Prozesses die Kontrolle an die eigentlichen ARM-CPU-Kerne übergibt, sind jetzt die ARM-Kerne die eigentlichen Hauptprozessoren. Zudem existiert jetzt ein Flash-Speicher, der die Firmware für den Systemstart enthält.
  4. Damit einher geht auch, dass sowohl USB-Boot als auch Netzwerkboot anders funktionieren müssen (→ Die Firmware muss jetzt über PCIe mit dem USB-Controller und dem im SoC integrierten Gigabit-MAC „sprechen“), beides wird aber über Updates der Firmware nachgereicht.
  5. Der USB-C-Anschluss zur Stromversorgung ist gleichzeitig auch ein USB 2.0-Port. Dort liegt jetzt nämlich der USB-Port an, der ursprünglich der primäre und einzige USB-(OTG)-Port des SoC war.
  6. Probleme, die durch den Datenverkehr über den einzigen USB-Port des SoCs verursacht wurden, wie Audioaussetzer bei Netzwerktransfer über die am internen USB-Hub-hängenden Netzwerkkarte und gleichzeitiger Audioausgabe über eine am gleichen Hub hängende USB-Soundkarte, sind mit dem über PCIe angebundenen USB-Controller und der separat am SoC angebundenen Gigabit-Netzwerkkarte passé.
  7. Der Grafik-Stack beinhaltet weniger proprietären Code und setzt jetzt auf Mesa. Der Treiber dafür war schon länger in Arbeit und wurde auch in Zusammenhang mit einem möglichen RPi 4 gesehen.

Insgesamt stellt der RPi 4 eine gelungene Rundum-Überholung dar. Wo möglich und nötig, wahrt er die Kompatibilität zu den Vorgängern. Und beseitigt dabei die Probleme der Vorgänger, was Erweiterbarkeit der SoC-Architektur, mangelnde IO-Bandbreite und fehlenden Arbeitsspeicher angeht. Erweiterungen, HATs und Anleitungen funktionieren allerdings weiterhin. Und das zu weiterhin günstigen Preisen und anscheinend weiterhin gutem Software-Support.

Das als Gesamtpaket hat die Konkurrenz zwar immer angekündigt, aber nie wirklich geliefert.
Trotz aller Schelten, die die RPi-Macher bisher für ihre Entscheidungen („Veraltetes SoC einsetzen geht gar nicht!“, „Wo bleibt Gigabit-Ethernet?!“) kassiert hat, muss man anerkennen, dass sich manche Dinge eher inkrementell lösen lassen als wenn man sie von Anfang an „richtig“ zu machen versucht und dann letztlich doch an der Komplexität des Ganzen scheitert.

Ich benötige im Moment keinen weiteren RPi, auch keinen schnelleren, weil ich alle meine drei Pis (3B, 3B+ und 3A+) im Headless-Betrieb nutze und sie dafür vollkommen ausreichend sind. Aber sobald mal wieder genug Geld in der Bastelkasse sein dürfte, wird der Haben-Reflex sicherlich überhand nehmen…

TV-Adapter-Einstellungen in Tvheadend zurücksetzen

Ich benutze Tvheadend als TV-Streaming-Server und hatte letztens das Problem, dass ich die Adapter-Einstellungen nicht mehr ändern konnte, weil ich vorher ein bisschen damit herum gespielt hatte – einen der Tuner hatte ich als Master-Tuner eingetragen, weil ich lediglich ein einzelnes Koaxialkabel in Satblock-Verteilung, was die am meisten benutzte Topologie für die Verteilung Satelliten-TV ist, am Standort des Servers hatte. Das bedeutet, dass nur einer der drei Tuner den Frequenzbereich und die Polarisation bestimmen kann.

Nun habe ich drei Kabel dort liegen, womit alle drei Tuner separat angesteuert werden können. Theoretisch, denn trotz dreier Tuner schien Tvheadend nur einen Tuner zu nutzen.

Da mir das Einstellungsmenü seltsam leer erschien (der Punkt „Universal LNB only“ fehlte bei zwei von drei Tunern), wollte ich „einfach“ mal die Einstellungen löschen und alles komplett von vorne konfigurieren. Diese Option konnte ich allerdings nirgends finden. Auf den richtigen Weg brauchte mich dann ein Beitrag im Tvheadend-Forum: Man muss die entsprechende Konfigurationsdateien unter /home/hts/.hts/tvheadend/input/linuxdvb/adapters/ löschen:

  1. Tvheadend stoppen: service tvheadend stop
  2. (Sicherheitshalber) Backup erstellen: rsync -a /home/hts/.hts/ dot_hts_back
  3. (In meinem Fall) alle Adapter-Dateien (pro je verbundenem Tuner ist es immer eine Datei) löschen: rm /home/hts/.hts/tvheadend/input/linuxdvb/adapters/*
  4. Tvheadend wieder starten: service tvheadend start
  5. Adapter in Tvheadend wieder neu konfigurieren (da wollten wir ja hin :-)).

Die benutzte Tvheadend-Version ist übrigens 4.2.8-23.

Reset TV adapter settings in Tvheadend

I use Tvheadend as TV streaming server and recently encountered the problem that I couldn’t change the adapter’s settings any more. Two of three tuners missed the option „Universal LNB only“ and only one tuner was used by Tvheadend. Before that I set one tuner as master tuner because of the fact that I only had one free cable to the LNB. This is a restriction in the classic satellite signal distribution topology because only one tuner of the three available is able to control the polarisation and frequency range sent through the cable.
Anyway, now I have three cables for three tuners and wanted to change the settings.

Because of missing the Option „Universal LNB only“ in two of three cases, I wanted to reset all adapter settings but it seems that Tvheadend does not allow this. The solution was provided by a posting in the Tvheadend forum: It was neccessary to delete the adapter configuration files in /home/hts/.hts/tvheadend/input/linuxdvb/adapters/.

  1. stop Tvheadend service tvheadend stop
  2. create Backup (just to be safe): rsync -a /home/hts/.hts/ dot_hts_back
  3. delete files (one per every tuner ever connected): rm /home/hts/.hts/tvheadend/input/linuxdvb/adapters/*
  4. start Tvheadend: service tvheadend start
  5. configure adapter in Tvheadend (what was the goal :-))

The used Tvheadend version is 4.2.8-23.