Beiträge von frosch01

Suche mal N3700M. Da habe ich meine Erfahrungen zusammengetragen. - Es ist nicht gerade rosig -

Oder man steckt sich noch eine PCI Karte rein. Man hat ja 3 freie Slots. Pro Steckplatz bekommt man 2 SATA Ports dazu.

Ich habe auch schon überlegt johns zu fragen, ob er bei einer HW Spende bereit wäre, sich die Probleme mal anzusehen. Ich meine das Deintetlacing klappt bei älteren Intel Chipsätzen besser.

Danke. Genau die Info hatte mir gefehlt.

Ich habe die Parameter inzwischen in /etc/default/grub angepasst. Nur mit "splash" und "quiet" klappt es nicht, da der Kernel dann irgenwie einen Resume machen möchte. Die "noresume" Option war bei mit also auch noch nötig.

Ansonsten scheint das System zu laufen. Die Fehlermeldungen beim Booten sind verschwunden.

Ein Rückmeldung bezüglich des korrekten Vorgehens (voriger Beitrag) wäre super, damit die Einstellungn auch überdauern.

Hallo,

ich habe das Schwesterboard N3700M gekauft und experimentiere damit gerade so wie es meine Freizeit zulässt. Ich habe mit für das uATX entschieden, da ich mit der Intel-HW nicht ganz sicher war und ich dann ggf. auf eine NV-Karte ausweichen kann. Ich habe das Ganze hier beschrieben:

N3700M Mainboard-Vorstellung

Weitere Posts könnt ihr verfolgen, indem ihr mal meine letzten Posts anseht.

Mit der Grafik bin ich inzwischen so weit, dass ich davon ausgehe, dass mit dem aktuellen softhhdevice leider keine perfekte Videoausgabe hinzubekommen ist. Mit Deinterlacer hat man ein Zittern, ohne die Streifen. 720P (ARD/ZDF) ist spitzenmäßig. Der GLX-Code im Softhddevice führt beim aktuellen Grafikstack zu einem Segfault. Das habe ich sowohl beim hochgerüsteten yavdr (14.04) als auch unter Wily mit selbstcompilierten vdr/plugin (15.10). Der MPV zeigt aber, dass die HW es probzipiell kann.

Fazit: Wenn man das Board als Video-Server verwendet (mein Anwendungsfall) ist es ok, für einen HTPC aus diesen Gründen leider nicht.

Hallo yavdr-Experten,

vielen Dank für die Rückmeldungen. Ich möchte aber nochmal nachhaken. Wenn ich in die Datei /etc/default/grub schaue, finde ich den Hinweis, dass man die Datei nicht manuell editieren soll:

#################################################################################
#                                                                           	#
#   The following configuration file is generated automatically by the yaVDR	#
# 	system. Don't change this file as every update of yaVDR will overwrite	#
#     	the local changes. Instead put your required customizations       	#
#   	into /etc/yavdr/templates_custom/ based on the original templates   	#
#                  	under /usr/share/yavdr/templates.                    	#
#                                                                           	#
#        	http://www.yavdr.org/developer-zone/template-overview/         	#
#                                                                           	#
#                                                                           	#
################################################################################

Darum wollte ich das nicht machen und habe nach dem yavdr-Weg gefragt.

Hallo yavdr-team,

ich bekomme beim Booten immer eine Fehlermeldung wegen dem acpi_enforce_resources Kernel-Parameter. Auch das Setzen der vmalloc Größe oder die nohz option sind eher unüblich. Gibt es Gründe, weshalb diese Einstellungen aktuell noch aktiv sind?

GRUB_CMDLINE_LINUX_DEFAULT="vmalloc=256m quiet splash noresume nohz=off acpi_enforce_resources=lax"

Wie sollte man vorgehen, wenn man daran testweise etwas ändern möchte?

Hallo,

ich habe eben in die Einstellungen für das VNSI Plugin gesehen. Das Deutsche Menü hat bei mir ein paar Schönheitsfehler:

1. Die Texte sind zu lang, man kann den Text nicht vollständig lesen -> Das muss wohl direkt beim Plugin rückgemeldet werden.
2. Umlaute werden falsch dargestellt. -> Könnte evtl. am Build hängen.

Kann das jemand nachvollziehen?

1000-faches Dankeschön.

Hallo Frodo,

eben an den vdr gesetzt und <tab> gedrückt -> keine Menü. Dann svdrpsend ausgeführt und das Menü kam wieder.

Jetzt muss ich nur noch herausfinden, welches Bediengerät das anstellt. Auf jeden Fall: Danke für den Tipp!

Ich würde mich darauf konzentrieren, xine als Standaloneprogramm ans Laufen zu bekommen. Wenn schon das nicht geht wird es mit sfxe auch nichts.

Um das Audioproblem zu umgehen, kannst du mal die Option -A null versuchen. Dann wird einfach kein Ton ausgegeben.

Kannst Du mit xine irgedein video wiedergeben? Installiere mal xine-ui und versuche es damit.

Startest Du vdr-sxfe unter dem User, der am Desktop eingeloggt ist?

Hallo Leute,

ich habe mir vor einiger zeit ein N3700 basiertes MB geholt (Intel Grafik) und Versuche damit ein anständiges Videobild über das softhddevice hinzubekommen. Die Versuch mit yavdr 0.6 waren leider nicht so richtig erfolgreich, da sind einfach einige Dinge noch zu angestaubt. Unter Wily habe ich mit mpv ein sehr gutes Bild, also hatte ich die Hoffnung, dass sich das auch auf den vdr mit softhddevice übertragen lässt. Da es in Sachen vdr für wily mit Paketen recht schlecht aussieht, habe ich die Quellen für den vdr 2.2.0 samt dem softhddevice aus dem master branch geholt und übersetzt. Die Sache klappt mit -v va-api, mit -v va-api-glx stürzt der vdr mit einem Segfault ab.

Ich hatte abgespeichert, dass Johns die Option -v va-api zugunsten der -v va-api-glx Ausgabe abschaffen wollte. Außerdem gibt es bei interlaced Videos in SD und HD ein vertikales Zittern. Irgendwie springt das Bild mit jedem neuen Frame ein Zeile hoch und dann wieder zurück. Bei Text fällt das besonders auf. Keine Ahnung wie man diesen Effekt korrekt benennt . Das Verhalten ist aber abhängig vom Deinterlacing. Schalte ich den Deinterlacer ab, ist das Zittern weg, dafür hat man dann die Kämme. Wenn ich das selbe Video mit mpv wiedergebe habe ich diesen Effekt auch mit aktivem Deinterlacing nicht. Darum wollte zuerst noch der glx Ausgabe ein Chance geben. Den Compositor des (kde) Desktops habe ich abgeschaltet. Das änderte am Verhalten aber nichts.

Im Syslog findet sich nichts Auffälliges.

Ich habe aktuell folgende Bibliotheken installiert (wily + 01.org):

• libgl1-mesa -> 11.0.4-1-intel1
• libglu1-mesa -> 9.0.0.2
• libva -> 1.6.2-1
• i965-va-driver -> 1.6.2-1
• kernel -> 4.3.3
• xserver-xorg-video-intel -> 2.99.917+git20150808-0ubuntu4
• ffmpeg -> 2.7.6-0ubuntu0.15.1

Hat vielleicht jemand einen Tipp, wie ich die GLX-Ausgabe hinbekomme oder das Zittern abgestellt werden kann?

Vielen Dank für die Rückmeldungen. Aktuell läuft der vdr wieder anstandslos. Ich melde mich erst jetzt, da ich beruflich in den Staaten tätig war. Jetzt an den vdr gesetzt und das Menü war sofort da.

In /srv/vdr/videos finden sich tatsächlich ein paar Links, die aber alle gebrochen sind. Wenn es das nächste mal auftritt, werde ich das prüfen! Das mit dem svdrp-Kommando kann ich mir irgenwie nicht vorstellen. Da macht keiner etwas be meinem vdr. Aber ich werden es auch im Auge behalten.

Bei mir reagiert der vdr nach einiger Zeit auch nicht mehr auf
Eingaben. Dabei ist es egal, ob diese von der Fernbedienung oder von
einer Tastatur kommen. In anderen Programmen läuft die Tastatur auch wenn der vdr nicht reagiert. Wenn ich irw starte, bekomme ich auch eine Reaktion auf
die Fernbedienung. Wenn ich dann den vdr neu starte, geht es wieder. Nach einiger Zeit dann
wieder das Selbe. Ansonsten ist die vdr Funktion nicht eingeschränkt.

Im dmesg kann ich absolut nichts Aufälliges entdecken was auf ein input Problem hindeutet. Leider schreibt der DDBridge Treiber gerade ziemlich viel ins dmesg, darum ging mir die Histrorie ein bisschen Flöten, irgendein Timeout. Das kommt 2-5 Mal pro Sekunde. Nach dem letzten Suspend ist aber wieder Ruhe damit.

Zitat

[152326.832060] DDBridge I2C timeout, card 0, port 0, link 0
[152326.832080] ddbridge 0000:02:00.0: DDBridge IRS 000000f1

Um Syslog finden sich jede Mange von diesen Meldungen (und natürlich auch die von dmesg). Da sucht man nach einer Stecknadel im Heuhaufen....

Zitat

Feb 18 11:21:45 vdr vdr: [softhddev] empty video packet 7955 bytes
Feb 18 11:21:45 vdr vdr: [softhddev] empty video packet 7339 bytes

Im Moment läuft er wieder, nachdem ich den vdr (sudo service vdr restart) gestern neu gestartet hatte. Inzwischen war der vdr im s2ram Zustand und nach dem wieder Aufwachen ging alles wie gewohnt. Damit scheint es also nicht zusammenzuhängen.

Bei mir reagiert der vdr 0.6 nach einiger Zeit auch nicht mehr auf Eingaben. Dabei ist es egal, ob diese von der Fernbedienung oder von einer Tastatur kommen. Ich schreibe gerade auf dem System, das Keyboard ist also i.O.. Wenn ich irw starte, bekomme ich auch eine Reaktion auf die Fernbedienung.

Wenn ich den vdr neu starte, geht es wieder. Nach einiger Zeit dann wieder das Selbe. Ansonsten ist die vdr Funktion nicht eingeschränkt.

Aktuell läuft eine Aufnahme. Wenn die durch ist, starte ich mal neu. Evtl hängt es mit dem syspend zusammen. Ich fahre das System nicht runter, sondern schicke es schlafen.

Bzgl der Frage von Boss666: Man sollte danach, wie in der PPA-Anleitung beschrieben, ein apt-get dist-upgrade durchführen.

Vielen Dank für die Anleitung. Sie dient mir gerade als gute Basis für eigene Experimente mit meinem N3700M Mainboard. Ich habe das Mainboard (und was damit so geht) hier ausführlicher beschrieben:

N3700M Vorstellung

Das N3700M SoC ist von 2015 und dürfte verlustleistungsmäßig auf Basis Intel das Beste sein was es aktuell gibt. Allerdings ist der i965-va-driver in der Version 1.3 wie er bei Trusty mitgeliefert wird nicht ausreichend. Schon vainfo lässt sich damit nicht starten. Im oibaf Repo wird leider kein aktueller Treiber mitgeliefert. Ich bin daum auf das XEdgers repo gegangen: ppa:xorg-edgers/ppa. Da liegt der Treiber in der Version 1.5 vor.

Damit klappt es dann mit vainfo und auch mit der Option -v va-api-glx im softhddevice. Die Bildqualität ist leider nicht 100%tig optimal bei interlaced Videos. Das Bild flimmert vertikal, das Deinterlacing ist an sich aber i.O.. Bei einem Vergleich mit mpv unter wily wird der Unterschied dann aber deutlich. Das Flimmern betrifft sowohl 576i als auch 1080i Videos. 1080p läuft ohne Schwierigkeiten, Mit der Option -v va-api habe ich kein Deinterlacing in der Ausgabe hinbekommen.

Als ich mit dem oibaf-PPa wie im Thread beschrieben begonnen hatte, waren zeitweise sowohl dieses als auch das xedgers PPA aktiv. Inzwischen habe ich geprüft, dass die Mischung nur dann läuft, wenn man zuerst das oibaf PPA einspielt und danach das xedgers PPA. In der umgekehrten Reihenfolge läuft die Sache nicht. Am Stabilsten ist die Sache dann auch in dieser Kombination.

Update vom 07.02.16: Inzwischen konnte ich das Flimmerproblem etwas verbessern. Dazu habe ich das i965-va-driver Paket von wily in der Version 1.6.2-1 übersetzt und installiert. Das Paket hat in Trusty die Version 1.3, im xedgers PPA die Version 1.5. Bei stehendem Text sieht es noch recht mau aus. Die Bildränder sind jetzt aber stabil und auch Standbilder ohne Text sehen gut aus. Ich werde als nächstes mal sehen, ob das es dann auch nur mit dem oibaf PPA (ohne das xedgers PPA) und dem aktuellen i965-va-driver läuft.

Ich würde das Paket gerne zur Verfügung stellen, mein Attachment Limit ist aber leider zu klein

Leider nein. Der Fehler ist im 4.2 Kernel noch drin. Es ist wohl eher ein BIOS Problem. Asrock hat wohl ein Feature des Memory Controllers deaktiviert aber im Trwiber implizit als aktiv angenommen wird. Dann gibt es einen Fehler. Siehe hier:

Beitrag im freedesktop forum

Es gibt zwar keinen Uups mehr mit dem Kernel 4.2 aber noch einen Error. Hat wohl etwas mit Power Management und Takt zu tun....

Aber ich werde die Tage mal yavdr 0.6 einen Versuch geben. Mal sehen was so läuft. Für den Grafiktreiber findet man bestimmt auch updates, z.B. bei Xedgers.

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=128m

stress, 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
-D

Das 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 vdr

Zuerst 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_pulse

Damit 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 atta

Ggf. 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 deta

Ich 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.target

Das Modul muss nun noch aktiviert werden:

systemctl enable ddbridge-sleep.service

Jetzt 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 0

Um 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-upgrade

Nach 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-api

Ich 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.