Beiträge von dad401

Hallo,

ich glaube die Version hatte ich von hier.

Ich habe den Wert komplett auskommentiert/entfernt.

Der Vollständigkeit halber, hier meine bisher gut laufenden Units:

vdr.service (LimitCORE nur für Testzwecke)

[Unit]
Description=Video Disk Recorder
After=network.target
After=xorg.service inputlirc.service
After=dev-tbscard.device
Requires=inputlirc.service
Wants=vdradmind.service
BindsTo=xorg.service

[Service]
Type=notify
ExecStartPre=/opt/vdr/tools/vdr-exec-start.sh
ExecStart=/usr/bin/vdr
ExecStopPost=/opt/vdr/tools/vdr-exec-stop.sh
Restart=on-failure
RestartSec=3
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

devices (udev)

cat /etc/udev/rules.d/80-tbs-i915.rules
# symlinks and tags for frontend0 of the DVB-S card and for graphic card (drm)
SUBSYSTEMS=="pci", DRIVERS=="cx23885", ATTRS{subsystem_device}=="0x8888", ATTRS{subsystem_vendor}=="0x6981", SYMLINK+="tbscard", TAG+="systemd"
SUBSYSTEMS=="pci", DRIVERS=="i915", ATTRS{subsystem_device}=="0x2212", ATTRS{subsystem_vendor}=="0x1849", SYMLINK+="i915card", TAG+="systemd"

xorg.service

[Unit]
Description=X Server
PartOf=vdr.service
Requires=dev-i915card.device
After=dev-i915card.device

[Service]
ExecStart=/usr/bin/X -br -nolisten tcp :0

[Install]
WantedBy=multi-user.target

=> ohne das require für das DRM-Interface startete der X-Server - nach Nutzung von media_build - immer zu früh und fand kein Device. Mit den Original-Kernelmodulen hatte ich den Effekt nicht. Leider brauche ich die Module für meine TBS Karte aufgrund von "mpeg risc op code error" noch - mit Kernel 4.20 sollte es gelöst sein.

vdradmind.service

[Unit]
Description=vdradmind-am
PartOf=vdr.service
After=vdr.service

[Service]
ExecStart=/usr/bin/vdradmind -d /opt/vdr/config
PIDFile=/var/run/vdradmin-am/vdradmind.pid
Restart=on-failure
TimeoutStopSec=10sec
RuntimeDirectory=vdradmin-am

[Install]
WantedBy=multi-user.target

In vdr-exec-stxxx.sh kann ich die Module nun starten/stoppen - ist aber nicht zwingend notwendig.

killall vdr klappt aber immer noch nicht - scheint wohl am exit code 0 zu liegen:

● vdr.service - Video Disk Recorder
   Loaded: loaded (/etc/systemd/system/vdr.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Mon 2019-04-08 22:06:44 CEST; 8s ago
  Process: 2072 ExecStopPost=/opt/vdr/tools/vdr-exec-stop.sh (code=exited, status=0/SUCCESS)
  Process: 1981 ExecStart=/usr/bin/vdr (code=exited, status=0/SUCCESS)
 Main PID: 1981 (code=exited, status=0/SUCCESS)
   Status: "Exiting"

Apr 08 22:06:43 antecvdr vdr[1981]: video/vaapi: no osd subpicture yet
Apr 08 22:06:43 antecvdr vdr[1981]: video/vaapi: no osd subpicture yet
Apr 08 22:06:43 antecvdr vdr[1981]: video/vaapi: no osd subpicture yet
Apr 08 22:06:43 antecvdr vdr[1981]: [1981] deleting plugin: menuorg
Apr 08 22:06:43 antecvdr vdr[1981]: [1981] deleting plugin: dynamite
Apr 08 22:06:43 antecvdr vdr[1981]: [1990] dynamite udev monitor for subsystem dvb thread ended (pid=1981, tid=1990)
Apr 08 22:06:44 antecvdr vdr[1981]: [2033] dynamite udev monitor for subsystem (null) thread ended (pid=1981, tid=2033)
Apr 08 22:06:44 antecvdr vdr[1981]: [1981] max. latency time 1 seconds
Apr 08 22:06:44 antecvdr vdr[1981]: [1981] caught signal 15
Apr 08 22:06:44 antecvdr vdr[1981]: [1981] exiting, exit code 0

Danke für die Tipps/Neuerungen - bin auf einem guten Weg. Das mit conf.d funktioniert sehr gut - ich habe das VDR CONF-DIR nun nach /opt umgezogen und conf.d verlinke ich dort hin.

Die VDR-Konfiguration ändere somit wie folgt:

--config=/opt/vdr
--video=/video
--record=/opt/vdr/tools/rwrapper.sh
--shutdown=/opt/vdr/tools/safepower.sh
--grab=/tmp
--port=6419
--watchdog=90
--epgfile=/video/epg.data
--log=3
--lirc=/var/run/lirc/lircd

Ich nutze nun folgende Units:

vdr.service

[Unit]
Description=Video Disk Recorder
After=network.target
After=xorg-vdr.service inputlirc.service
Requires=inputlirc.service
BindsTo=xorg-vdr.service

[Service]
Type=notify
#ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "commands"
#ExecStartPre=/bin/bash /usr/lib/vdr/merge-commands.sh "reccmds"
ExecStart=/usr/bin/vdr
Restart=on-failure
RestartPreventExitStatus=0 2

[Install]
WantedBy=multi-user.target

Das ganze kann ich mit ExecPre/Post ja noch ausbauen.

Und X wird nun mit dieser Unit gestartet:

xorg-vdr.service

[Unit]
Description=X Server für VDR
BindsTo=vdr.service

[Service]
ExecStart=/usr/bin/X -br -nolisten tcp :0

[Install]
WantedBy=multi-user.target

vdr.service kann ich nun starten und stoppen, und X startet/stoppt gleichzeitig mit.

Was jedoch noch nicht funktioniert, ist der Restart des VDR, wenn er mal abschmiert. Gebe ich killall vdr ein, wird der service nicht neu gestartet. Restart=on-failure scheint irgendwie nichts zu bewirken?!

Hallo,

ich habe hier ein komisches Verhalten des VDR, welcher, wenn ich auf der FB die OK Taste drücke, doppelt reagiert.

Ursache ist der IMON IR-Empfänger in meinem Gehäuse, welcher reagiert, wenn ich das Protokol rc-6 aktiviere:

Found /sys/class/rc/rc1/ (/dev/input/event5) with:
        Name: iMON Remote (15c2:0038)
        Driver: imon, table: rc-imon-pad
        lirc device: /dev/lirc0
        Supported protocols: other rc-6
        Enabled protocols: rc-6
        bus: 3, vendor/product: 15c2:0038, version: 0x0001
        Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc0/ (/dev/input/event7) with:
        Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)
        Driver: mceusb, table: rc-rc6-mce
        lirc device: /dev/lirc1
        Supported protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
        Enabled protocols: lirc rc-6
        bus: 3, vendor/product: 0471:0815, version: 0x0000
        Repeat delay = 500 ms, repeat period = 125 ms

Nehme ich rc-6 weg, funktioniert alles korrekt. Ich frage mich jedoch, warum der VDR auf /dev/input/event5 überhaupt reagiert. Ich habe hier nur inputlirc am Laufen mit folgender Konfiguration:

# Options to be passed to inputlirc.
EVENTS="/dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00XWRC-event-if00"
OPTIONS="-g -m 28"

D.h. er darf nur auf die den MCE-IR-Empfänger reagieren.

Kann es sein, dass Xorg event5 auswertet - quasi wie eine angeschlossene Tastatur?! Der VDR funktioniert auch mit einer Tastatur (remote.conf) und ENTER ist "OK" - genauso wie die event5 evtest-Ausgabe KEY_ENTER ausgibt.

Kann das jemand bestätigen - oder ist die Vermutung falsch?

Ich hab es lange nicht beobachtet, aber Du meinst dass auch 4TB schnell genug gescannt werden, so dass es den Aufnahmeanfang nicht stört?

ok...auch eine Idee

Hallo,

das mit der Konfiguration der zu startenden Plugins - direkt mit dem VDR - habe ich irgendwie überlesen. Wo ändere ich hierfür das Default-Verzeichnis (/etc/vdr/conf.d)? Ich mag die Defaults nicht, die sind mir alle überall verstreut (/var/lib/vdr, /etc/vdr, /usr/lib...) - daher mein - richtig erkannt - historisches /etc/4vdr. Eine gute Idee, das gleich auf /opt umzuziehen. Ich habe gern alles an einer Stelle konfiguriert um es auch schnell mal umziehen zu können.

So, ich scanne mal meine runvdr.conf / Gründe für runvdr-extreme:

1. Plugins:

ersetzbar mit /etc/vdr/conf.d und hoffentlich änderbar auf /opt/vdr/plugins oder so...

2. DVB-Treiber laden/entladen

sollte heutzutage nicht mehr notwendig sein, könnte ich in einem Pre/Post-Script unterbringen, wenn erforderlich

3. Nicht-Plugin-Konfigurationen, z.B. Video-DIR, config-DIR, LIRC, RECORDCMD, SVDRPPORT, LANGUAGE etc.

wäre hier noch offen

4. XSERVER starten (mein VDR bootet nicht automatisch in die X-Umgebung)

wäre noch offen, könnte ggf. softhddevice übernehmen, aber dann wäre man Pluginabhängig (z.B. mit xineliboutput/xine würde es nicht gehen)

5. Timeout für TERM/KILL des VDR

sollte über die Unit möglich sein, ist in dem o.g. Beispiel aber nicht konfiguriert.

Sonstiges:

Ich wüsste nicht, dass man CPUFreq sagen kann, dass er nur beim Laufen des VDR die CPU auf 2GHz halten soll (ist notwendig wegen einem Problem VDPAU/GPU des AMD Systems). Kann ja im Pre/Post-Script bleiben, ebenso wie der Rest bis auf ALSACTL, dass weggelassen werden kann.

Bleibt erstmal noch Punkt 3 und 4 um mein "geliebtes" runvdr-extreme zu ersetzen.

Hallo,

ich kenne den Thread hier im Forum, wo es schon einmal um eine Start Unit für den VDR ging. Hier gab es unterschiedliche Lösungen sowie Patches für den VDR damit er auf notifys reagiert.

Mir reicht es jedoch aus, wenn ich meine bestehende Konfiguration mit runvdr-extreme von init.d nach systemd gut übertragen bekomme.

Mich würde interessieren, was ihr zu der folgenden Unit meint. So gut kenne ich mich damit noch nicht aus, so dass ggf. der ein oder andere Verbesserungen sieht.

Laufen tut es erst einmal. Ich finde das Stoppen des VDR dauert aber recht lange - kann aber auch sein, dass es mit runvdr-extreme auch vorher so war.

Hier mal meine Service-Datei:

[Unit]
Description=Video Disk Recorder
After=lircd.service
Wants=vdradmind.service

[Service]
EnvironmentFile=/etc/4vdr/config/hostconfig
ExecStartPre=/etc/4vdr/tools/runvdr-pre.sh
ExecStart=/etc/4vdr/tools/runvdr -C /etc/4vdr/config/runvdr-initd.conf
ExecStopPost=/etc/4vdr/tools/runvdr-post.sh
WorkingDirectory=/root
#User=pi
#Group=pi
PIDFile=/var/run/runvdr.pid
Restart=on-failure
SuccessExitStatus=1

[Install]
WantedBy=multi-user.target

Dazu die vor/danach Skripte:

/etc/4vdr/tools/runvdr-pre.sh

#!/bin/sh

#set -x
set -e

if [ -f /etc/4vdr/config/hostconfig ]; then
    . /etc/4vdr/config/hostconfig
else
    echo "Konfiguration /etc/4vdr/config/hostconfig fehlt!"
    exit 2
fi

if [ ! -f /etc/4vdr/config/runvdr-initd.conf ]; then
    echo "Konfiguration /etc/4vdr/config/runvdr-initd.conf fehlt!"
    exit 2
fi

export HOME=/root

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/etc/4vdr/tools
DAEMON=/etc/4vdr/tools/runvdr

# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 1

if [ "$ULIMIT_ENABLE" = "ON" ]; then
    echo "Starting ulimit debugging : ulimit"
    eval $ULIMIT_CMD
fi

if [ "$CPUFREQ_ENABLE" = "ON" ]; then
    echo "Setting CPUFREQ minimum: cpufreqset"
    eval $CPUFREQ_SET_CMD
fi

if [ "$ALSARESTORE_ENABLE" = "ON" ]; then
    echo "Restoring ALSA settings : alsactl"
    eval $ALSARESTORE_CMD || true && echo "check alsactl!"
fi

if [ "$IECSET_ENABLE" = "ON" ]; then
    echo "set IEC settings : iecset"
    eval $IECSET_CMD || true && echo "check iecset!"
fi

if [ "$CLEANCHAN_ENABLE" = "ON" ]; then
    echo "enabling channel clean : cleanchannels"
    eval $CLEANCHAN_CMD || true && echo "check cleanchannels!"
fi

if [ "$EXTRA_ENABLE" = "ON" ]; then
    echo "enabling extra command : extracmd"
    eval $EXTRA_CMD &
fi

exit 0

/etc/4vdr/tools/runvdr-post.sh

#!/bin/sh

#set -x
set -e

if [ -f /etc/4vdr/config/hostconfig ]; then
    . /etc/4vdr/config/hostconfig
else
    echo "Konfiguration /etc/4vdr/config/hostconfig fehlt!"
    exit 2
fi

if [ ! -f /etc/4vdr/config/runvdr-initd.conf ]; then
    echo "Konfiguration /etc/4vdr/config/runvdr-initd.conf fehlt!"
    exit 2
fi

export HOME=/root

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/etc/4vdr/tools
DAEMON=/etc/4vdr/tools/runvdr

if [ "$CPUFREQ_ENABLE" = "ON" ]; then
    echo "Setting CPUFREQ back to default: cpufreqset"
    eval $CPUFREQ_UNSET_CMD
fi

exit 0

Gruss

Marcus

Hallo,

ich stelle gerade auf Ubuntu 18.04 um und mit systemd scheint das alte Skript nicht mehr korrekt zu laufen. Gibt es ggf. jemanden, der das Skript schon auf systemd umgestellt hat?

Was ich bisher gefunden habe, wäre dies mein Ansatz - welcher nach einem Test funktionieren sollte:

Grundsätzlich sollte es ausreichen, das/ein ausführbare Skript nach /lib/systemd/system-shutdown zu verlinken. Alles was dort ausführbar liegt, wird beim reboot, shutdown etc. ausgeführt (mit Übergabe eines Parameters, ob nun poweroff oder reboot etc.). Im Skript muss man dann nur den Parameter abfragen, ob poweroff (denn beim Reboot will ich ja das Skript nicht ausführen).

Hier ein Proof of Concept Code:

#!/bin/bash

chvt 1
echo "IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII" >/dev/tty1 2>&1

fsck -C0 -y -v -f /dev/sda3 >/dev/tty1 2>&1

if [ mount | grep ' / ' | grep -q 'rw' ]; then
    echo "-> File system is still mounted, skipping run of fsck! Para: $1" >/dev/tty1 2>&1
    sleep 30
else
    echo "-> Now starting fsck...Para: $1" >/dev/tty1 2>&1
    sleep 30
fi


exit 0

Oder hat das jemand besser gelöst? Als Service-Unit habe ich es bisher nicht hinbekommen, dass das ganze zum korrekten Zeitpunkt startet.

Nochmal von vorn:

Laufen tut nicht viel:

Sobald bei ir-keytable das Protokoll rc-6 für meine MCE-FB aktiviert ist, funktioniert das mit dem Abschalten.

/sys/class/rc/rc1/ gefunden (/dev/input/event8) mit:
        Name: Serial IR type home-brew
        Treiber: serial_ir, Tabelle: rc-rc6-mce
        Lirc Gerät: /dev/lirc1
        unterstützte Protokolle: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
        Aktivierte Protokolle: lirc rc-6
        bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100
        Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms
/sys/class/rc/rc0/ gefunden (/dev/input/event7) mit:
        Name: Budget-CI dvb ir receiver saa7146 (0)
        Treiber: budget_ci, Tabelle: rc-tt-1500
        Lirc Gerät: /dev/lirc0
        unterstützte Protokolle:
        Aktivierte Protokolle:
        bus: 1, Anbieter/Produkt: 13c2:1019, Version: 0x0001
        Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

Ist dort nur lirc enthalten, erkennt das System auch keine Tasten (evtest).

Systemd muss also auf /dev/input/event8 lauschen und sobald mit aktivierten Protokoll der KEY_SLEEP kommt, fährt das System herunter. Kann es sein, dass systemd generell alle events die es mitbekommt, auf KEY_SLEEP auswertet und reagiert? Kann man es dann auch nur generell abschalten (sleep.conf oder logind.conf)? Kann man systemd nicht sagen: bei /dev/input/event8 reagiere nicht!

EDIT:

man logind.conf beschreibt es m.E.:

Zitat

HandlePowerKey=, HandleSuspendKey=, HandleHibernateKey=, HandleLidSwitch=, HandleLidSwitchDocked=

Controls how logind shall handle the system power and sleep keys and the lid switch to trigger actions

such as system power-off or suspend. Can be one of "ignore", "poweroff", "reboot", "halt", "kexec",

"suspend", "hibernate", "hybrid-sleep", "suspend-then-hibernate", and "lock". If "ignore", logind will

never handle these keys. If "lock", all running sessions will be screen-locked; otherwise, the specified

action will be taken in the respective event. Only input devices with the "power-switch" udev tag will

be watched for key/lid switch events.

Alles anzeigen

Also bleibt nur eine Frage: wo und wer tagt /dev/input/event8 mit "power-switch"?

Anwort: /lib/udev/rules.d/70-power-switch.rules für ALLE event*

SUBSYSTEM=="input", KERNEL=="event*", ENV{ID_INPUT_SWITCH}=="1", TAG+="power-switch"
SUBSYSTEM=="input", KERNEL=="event*", ENV{ID_INPUT_KEY}=="1", TAG+="power-switch"

Wenn ich hier irgendwie event8 ausklammern könnte, wäre mein Ziel erreicht...

Ich habe den "Actionhandler" ausfindig gemacht - nachdem ich von inputdev auf lirc-only umgestellt habe und lircd-uinput.service abgestellt habe ("umasked") - war das Verhalten weg. D.h. lircd-uinput.service muss das ganze schon einmal weiter reichen.

Jetzt weiss ich wo ich genauer suchen muss...

EDIT: nein, passt auch nicht. Weiter suchen...

Zitat von Dr. Seltsam

was ist da für ein Empfänger verbaut?

Das träge Verhalten hatte ich mit atric.

Das ist ein eigener USB-Empfänger.

Zurück zum atric - gerade gestestet: mit lircd statt inputlirc ist es nicht so träge.

Wäre schön, wenn ich es einheitlich über inputlirc konfigurieren könnte - geht aber leider nicht. Alle atric-VDRs bleiben erstmal auf LIRC. Nun muss ich nur noch herausfinden, wie ich den KEY_SLEEP (über inputdev-event) abstellen kann. Denn ohne inputlirc wird der KEY an systemd weitergereicht und der VDR geht direkt in den Standby. Aber das ist ein anderer Thread.

Um meinen Stand 14.04 auf 18.04 zu übertragen, habe ich softhddevice selber gebaut und diese Patches verwendet.

Dazu das aus 14.04 verwendete softhddevice mit Patchen heruntergeladen (yavdr stable).

Bei yaVDR experimental kann man softhddevice ebenfalls nicht installieren (selber Fehler wie Eingangspost).

Der Rechner fährt er auch ohne lircd-uinput herunter - und ich bin nicht grafisch eingeloggt, d.h. xfce läuft nicht. Bei inputlirc habe ich es gut feststellen können - mit "grab" Option fährt nichts herunter. Ohne schon.

Es reicht serial_ir geladen zu haben. Wo ist quasi KEY_SLEEP verdrahtet...

Hallo,

ich bastle derzeit gerade an der Umstellung meines VDR von Xubuntu 14.04 auf 18.04. Beim Konfigurieren der Fernbedienung ist mir aufgefallen, dass der Rechner bei der Taste "KEY_SLEEP" in den Standby (Suspend2RAM) fährt und wenn man erneut drückt, dieser wieder hochfährt (SSH Verbindung bleibt sogar bestehen, wenn man nicht zu lange wartet). Empfänger ist ein serieller Atric.

Kann mir jemand kurz erklären, welchen genauen Weg der Tastendruck nunmehr geht (udev legt fest, dass systemd auf den event reagieren soll?)?

Hat es mit /lib/udev/rules.d/70-power-switch.rules zu tun? Aber wo ist festgelegt, dass KEY_SLEEP und nicht KEY_NUMERIC_1 den events auslöst?!

Marcus

Dank Deiner "Selbstgespräche" habe ich den remote-Teil meines Xubuntu-Upgrades (14.04 auf 18.04) erstmal hinbekommen :-). Der Umstieg scheint wieder nervige Tage zu kosten, da es ja noch andere Änderungen zu beachten gilt (z.B. [offiziell] kein rc.local mehr). Die FB reagiert über events/inputlircd aber auch sehr träge. Ich werde es ebenfalls mal direkt mit lirc allein probieren.

Wenn dann scheint es am Zusammenspiel mit dem seriellen Empfänger zu liegen. Mein anderer VDR mit events/inputlircd und MCE-USB-FB macht keine Probleme...

Hallo,

das mit der Abstufung der Helligkeit muss ich mal im VDR (graphlcd Plugin) testen. Mal sehen ob die dort genauso ist. Dort wird ja dann auch auf diesselbe Funktion zugegriffen, wie es das Kodi-Plugin tut. Display ist ein Megtron SDC (siehe Sig).

Für die Abdunklung müsste man nur die entsprechenden Status ergänzen:

Derzeit:

if xbmc.getCondVisibility('System.ScreenSaverActive'):

Gemäß Kodi-Wiki müsste es "Player.Playing" sein. Im alten XBMC-GraphLCD Plugin gab es sowas aber mal...könnte man dort abgucken.

Ich bin seit längerem mal wieder zum Kodi anschauen gekommen. Auch nach einem Update auf Kodi 17.6 läuft das Plugin gut.

Allerdings wird das Display bei der Filmwiedergabe nicht gedimmt. Ist das so normal, oder müsste es gedimmt werden? Das Dimmen beim Bildschirmschoner funktioniert. Wobei hier die Einstellung der Helligkeit des Displays nicht sehr linear ist. 50% ist von 100% kaum zu unterscheiden. Für eine Abdunklung, die z.B. bei Filmwiedergabe sinnvoll ist, habe ich 2% eingestellt. Bei 1% ist das Display schon aus.

Super - funktioniert perfekt und reicht mir!

EasyVDR 3.5 hatte die V1.7.4pre1, mein Ubuntu ist bei 1.7.0 (habe das Intel Graphics Update Tool wieder deinstalliert, dort war die V1.7.1).

Ich habe zwar mal versucht, dass Ganze hochzuziehen (war bei V1.8.x, aber dann hatte ich nur noch ein schwarzes Bild mit SHDD).

Für mein Zwecke passt es nun. SHDD sowie Xineliboutput funktionieren. DVB-T2 mit HEVC kann ich nun problemlos mit dem Celeron schauen.

Das bringt wieder einige Erfahrungen, falls ich mal meine "alten" VDRs upgraden muss - noch reicht es bei SAT mit H.264 und den alten Nvidias.

Neuer Stand mit easyvdr (USB Live-System):

Nach langer Konfigurationsorgie steht fest, dass softhddevice funktioniert. Die dortigen Defaulteinstellungen sind sehr gut. Wenn ich die OSD Größe ändere, dann bekomme ich Pixelgrafik. Sehr interessant ist aber, dass wenn ich in die Konfiguration des Plugins softhddevice gehe und wieder raus, dann habe ich sofort ein quasi farblich-invertiertes Bild, die Farben sind cyan-gelb/rosa - eher so als ob der Farbraum falsch eingestellt ist?!

Nur nach einem Neustart des easyvdr (stopvdr/startvdr) sieht wieder alles normal aus. Also setup-Einstellung des Plugins ist verboten.

Bei meinem Ubuntu-System ist die Pixelgrafik nun weg. Es lag wie oben beschrieben an der OSD-Größeneinstellung.

Allerdings wird das Fernsehbild sehr frequent von grün/schwarz/roten?! Kammlinien überlagert. Diese überlagern aber nicht das OSD. Wenn ich in die Einstellungen des Plugins gehe, kommt derselbe Effekt wie bei easyVDR.

Fazit: die Überlagerung des Fernsehbildes bleibt als Restproblem. Dies könnte dann evtl. am Softwarestand/Kernel/Treiber/??? liegen....mhhh

Hiermal ein paar Logauszüge (irgendwie darf ich nur 10.000 Zeichen schreiben?!) beim Start des VDR, wo er dann mit dem Kammeffekt läuft:

Jan 18 22:10:59 netmac vdr: [3511] VDR version 2.3.8 started
Jan 18 22:10:59 netmac vdr: [3511] DVB API version is 0x050A (VDR was built with 0x050A)
Jan 18 22:10:59 netmac vdr: [3511] frontend 0/0 provides DVB-T,DVB-T2,DVB-C with QPSK,QAM16,QAM32,QAM64,QAM128,QAM256 ("Silicon Labs Si2168")
Jan 18 22:10:59 netmac vdr: [3511] cTimeMs: using monotonic clock (resolution is 1 ns)
Jan 18 22:10:59 netmac vdr: [3511] found 1 DVB device
Jan 18 22:10:59 netmac vdr: [3511] initializing plugin: softhddevice (0.6.1rc1): Ein Software und GPU emulieres HD-Gerät
Jan 18 22:10:59 netmac vdr: [3511] new device number 2
Jan 18 22:10:59 netmac vdr: [3515] frontend 0/0 tuner thread started (pid=3511, tid=3515, prio=high)
Jan 18 22:10:59 netmac vdr: [3511] setting primary device to 2
Jan 18 22:10:59 netmac vdr: [3511] starting plugin: softhddevice
Jan 18 22:10:59 netmac vdr: audio: 'alsa' output module used
Jan 18 22:10:59 netmac vdr: audio/alsa: supports pause: yes
Jan 18 22:11:00 netmac vdr: [3513] epg data reader thread ended (pid=3511, tid=3513)
Jan 18 22:11:00 netmac vdr: audio:  44100Hz supports 1 2 3 4 5 6 7 8 channels
Jan 18 22:11:00 netmac vdr: audio:  48000Hz supports 1 2 3 4 5 6 7 8 channels
Jan 18 22:11:00 netmac vdr: audio: 192000Hz supports 1 2 3 4 5 6 7 8 channels
Jan 18 22:11:00 netmac vdr: video/vaapi: libva 0.39 (Intel i965 driver for Intel(R) CherryView - 1.7.1) initialized
Jan 18 22:11:00 netmac vdr: video/vaapi: background-color is unsupported
Jan 18 22:11:00 netmac vdr: video/vaapi: supports video processing
Jan 18 22:11:00 netmac vdr: video/vaapi: supports unscaled osd
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 0 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 1 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 2 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 3 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 4 is not supported by HW
Jan 18 22:11:00 netmac vdr: [softhddev] ready
Jan 18 22:11:00 netmac vdr: [3545] device 1 receiver thread started (pid=3511, tid=3545, prio=high)
Jan 18 22:11:00 netmac vdr: [3548] device 1 TS buffer thread started (pid=3511, tid=3548, prio=high)
Jan 18 22:11:00 netmac vdr: video/vaapi: supports unscaled osd
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 0 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 1 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 2 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 3 is not supported by HW
Jan 18 22:11:00 netmac vdr: Selected deinterlacer for resolution 4 is not supported by HW
Jan 18 22:11:00 netmac vdr: [3511] OSD size changed to 1920x1080 @ 1
Jan 18 22:11:00 netmac vdr: video: display buffer empty, duping frame (1/0) 0
Jan 18 22:11:00 netmac vdr: video: display buffer empty, duping frame (2/0) 0
Jan 18 22:11:00 netmac vdr: video: display buffer empty, duping frame (3/0) 0
...
Jan 18 22:11:00 netmac vdr: video: display buffer empty, duping frame (21/0) 0
Jan 18 22:11:00 netmac vdr: video: display buffer empty, duping frame (22/0) 0
Jan 18 22:11:00 netmac vdr: audio/alsa: using device 'default'
Jan 18 22:11:00 netmac vdr: audio/alsa: start delay 336ms
Jan 18 22:11:00 netmac vdr: video: display buffer empty, duping frame (23/0) 0
...
Jan 18 22:11:01 netmac vdr: video: display buffer empty, duping frame (64/0) 0
Jan 18 22:11:01 netmac vdr: codec: YUV 420 supported
Jan 18 22:11:01 netmac vdr: Using entrypoint for vpp: 10
Jan 18 22:11:01 netmac vdr: video/vaapi: can't destroy postproc context!
Jan 18 22:11:01 netmac vdr: video/vaapi: can't destroy config!
Jan 18 22:11:01 netmac vdr: video/vaapi: noise reduction supported
Jan 18 22:11:01 netmac vdr: video/vaapi: 0.00 - 1.00 ++ 0.03 = 0.50
Jan 18 22:11:01 netmac vdr: Enabling denoise filter (pos = 0)
Jan 18 22:11:01 netmac vdr: Selected deinterlacer for resolution 0 is not supported by HW
Jan 18 22:11:01 netmac vdr: Selected deinterlacer for resolution 1 is not supported by HW
Jan 18 22:11:01 netmac vdr: Selected deinterlacer for resolution 2 is not supported by HW
Jan 18 22:11:01 netmac vdr: Selected deinterlacer for resolution 3 is not supported by HW
Jan 18 22:11:01 netmac vdr: Selected deinterlacer for resolution 4 is not supported by HW
Jan 18 22:11:01 netmac vdr: video/vaapi: deinterlacing supported
Jan 18 22:11:01 netmac vdr: video/vaapi: bob deinterlace supported
Jan 18 22:11:01 netmac vdr: video/vaapi: motion adaptive deinterlace supported
Jan 18 22:11:01 netmac vdr: video/vaapi: motion compensated deinterlace supported
Jan 18 22:11:01 netmac vdr: Enabling Deint (pos = 1)
Jan 18 22:11:01 netmac vdr: video/vaapi: sharpening supported
Jan 18 22:11:01 netmac vdr: video/vaapi: 0.00 - 1.00 ++ 0.03 = 0.50
Jan 18 22:11:01 netmac vdr: Enabling sharpening filter (pos = 0)
Jan 18 22:11:01 netmac vdr: video/vaapi: enabling color balance filters
Jan 18 22:11:01 netmac vdr: video/vaapi: Supported color balance filter count: 4
Jan 18 22:11:01 netmac vdr: Hue (-180.00 - 180.00 ++ 1.00 = 0.00) (pos = 2)
Jan 18 22:11:01 netmac vdr: Saturation (0.00 - 10.00 ++ 0.10 = 1.00) (pos = 2)
Jan 18 22:11:01 netmac vdr: Brightness (-100.00 - 100.00 ++ 1.00 = 0.00) (pos = 2)
Jan 18 22:11:01 netmac vdr: Contrast (0.00 - 10.00 ++ 0.10 = 1.00) (pos = 2)
Jan 18 22:11:01 netmac vdr: video/vaapi: skin tone enhancement supported
Jan 18 22:11:01 netmac vdr: video/vaapi: 0.00 - 4.00 ++ 1.00 = 0.00
Jan 18 22:11:01 netmac vdr: Enabling skin tone filter (pos = 3)
Jan 18 22:11:01 netmac vdr: Allocating 1 forward reference surfaces for postprocessing
Jan 18 22:11:01 netmac vdr: Allocating 0 backward reference surfaces for postprocessing
Jan 18 22:11:01 netmac vdr: video: display buffer empty, duping frame (65/0) 6
Jan 18 22:11:01 netmac vdr: video: display buffer empty, duping frame (66/0) 0
Jan 18 22:11:01 netmac vdr: video: display buffer empty, duping frame (67/0) 0
Jan 18 22:11:01 netmac vdr: video: display buffer empty, duping frame (68/0) 0
Jan 18 22:11:01 netmac vdr: video: display buffer empty, duping frame (69/0) 7
Jan 18 22:11:01 netmac vdr: Surface 0 query status = 0x6: invalid VASurfaceID
Jan 18 22:11:01 netmac vdr: Changing to 0 forward reference surfaces for postprocessing
Jan 18 22:11:02 netmac vdr: video/vaapi: synced after 39 frames
Jan 18 22:11:02 netmac vdr: video: slow down video, duping frame
Jan 18 22:11:02 netmac vdr: video: 16:52:44.476 +113  271   0/\ms  27+3 v-buf

Zitat von fnu

Aus Neugier, welches softhddevice Paket hast Du genutzt?

Ähmm, dass aus Deinen Paketen

ii vdr-plugin-softhddevice-vpp-hevc 0.6.1rc1+git20171210-rofa-0fnu0~xenial

Zitat von pbg4

wichtig war damals in softhddevice das OSD fest auf 1920x1080 einzustellen und 60 HZ mode, sonst sah es so aus wie in deinen Bildern,

Na das klingt doch schonmal vielversprechend. Werde ich testen Danke!

Zitat von SurfaceCleanerZ

Dein VDR ist HEVC gepatcht bzw. v2.3.8?

Ja, der VDR ist aus den Paketquellen von fnu (vdr 2.3.8-6fnu0~xenial) und damit mit HEVC Unterstützung.

Das mit der LiveCD (bzw. Stick) ist eine gute Idee. Das teste ich mal.

Im übrigen funktioniert VA-API nach weiteres Tests mit xineliboutput. Aufnahmen mit H.264, H.265 und MPEG2 werden abgespielt. Bei HEVC liegt die CPU-Last bei ca. 5%. Ganz perfekt geht es nicht, Deinterlacing nicht das beste, paar kleine Ruckler sind zu sehen, aber zum Gelegenheitsschauen kann ich damit leben. Wenn aber softhddevice ginge, wäre das toll, da ich es auch sonst einsetze.

Ich nehme an, dass ist die richtige Version (easyvdr-3.5.02-64-stable.iso  NEU !!! ) von EasyVDR 3.5.