PVR-Funktionalität

Für das PVR-Backend musste eine Entscheidung getroffen werden – VDR oder MythTV. Nach einem Blick auf die Packet-Abhängigkeiten von MythTV (ich brauch kein libqt-*, mysql-server, transcode usw. auf meinem Media-Center-PC) fiel die Entscheidung im ersten Installationsversuch auf VDR. Doch ganz glücklich bin ich mit diesem nicht geworden. Die Administrationsoberfläche kam mir unübersichtlich und spartanisch zugleich vor. Der Sendersuchlauf mit dem Kommandozeilentool scan hat nicht funktioniert. Mit einer entsprechenden channels.conf aus dem Netz funktionierte das ganze zwar aber ob beide Empfänger der Karte genutzt wurden war mir nicht ganz klar.

Während der Konfiguration des VDR ist mir ein weiterer Dienst (tvheadend) auf der Maschine aufgefallen der anscheinend bei XBMCbuntu als out-of-the-box-PVR vorgesehen ist. Nach einer kurzen Recherche im Internet war ich gewillt auf dem neu installierten System Tvheadend als PVR-Backend zu verwenden.

Die Konfiguration lief dank Anleitung recht schmerzfrei. Auf Port 9981 läuft ein Webservice zu dem man mit dem vorkonfigurierten Benutzer/Passwort: xbmc/xbmc Zugang erhält. Bei einer mehrfach-Adapter-Karte sollte man wenn notwendig zunächst unter Configuration->TV-Adapters den Karten verschiedene Namen (Adapter Name) geben da sonst die Konfiguration durcheinander geraten kann. Danach führt man für jeden Adpater wie in der Anleitung beschrieben die DVB-Network-Lokalisierung, den Sendersuchlauf und das Channelmapping durch. Anschliessend wird der PVR im xbmc aktiviert und das PVR-add-on für Tvheadend installiert und konfiguriert.

Die Kanalreihenfolge kann man im Webinterface des Tvheadend-Dienstes unter Configuration->Channels anpassen indem in der ersten Spalte (Number) entsprechende Nummern vergeben werden und das ganze mittels „Save changes“ abgespeichert wird. Man muss nicht für alle Sender Nummern vergeben es reicht dies für die zur eigenen Verwendung benötigten zu tun die anderen werden hinter den nummerierten gelistet.

Wenn man die Aufnahmefunktion nutzen möchte sollte man unter Digital-Video-Recorder noch den Recording System Path anpassen (Pfad vorher mit passenden Rechten anlegen nicht vergessen) damit die Aufnahmen auf dem Terrabyte-Datengrab und nicht auf der SSD landen.

Der Test gleichzeitig während einer Aufnahme alle anderen Kanäle durchzuschalten verlief im XBMC erfolgreich – d.h. die Dual-Adapter-SAT-Konfiguration ist geglückt.

Nett wären dann noch die verschiedenen Kanalsymbole im Menü und OSD des Mediacenter. Leider funktioniert das nicht automatisch und man muss nochmal Hand anlegen. Die Kanalsymbole kann mann z.B. hier gesammelt herunterladen oder/und sich einzeln bei Lyngsat zusammensuchen. Diese packt man in einen Ordner im Homeverzeichniss des xbmc-Benutzers und konfiguriert diesen unter: System->Einstellungen-> Live TV-> Menü/OSD-> Standard-Ordner für PVR Thumbnails. Die Option „Suche fehlende Symbole“ erledigt die Zuordnung.  Damit das Mapping funktioniert müssen die Bilddateien genauso heißen wie die Sendernamen.

Um die Umschaltzeiten noch etwas zu optimieren kann man in den tvheadend-Einstellungen noch das idle-scanning aus- und den Punkt skip initial scan einschalten.

Alles auf Anfang

Die Geräuschkulisse und die Verwendung eines anderen Grafikkartenmodells veranlassten mich aus verschiedenen Gründen nochmal vor vorne zu beginnen.

Geräuschbekämpfung

Um die Komponenten zur Geräuschbekämpfung einzubauen musste das ganze Gerät nochmal zerlegt und wieder zusammengebaut werden. Folgende Änderungen sollten für mehr Ruhe sorgen:

  • Gehäuseboden und -seiten mit brummdämpfenden Bitumenmatten ausgekleidet
  • Mainboard (und damit den Prozessorlüfter) mit Gummiunterlegscheiben entkoppelt
  • Netzteil mit Gummirahmen vom Gehäuse entkoppelt
  • im Bios die Einstellungen für die Temperaturregelung der Lüfter gefunden und konfiguriert
  • den 92mm Gehäuselüfter gegen einen mit Temperaturregelung (4-poliger statt 3-poliger Anschluss) getauscht
  • die 2x 60mm Gehäuselüfter gegen leisere Modelle getauscht, vom Gehäuse mit Gummirahmen entkoppelt und die Spannung mittels entsprechendem Adapter reduziert
  • zusätzlich zur Festplatte auch den Festplattenrahmen mit Gummiunterlegscheiben vom Gehäuse entkoppelt

Vorher war das ganze Gerät am brummen jetzt hört man noch das Lüfterrauschen und die Festplattenzugriffe (falls überhaupt aktiv). Nur wenn’s im Gehäuse zu warm wird dreht der geregelte Gehäuselüfter auf und das ist doch recht laut.

Neuinstallation / AMD-Eigenheiten

Vom XBMCbuntu-ISO gibt es auf der Webseite 2 Versionen – eine für Intel/Nvidia und ein andere für AMD. Da ursprünglich die Nvidia-Version installiert war und jetzt eine AMD-Grafikkarte Dienst tut hab ich mich entschieden das Ganze mit der AMD-Version neu aufzusetzen. Die Recherche um herauszufinden was der Unterschied ist (Sind es nur die Treiber oder doch noch was anderes?) und die notwendigen Konfigurationen manuell nachzuziehen hätte wahrscheinlich länger gedauert.

Dank der Dokumentation auf dieser Seite (incl. Zusammenfassung der Konfiguration) ging die Neuinstallation recht zügig und der ursprüngliche Stand der Dinge war schnell wieder hergestellt.

Unter XBMCbuntu ist keine xorg.conf aufzufinden. Keine Ahnung warum trotzdem alles funktioniert. Jedenfalls braucht man diese Datei um an der Konfiguration zu schrauben d.h. mit folgendem Befehl wird eine erzeugt:

aticonfig --initial --nobackup

Wenn man die Auflösung des Desktops anpassen muss (da das TV-Gerät aktuell nur HD-ready ist passen die 1920×1080 im Desktopbetrieb nicht ganz) stolpert man darüber dass das AMD-Tool root-Rechte möchte aber die superuser-Version aus dem Startmenü nicht startet. Folgender Befehl aus einem root-Terminal gestartet schafft Abhilfe:

amdcccle

Interssanterweise hat die Anzeige der GPU-Temperatur (unter System->Systeminfo->Grafik) in der XBMC-Live-Version funktioniert nach Installation erscheint nur ein Fragezeichen. Das von XBMC genutzte bash-Script gputemp sah bei genauerer Betrachtung noch sehr auf Nvidia zugeschitten aus. D.h. so tiefgreifend sind die Unterschiede zwischen den XBMCbuntu-Versionen doch nicht bzw. diese sind nicht vollständig auf die GPU abgestimmt.

Folgende Änderung hat die Temperaturanzeige wiederbelebt:

vi ~/.xbmc/userdata/advancedsettings.xml

<gputempcommand>export DISPLAY=:0; xhost + > /dev/null 2>&1; /usr/bin/aticonfig --od-gettemperature | grep Temperature | cut -f 2 -d "-" | cut -f 1 -d "." | sed -e "s, ,," | sed 's/$/ C/'<⁄gputempcommand>

Die hohe CPU-Nutzung bei der Anzeige von HD-Material und ein Blick ins xbmc-Log legen den Schluss nahe das etwas mit der VaAPI-Konfiguration nicht stimmt.

less /home/xbmc/.xbmc/xbmc.log
ERROR: VAAPI - unable to initialize display -1 - unknown libva error

Das Tool vainfo verschafft Gewissheit:

apt-get install vainfo
export DISPLAY=:0
xhost +
vainfo
libva: VA-API version 0.32.0
libva: User requested driver 'xvba'
libva: Trying to open /usr/lib/va/drivers/xvba_drv_video.so
libva: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Anscheinend wird die Bibliothek xvba_drv_video.so nur unter /usr/lib/va/drivers/ erwartet. Das Verzeichnis existiert aber gar nicht. D.h. die Datei wird aufgespürt und an diese Position verlinkt:

mkdir -p /usr/lib/va/drivers/
cd /usr/lib/va/drivers/
ln -s /usr/lib/i386-linux-gnu/dri/xvba_drv_video.so .

Das Ergebnis sieht schon freundlicher aus:

export DISPLAY=:0
xhost +
vainfo
libva: VA-API version 0.32.0
libva: User requested driver 'xvba'
libva: Trying to open /usr/lib/va/drivers/xvba_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA-API - 0.7.8
vainfo: Supported profile and entrypoints
VAProfileH264High               : VAEntrypointVLD
VAProfileVC1Advanced            : VAEntrypointVLD

Damit XBMC auch von der Änderung profitiert wird dieser neu gestartet:

service lightdm restart

Grafikkarte von vorn

Da die ausgewählte Grafikkarte mechanisch nicht ins Gehäuse gepasst hat und auch keine andere  der passiven Karten mit Geforce GT 640 Chip sich verbauen lässt müssen die Überlegungen neu angegangen werden. Auf allen anderen Karten mit Nvidia-Chip die zur gewünschten Leistungskategorie gehören ist ist ein luftverwirbelnder Geräuscherzeuger verbaut. Somit wird wohl doch ein AMD-Chip auf einer passiven Karte seine Linux-Tauglichkeit beweisen müssen.

GPU Bench- mark dolphin-emu Einstufung interne Auflösung (Dolphin) ca. Preis 05/2013
Radeon HD 6850 2200 Excellent 4x (2560×2112)
Radeon HD 7750 1601 105,00 €
Geforce GT 640 1299 90,00 €
Radeon HD 6670 1050 85,00 €
Nvidia 8800GT 759 Good 2.5x-3x (1600×1320–1920×1584)
Radeon HD 6570 748 55,00 €
GeForce GT 630 724 55,00 €
GeForce GT 520 365 40,00 €
ATI HD3650 178 Average 1x-1.5x (640×528–960×792)
Intel HD 4000 480 Bad
Intel HD 3000 320 Bad

Im Bereich um den ursprünglich ausgewählten Chip befinden sich die  Radeon HD 6670  und die HD 7750 für die es passive Karten gibt die auch ins Gehäuse passen. Das mehr an Leistung und die um 8W geringere TDP (55W statt 63W) sprechen für den moderneren Chip HD 7750. Somit werde ich mit der HIS Radeon HD 7750 iSilence 5 mein Glück versuchen.

Systemoptimierungen

Im allgemeinen und im speziellen bei SSDs macht die Mountoption atime nicht viel Sinn da unnötig Schreibzugriffe generiert werden. Eine kurze Überprüfung liefert die Erkenntniss dass bei den meisten Distributionen relatime als Standard etabliert wurde und an dieser Stelle kein Optimierungsbedarf besteht:
cat /proc/mounts | grep /dev | grep -v devpts | grep -v udev
/dev/disk/by-uuid/c4c733d9-c498-4641-ad24-15710e06681b / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/sda3 /home ext4 rw,relatime,data=ordered 0 0
/dev/sdb1 /data ext4 rw,relatime,data=ordered 0 0
/dev/sda2 /var ext4 rw,relatime,data=ordered 0 0

Anders sieht es bei den tmp-Verzeichnissen aus:
vi /etc/fstab

Das /tmp-Verzeichnis wird in den reichlich vorhanden RAM gelegt und auf 2GB begrenzt:

tmpfs /tmp tmpfs nosuid,size=2G 0 0

Das Verzeichnis /var/tmp wird als Symbolischer Link auf /tmp umgelegt:
cd /var
rmdir tmp
ln -s /tmp tmp

Nach 20 Minuten Inaktivität auf der grossen Datenplatte sollte feststehen das gerade was anderes genutzt wird und diese in den Spindown gehen kann:
vi /etc/hdparm.conf

/dev/sdb {
 spindown_time = 240 # 20 min
 }

Beim Herunterfahren des Rechners macht die Platte jedoch wieder einen SpinUp. Um das zu verhindern muss die Platte mit autofs gemountet werden:

umount /data
vi /etc/fstab

Der Eintrag für sdb1 wird in der /etc/fstab auskommentiert.

vi /etc/auto.master

/media/mydata /etc/auto.data --timeout=300,defaults

blkid
/dev/sda1: UUID="56f8b868-cc54-49b7-9e53-44c8b0fb84c9" TYPE="ext4"
/dev/sda2: UUID="f38f0f84-be21-41d1-9e42-ae881b542695" TYPE="ext4"
/dev/sda3: UUID="33b50961-d98b-4559-9365-83c9f5c7c3cd" TYPE="ext4"
/dev/sdb1: UUID="79ec9ce2-9dcd-4b79-b883-3340628d032a" TYPE="ext4"

vi /etc/auto.data

data -fstype=ext4 :UUID=79ec9ce2-9dcd-4b79-b883-3340628d032a

mkdir /media/mydata
rmdir /data
ln -s /media/mydata/data /data
service autofs restart

Jetzt wird sdb1 automatisch gemountet wenn auf /data/… zugegriffen wird. Nach 5min ohne weiteren Zugriff erfolgt ein automatischer umount und nach weiteren 20min der Spindown. Wenn jetzt der Rechner runtergefahren wird während die Platte im Standby ist dürfte sie nicht wieder hochfahren da sie nicht mehr im Dateisystem hängt.

Aktivierung Gehäusedisplay

Um das Gehäusedisplay zur Arbeit zu übereden muss das richtige Kernelmodul geladen sein. Beim OrigenAE S14V ist ein VF310 als VFD/IR-Modul verbaut und somit imon das Kernelmodul der Wahl. Unter XBMCbuntu wird dieses automatisch erkannt:
lsmod | grep imon
imon

Dann muss noch der passende Dienst installiert werden:
apt-get install lcdproc

In der Konfiguration des lcdproc sind einige Anpassungen vorzunehmen:
vi /etc/LCDd.conf

Der richtige Treiber soll verwendet werden:

[server]
Driver=imon

Wenn kein Programm (in meinem Fall XBMC) das Display verwendet soll es nichts anzeigen. Andernfalls würden technische Infos zum lcdproc-Dienst erscheinen – was ich nicht möchte:

ServerScreen=blank

Eine Willkommens- und Abschiedsmeldung soll auf dem Diplay nicht angezeigt werden:

Hello=""
Hello=""
GoodBye=""
GoodBye=""

Der Treiber des lcdproc muss das richtige Device verwenden:

[imon]
Device=/dev/lcd1

Der Dienst soll auch atomatisch gestartet und beendet werden:
update-rc.d LCDd defaults

Und sofort auch mit der neuen Konfiguration laufen:
/etc/init.d/LCDd restart

Im XBMC wird das Display dann unter System -> Einstellungen -> System -> Video-Hardware -> LCD/VFD benutzen aktiviert. Ggf. muss XBMC neu gestartet werden.

Aufbau

Zusammenschrauben

Nachdem am Freitag das Gehäuse und am Samstag die noch fehlenden Innereien geliefert wurden ging’s endlich los.

HTPC-Komponenten

HTPC-Komponenten

Der Zusammenbau hat weitestgehend problemlos geklappt. Nur die Grafikkarte hat leider nicht ins Gehäuse gepasst da die Heatpipe-Röhren zu weit oben über die Karte hinausragen. D.h. die Karte geht zurück zum Händler und ich muss mir erneut Gedanken machen. Solange kann ich zum Glück die Onboard- bzw. inCPU-Grafik nutzen.

Für die SSD hab ich natürlich (wiedermal) den Einbaurahmen vergessen zu kaufen – aber die kann übergangsweise auch so im Gehäuse rumliegen. Da ich aber sowiso eine andere Grafikkarte kaufen muss und noch ein paar Komponenten zur Lärmbekämpfung brauch (dazu später mehr) ist das kein Problem.

Kleiner Tipp noch zum Einbau des optischen Laufwerks in ein OrigenAE-Gehäuse: Vor dem Einbau die Frontblende der Schublade entfernen sonst macht man das Ganze zweimal – denn einmal eingebaut geht die Schublade nicht auf wenn die Blende noch dran ist.

 
Installieren

XBMCbuntu installiert sich praktisch von allein. D.h. USB-Stick einstöpseln oder CD einlegen booten, Installation wählen und durchklicken. Nur bei der Partitionierung sollte man sich ein paar Gedanken machen und berücksichtigen dass XBMC die Konfiguration, Plugins, Fanart, Coverbilder etc. unter /home speichert. Ich habe folgende Aufteilung gewählt:

Filesystem Size Used Avail Use% Mounted on
/dev/sda1 19G  2.0G  16G 12% /
/dev/sda3 34G  1.8G  30G  6% /home
/dev/sda2 7.4G 667M 6.4G 10% /var
/dev/sdb1 2.7T 271G 2.5T 10% /data

Out-of-the-box funktioniert dann schonmal der Mediaclient, die Fernbedienung (leider nicht alle Tasten) und die Desktopumgebung Openbox (letztere leider nur mit englischem Tastaturlayout).

Damit ich mich mit dem VI leichter tu und auch remote auf dem Rechner was machen kann hab ich erstmal ein paar nützliche Sachen installiert:
apt-get install vim openssh-server firefox

Ach ja, das da oben kein sudo steht ist Absicht. Um das nicht jedes mal zu tippen wenn man unter Ubuntu was als root machen muss, kann man auch einfach eine root bash aufmachen:
sudo bash

 

Alles zusammen sieht dann erstmal so aus (Das funktionierende Display ist schon ein Vorgriff :-)):

Alles zusammen

Alles zusammen

Wii-Sensorleiste am HTPC

Um die Wiimote am PC betreiben zu können brauchts eine Bluetooth-Verbindung zur Kommunikation und eine Infrarot-Lichtquelle zur Positionsbestimmung. Testhalber kann man für letzteres 2 Teelichter im Abstand von 30 cm nehmen – als Dauerlösung allerdings ungeeignet. Im Fachhandel werden Kabellose Sensorleisten angeboten. Diese benötigen jedoch wieder Batterien und ich gehe davon aus, dass man meistens vergisst das Ding auszuschalten. Daher möcht ich einfach die kabelgebunde Sensorleiste am PC anstöpseln. Dafür brauchts eine passende Buchse und die richtige Spannung. Man nehme ein Verlängerungskabel für die Wii Sensorleiste, ein Lüfter Adapterkabel 12V auf 7V und ein Dummy-Slotblech. Die beiden Kabel werden mehr oder weniger mittig getrennt und passend mit Abisolierer, Lötkolben und Schrumpfschlauch bearbeitet (Beim Wii-Verlängerungskabel ist jeder Litzendraht mit Isolierung bedampft – hier hilft ein Feuerzeug um das Metall für jede Ader freizulegen).
In das Slottblech wird eine für die Buchse passende Öffnung gebohrt und gefeilt.

Zubehör Wiimote-Anbindung

Zubehör Wiimote-Anbindung

Die Buchse wird noch im Slotblech befestigt und schon haben wir einen passenden Anschluss mit 7V aus dem PC-Gehäuse geführt der automatisch mit dem Rechner an- und ausgeschaltet wird.

Fertiges Slotblech

Fertiges Slotblech

Bestellodyssee

So, nachdem Anfang Februar die Bestellungen für die Komponenten rausgingen passierte grösstenteils erstmal … nichts. Wie sollte es anders sein war das Gehäuse für fast 2 Monate in ganz Europa nicht lieferbar. Letzte Woche war eben dieses bei einigen Händlern wieder auf Lager nur dort wo meine Bestellung auf Halde lag natürlich nicht. Somit hieß es teilweise stornieren und woanders bestellen. Jedenfalls sollte in Kürze alles da sein und dann gehts hier weiter.

Gedanken zum Gehäuse und sonstigen Hardware-Innereien

Die Auswahl eines passenden HTPC-Gehäuses wurde von folgenden Faktoren bestimmt:

  • einigermassen gut aussehen
  • Standard-HIFI-Komponenten-Breite (ca. 43cm) und maximal 40cm Tiefe
  • gut lesbares Frontdisplay

Nimmt man diese Anforderungen zusammen und tütet diese beim Heise Preisvergleich ein bleiben leider nur die Gehäuse des teuersten Herstellers (Origenae) übrig. Gilt es nur noch die Entscheidung zwischen schwarz und silber sowie 11,5cm, 15cm oder 17,5 cm Höhe zu treffen und (zähneknirschend) zu aktzeptieren, dass dies die teuerste (aber auch die schickste ;-)) Komponente des ganzen Unterfangens wird.

Bei der TV-Karte gibt es nur zwei Anforderungen – S2-Doppeltuner und problemlose Funktionalität unter Linux. Da ich mich schon viel zu oft über meine HVR4000 geärgert habe und es in diversen Foren nichts Gutes zu Hauppauge in Verbindung mit Linux zu lesen gab ist dieser Hersteller aussen vor. Mehrfach positive Erwähnung fanden dagegen Karten von Digital Devices in verschiedenen HTPC-Foren. Somit werde ich mein Glück mit einer Digital Devices Cine S2 V6 probieren.

Auf dem Mainboard sollen alle Komponenten Platz finden der Formfaktor zum Gehäuse passen und es sollte einigermassen preiswert sein. Zusätzlich sollte es USB3 einen optischen Digitalausgang für Audio und (um alle Optionen offen zu haben) eine Infrarotschnittstelle besitzen. Mit diesen Anforderungen bin ich nach Eingabe der Parameter in eine beliebte Preisvergleichsseite beim ASRock B75 Pro3-M gelandet.

Die restlichen Komponenten wurden primär von einem recht informativen c’t-Artikel inspiriert oder nach persönlichen Vorlieben bzw. den preislichen Rahmenbedingungen ausgewählt.

 

Intel, nVidia oder AMD – die Grafikkartenfrage

Es wäre schön gewesen auf eine separate Grafikkarte verzichten zu können. Doch mehrere Gründe sprechen dagegen. Zum einen können moderne Grafikkarten die CPU bei der Dekomprimierung von Videomaterial  gewaltig (thermisch) entlasten (vdpau und vaapi), d.h. trotz eines zusätzlichen Bauteils mit eigener Verlustleistung sollte der Bedarf an Wärmeabtransport trotzdem geringer ausfallen. Auf der anderen Seite erfordern die Empfehlungen/Vorgaben des Emulators Dolphin den Einbau einer Grafikkarte von AMD oder nVidia um hohe Auflösungen zu erzielen.

Analog zur Auswahl der CPU soll ein Vergleich von Benchmarkwerten die Entscheidungsfindung unterstützen. Die persönliche Erfahrung das Grafikkarten von nVidia unter Linux meist problemlos funktionieren sprechen für eine GPU von diesem Hersteller. AMD (vormals ATI) konnte an dieser Stelle noch keine Pluspunkte sammeln auch wenn die Firmenpolitik bzgl. Dokumentationsveröffentlichung gewürdigt werden sollte.

GPU Bench- mark dolphin-emu Einstufung interne Auflösung (Dolphin) ca. Preis 01/2013
AMD HD6850 2200 Excellent 4x (2560×2112)
Geforce GT 640 1299 90,00 €
Nvidia 8800GT 759 Good 2.5x-3x (1600×1320–1920×1584)
GeForce GT 520 365 40,00 €
ATI HD3650 178 Average 1x-1.5x (640×528–960×792)
Intel HD 4000 480 Bad
Intel HD 3000 320 Bad

Mit einer preiswerten Grafikkarte (<50€) bekommt man leider keine interne HD-Auflösung im Wii-Emulator. Eine 4-fache interne Auflösung ist meines Erachtens jedoch übertrieben und treibt den Preis der Grafikkarte sinnlos nach oben. Ausserdem konnte ich in diesen Leistungsgefilden keine passive Karte (d.h. ohne eigenen Luftquirl) finden. Somit wird wohl eine passiv gekühlte Grafikkarte mit Geforce GT 640 Chip verbaut.