Hallo Forum,
ich habe diesen Artikel aktualisiert. Ich hoffe das geht so i.O. Wer den Artikel als Anleitung braucht wird froh sein, wenn er sich nicht durch die Beiträge quälen muss.
Motivation: Ich ärgerte mich seit längerer Zeit über mein bestehendes VDR System. Es basierte noch auf dem Atom 330 und hat einen externen NVIDIA Chipsatz. Sowohl der Energieverbrauch (>35W) im VDR Betrieb als auch die Rechenleistung der CPU haben mich von Anfang an nicht wirklich überzeugt. Also musste ein neues Board her. Das N3700M von Asrock ist ein uATX Board und hat 3 PCIe Steckplätze. Damit bin ich flexibler falls es doch nichts wird mit der HW Beschleunigung beim HD Dekodieren. Die onboard CPU liefert Pentium Performance, ist in 14nm gefertigt und gönnt sich max. 6W. Das ist cool, im wahrsten Sinne des Wortes 
Auch cool ist, dass Asrock offiziell Ubuntu als unterstützes Betriebssystem angibt: http://www.asrock.com/mb/Intel/N3700M/?cat=Specifications. Ich hatte den Plan auf yavdr 0.6 zu setzten, was sich aber als sehr schwierig erwiesen hat. Dazu gleich noch 1-2Sätze. Intermediate hatte ich dann Ubuntu Wily drauf, inzwischen bin ich aber bei Xenial und möchte dies auch als Basis nehmen, da das System sehr zuverlässig läuft.
HW-seitig sieht das System so aus:
* N3700M Mainboard
* 2x4GByte DDR3L-1600 (1,35V),
* 80W pico PSU
* 120W Leicke ext. 12V (10A) Netzteil,
* 3,5'' HDD (war nur für die ersten Tests drin)
* 1280x1024 Monitor (Röhre, VGA).
Suspend to RAM läuft super. Das System schläft in weniger als 1s ein und wacht ebenso schnell wieder auf. Die HW ist wirklich toll. Das selbe gilt für den ACPI-Wakeup und Wake on LAN. Ein echtes Schmankerl ist das BIOS/die Firmware. Die ist grafisch und kann sich selbst aktualisieren. Dazu ist ein IP-Stack integriert samt DHCP und was man sonst so braucht. Da wird so manches "Profi"-Mainboard neidisch.
Kubuntu 16.04 (Xenial)
Sowohl die Installation als auch danach läuft das Board sauber und unauffällig. Enthalten sind bereits die aktuellsten die Intel-Treiber, die in der Konfiguration problemlos laufen.
Zu meinen HD Wiedergabe Tests: Ich habe mit mpv und kodi mal nachgesehen, was die interne Intel HD GPU so kann. Dazu habe ich Demo Videos sowohl in 1080p als auch 1080i aus dem Internet besorgt und angesehen. Das Ergebnis ist völlig zufriedenstellend. Das Deinterlacing arbeitet über BOB Niveau, alle Streifen wurden weggebügelt und waren im bewegten Bild nicht mehr erkennbar. Das Deinterlacing habe ich mit <d> zugeschaltet. Ich habe folgende Parameter verwendet:
$ mpv --hwdec=vaapi --vo=opengl
Mit Kodi ging einfach starten und los bei gleicher Bildqualität 
Während den Tests hat sich der nicht wirklich große Kühlkörper ohne aktive Belüftung nicht einmal auf Handtemperatur erwärmt. Aber ich habe natürlich nachgemesen. Dazu habe ich ein Multimeter zur Strommessung zwischen ext. Netzteil und Pico PSU gehängt. Hier die Ergebnisse:
Power Off, nachdem die Stromversorgung eingesteckt wurde: 85mA (~1W)
Power Off, nachdem der Rechner einmal an war: 59mA (~0,7W)
im BIOS, ohne HDD: 530mA (~6,5W)
im BIOS, mit HDD: 1215mA. Es war noch ein 5,5'' HDD. Inzwischen setzte ich auf ein 1750MB HDD im 2,5'' Format.
Also zieht das gesamte Mainboard gerade mal 6,5W im Idle. Das HDD zog mehr als das Board! (685mA, 8,2W).
Während dem Booten/Login: max. 1840mA (war wohl das HDD)
KDE Desktop, Idle: 1200mA
Kodi über KDE-Desktop gestartet, Idle: 1400mA
Kodi, 1080i Video: Min 1370mA, Max 1750mA, Normalwert ca. 1400mA
Kodi, 1080p Video: Min 1240mA, Max 1470mA, Normalwert ca. 1330mA
mpv, 1080i Video: Min 1400mA, Max 1510mA, Normalwert ca. 1440mA
mpv, 1080p Video: Min 1250mA, Max. 1560mA, Normalwert ca. 1300mA
Die CPU-Temperatur blieb unter 40°C! Das HDD hat immer mal wieder gerappelt, somit waren schon ein paar Spitzen drin. Kubuntu servt ja auch immer ein bisschen nach Updates....
Dann habe ich nochmal etwas härter versucht das System ins Schwitzen zu bekommen:
$ stress --cpu=4 --io=2 --vm=1 --vm-bytes=128mstress, ohne Video: 1900mA, ~70°C nach 10 Minuten
stress + mpv 1080i Video: 2000mA, ~73°C nach 10 Minuten
Fazit zur HW: Wenn man die CPU nicht stresst reichen mit dem Board 750mA (10W) um ein HD Video zu dekodieren. Mit Low Power HDD und DVD-S2 Karte sollten es dann so 16W sein. Ist die Video-Ausgabe deaktiviert sind es nochmal 3W weniger, also 13W für ein komplettes VDR-System und 7W für das Mainboard. Sparen kann man nicht mehr viel, zumindest nicht bei der CPU. Lässt man das System 365/24 laufen und geht von einer Leistung von 15W aus macht das 130KWh Energie und ca. 35€ im Geldbeutel. Leider dürfte da das ext. Netzteil nochmal etwas dazupacken. Da es sich durchaus leicht erwärmt könnten da schon 3W dazu kommen. Vor allem die DVB-S2 Karte wird wohl der Hauptverbraucher werden. Ich hoffe das Anschließen eines HD-Monitors mit der doppelten Auflösung verändert die Ergebnisse nicht zu sehr.
VDR Installation
Wir sind hier ja im vdr Forum, also wird es Zeit auch mein VDR-Setup unter Xenial zu beschreiben. Folgende Plugins waren in zufriedenstellender Version und Konfiguration mit dabei:
* vdr 2.2.0
* vdr-plugin-life 0.3.0 (optional)
* vdr-plugin-vnsiserver 1.3.1 (optional, für Kodi)
* vdr-plugin-epgsearch 1.0.1~beta6+git2 (optional, für Suchtimer)
Weitere Plugins sind vorhanden, ich nutze diese aber nicht. Der Umfang reicht an einen yavdr aber bei weitem nicht heran.
Folgende Plugins habe ich selbst als Debian-Pakete übersetzt. Als Paketquelle habe ich yavdr testing (0.6) verwendet. An dieser Stelle: Vielen Dank für diese Pakete! Beim Plugin vdrmanager gibt es eine fehlende Abhängigkeit die sich leicht manuell nachinstallieren lässt.
* vdr-plugin-vdrmanager 0.14.git20151112.2202-1yavdr2~trusty (optional, für Android App)
* vdr-plugin-vompserver 0.4.1-1yavdr4~trusty (Optional, für RPI-Ausgabe über vomp)
Das softhddevice Plugin geht mit der Intel-HW nicht, auch nicht, wenn man VAAPI Support vor dem Übersetzten des Quellpakets einschaltet. Es wird zwar Bild und Ton ausgegeben, diese laufen aber auseinander und das Deinterlacing bekommt auch nicht ans Laufen. Schade. Der vpp_support Branch aus dem presintta Repository von Antti Seppälä geht dafür um so besser. Nur das Compositing des Desktops habe ich deaktiviert. Das hatte nachteilige Auswirkungen. Ich habe außerdem einige Dinge in dem Code angepasst. Diese Anpassungen habe ich aus diesem Beitrag. Sie sind im Wesentlichen von Johns. Tatsächlich habe ich diese Konfiguration unter Wily erstellt und einfach nach Xenial übernommen. Evtl. braucht es diese Anpassungen unter Xenial auch gar nicht mehr. Das diff ist angehängt. Das Plugin habe ich mit git clone geholt und übersetzt. Die Abhängigkeiten habe ich apt-get build-dep vdr-plugin-softhddevice installiert. Danach habe ich das Plugin nach /usr/lib/vdr/plugins/libvdr-softhddevice.so.2.2.0 kopiert.
VDR Basiskonfiguration
Zur Basiskonfiguration sollte man die Dateien remote.conf und channels.conf nach/var/lib/vdr legen. Diese gibt es ggf. im Internet. Oder einfach mal im Forum fragen.
Für das Softhddevice habe ich folgende Konfiguration verwendet (/etc/vdr/conf.avail/softhddevice.conf)
#
# softhddevice VDR plugin arguments
#
[softhddevice]
-v va-api
-DDas Plugin noch über einen Softlink von /etc/vdr/conf.avail/softhddevice.conf nach /etc/vdr/conf.d/50-softhddevice.conf aktivieren und dann den vdr starten.
systemctl start vdrZuerst solle man im systemd prüfen (systemctl status vdr), was der vdr so macht. Es sollte keine Fehlereinräge von "video" oder "softhddevice" geben (journalctl -u vdr). Um ein Bikld und Ton zu bekommen muss man dem vdr zuerst erlauben auf den X-Server und den Pulse Audio Server zugreifen zu dürfen. Das lässt sich mit folgenden Befehlen erreichen:
xhost +si:localuser:vdr
pactl load-module module-native-protocol-unix auth-anonymous=1 socket=/tmp/shared_pulseDamit sollte das sofhddevice in der Lage sein eine Ausgabe zu erzeugen. Mit dem folgenden Befehlen kann man das softhddevice schließlich starten:
svdrpsend plug softhddevice attaGgf. mit journalctl -u vdr prüfen, was der vdr so macht. Video-Probleme werden i.d.R. über die tags "video" oder "softhddevice" ausgegeben.
Schließen kann man die Video-Ausgabe über:
svdrpsend plug softhddevice detaIch habe das System jeweils 24 Stunden non stop 720p und 1080i Kanäle empfangen lassen und über die GPU ausgegeben, ohne dass etwas abgestürzt wäre. Ich würde sagen, das ist stabil. Wie viel SD-Material auf den Sendern zwischendurch gesendet wurde habe ich nicht geprüft.
Erweiterte Einrichtung
Ich habe eine Cine-S2 DVB-S2 Karte. Wenn man den Rechner in den Suspend schickt, verliert die Karte ihre Konfiguration und der Empfang klappt nicht mehr. Als Abhilfe kann man die Treiber vor dem Suspend entladen und nach dem Suspend wieder laden. Dazu muss auch der vdr gestoppt und wieder gestartet werden. Ich habe das durch folgendes systemd-Modul erreicht, die Idee kam von hier. Das Modul in etc/systemd/system/ddbridge-sleep.service ablegen:
[Unit]
Description=Restart ddbridge
Before=sleep.target
StopWhenUnneeded=yes
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/bin/systemctl stop vdr.service
ExecStart=/sbin/modprobe -r ddbridge cxd2099 dvb_core
ExecStop=/sbin/modprobe ddbridge cxd2099 dvb_core
ExecStop=-/bin/systemctl start vdr.service
ExecStop=-/bin/sh -c 'echo 0 > /sys/class/rtc/rtc0/wakealarm'
[Install]
WantedBy=sleep.targetDas Modul muss nun noch aktiviert werden:
systemctl enable ddbridge-sleep.serviceJetzt sollte das System nach dem Aufwachen vom Suspend wieder ein Videosignal empfangen. Die Ausgabe muss mit svdrpsend wie oben beschrieben neu gestartet werden. Einfach mal probieren.
Also nächstes ging es an den automatischen Suspend, wenn der vdr idle ist und wieder über ACPI geweckt werden soll. Dazu habe ich folgendes Script in /etc/vdr/shutdown-hooks/S90.custom gelegt:
NextTimer=$(($1 - 300 )) # Start 5 minutes earlier
# Set alarm in RTC
DEV=/sys/class/rtc/rtc0/wakealarm
echo "0" > $DEV
echo $NextTimer > $DEV
# Some debugging....
#echo "TRY_AGAIN=1"
#echo $@ >> /tmp/time.log
#exit 1
# Tell vdr to syspend instead of shutdown
echo "SHUTDOWNCMD="/bin/systemctl --no-block suspend""
exit 0Um den Shutdown zu aktivieren, muss noch in /etc/vdr/conf.d/00-vdr.conf der Shutdown einkommentiert werden. Dazu einfach den '#' vor der -s Option entfernen.
Ich hoffe die Anleitung erweist sich für den einen oder anderen als nützlich.
yavdr 0.6
Noch ein paar Informationen zu meinem erfolglosen Versuch, yavdr 0.6 auf der HW ans Laufen zu bekommen:
Die Installation von yavdr verlief unauffällig und ohne Fehler. Nach dem Reboot kam dann aber die Überaschung. Es gab keine funktionierende Grafikausgabe. Es wurde zwar auf den grafischen Bildschirm umgeschaltet, aber dann waren nur Klötze, zunächst weiß auf schwarzem Hintergrund, später schwarz auf weißem Hintergund, zu sehen. Das System lief aber, ich konnte mir per ssh Zugang verschaffen. Beim Versuch in den Grub zu kommen dann die Überraschung. Schon im Grub klappt es mit der Textausgabe nicht. Das Boot-Menü wurde einfach nicht angezeigt.
Also musste ein anderer Grub drauf der die Grafikausgabe richtig initialisiert. Ich habe den Grub von Kubuntu dafür verwendet. Dazu mit dem Stick Kubuntu gebootet und den Grub neu installiert. Bind-Mounts anglegt, chroot und dann grub-install und update-grub. Da gab es dann einen Fehler mit der Externded Partition die irgendwie als Filesystem erkannt wurde. Das hinterließ zunächst ein ungutes Gefühl, nach dem Reboot bin ich aber im Grub Menü gelandet und konnte auch yavdr mit lesbarer Bildausgabe booten. Die Probleme scheinen also primär mit dem Grub zusammenzuhängen. Evtl. ist das ein Hinweis für einen Wissenden aus der yavdr-Gemeinde.
Der Monitor war jetzt in einem interlaced Mode (ich hab grad noch eine Röhre dran). Vom softhddevice habe ich noch kein Bild bekommen, aber die Sidebar funktionierte bereits. 
Ich habe jetzt gar keine Zeit in eine Optimierung investiert sondern mich gleich daran gemacht den Grafikstack zu renovieren. Neben dem Kernel update auf 4.3.3-wily (Update wird hier beschrieben: http://linuxdaddy.com/blog/install-kernel-4-3-on-ubuntu/) habe ich noch das Xedgers ppa eingebunden und alle Pakete aktualisiert:
sudo apt-add-repository ppa:xorg-edgers/ppa
sudo apt-get update
sudo apt-get dist-upgradeNach dem Reboot sieht die Grafikausgabe wie erwartet aus. Das Bild ist flimmerfrei :tup, aber es fehlt noch immer die Ausgabe des softhddevice. Beim Lesen des Syslog wurde dann schnell klar, dass das softhddevice über vdpau versucht die Grafik anzusprechen was für Intel-HW nur mit weiteren Anpassungen geht und von mir irgendwie als Hack wahrgenomen wurde. Also habe ich mittels vdrctl die Option -v va-api zum softhddevice Plugin hinzugefügt. Das geht mit vdrctl wirklich richtig gut. Großes Lob dafür! 
vdrctl edit softhddevice
[softhddevice]
-D
-v va-apiIch habe mich dann durch das Forum gequält und versucht die Sache ans laufen zu bekommen. Da meine Versuche unter Ubuntu quasi sofort zu Erfolg geführt haben, ich unter yavdr aber niemals ein stabiles Deinterlacing hinbekommen habe, habe ich mich schließlich für Kubuntu als Basis entschieden.