Posts by 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)


    devices (udev)

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

    xorg.service

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


    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:

    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:

    Code
    1. --config=/opt/vdr
    2. --video=/video
    3. --record=/opt/vdr/tools/rwrapper.sh
    4. --shutdown=/opt/vdr/tools/safepower.sh
    5. --grab=/tmp
    6. --port=6419
    7. --watchdog=90
    8. --epgfile=/video/epg.data
    9. --log=3
    10. --lirc=/var/run/lirc/lircd


    Ich nutze nun folgende Units:

    vdr.service

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


    Und X wird nun mit dieser Unit gestartet:

    xorg-vdr.service

    Code
    1. [Unit]
    2. Description=X Server für VDR
    3. BindsTo=vdr.service
    4. [Service]
    5. ExecStart=/usr/bin/X -br -nolisten tcp :0
    6. [Install]
    7. 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:

    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:

    Code
    1. # Options to be passed to inputlirc.
    2. EVENTS="/dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00XWRC-event-if00"
    3. 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?

    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:


    Dazu die vor/danach Skripte:



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


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


    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:

    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.

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

    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*

    Code
    1. SUBSYSTEM=="input", KERNEL=="event*", ENV{ID_INPUT_SWITCH}=="1", TAG+="power-switch"
    2. 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...

    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.

    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:

    Code
    1. 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! :]:thumbup::thumbup:


    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:


    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.