Neuinstallation mit easyVDR stable

Neuinstallation mit easyVDR stable - Druckversion

+- easyVDR (http://www.easy-vdr.de)
+-- Forum: easyVDR (http://www.easy-vdr.de/forum-5.html)
+--- Forum: easyVDR 5.0 (Alpha) (http://www.easy-vdr.de/forum-161.html)
+--- Thema: Neuinstallation mit easyVDR stable (/thread-18801.html)

Seiten: 1 2 3 4 5 6

RE: Neuinstallation mit easyVDR stable - Oberlooser - 15.06.2020

(06.06.2020, 22:13)mango schrieb: Hallo Helmut!

(06.06.2020, 21:44)Oberlooser schrieb: Es muss daher an irgend ein Addon , Einstellungen oder Plugin liegen
Sorry, musste kurzfristig weg!
...sicher dir die Ausgabe von "ls -l /usr/share/vdr/shutdown-hooks" dann kannst
du leichter festellen wo es dann klemmt wenn die Kiste nicht mehr rünterfährt!

P.S

(06.06.2020, 14:13)Oberlooser schrieb: systemd-udevd[11941]: NVIDIA ACPI Video Driver: Process '/bin/systemctl start --no-block nvidia-persistenced.service' failed with exit code 5
kam diese Fehlermeldung erneut nach Neu Install??

Gruss
Wolfgang

Hi Wolfgang
Sorry das ich erst jetzt Antworte . War eine Woche im Urlaub...
Problem mit dem Shutdown ist nach einer Neu installation weg
Hier der syslog
-----------------------------------------------------
----- ERRORS in syslog -----
-----------------------------------------------------

Jun 15 18:27:58 Lintec5 systemd[1]: Started ACPI Events Check.
Jun 15 18:27:58 Lintec5 systemd[1]: Condition check resulted in Process error reports when automatic reporting is enabled (file watch) being skipped.
Jun 15 18:27:58 Lintec5 systemd[1]: Started CUPS Scheduler.
--
Jun 15 18:27:58 Lintec5 kernel: [ 0.606447] Key type dns_resolver registered
Jun 15 18:27:58 Lintec5 kernel: [ 0.606626] RAS: Correctable Errors collector initialized.
Jun 15 18:27:58 Lintec5 kernel: [ 0.606667] microcode: sig=0x6fb, pf=0x1, revision=0xba
--
Jun 15 18:27:58 Lintec5 kernel: [ 2.735981] systemd[1]: Finished Uncomplicated firewall.
Jun 15 18:27:58 Lintec5 kernel: [ 2.739942] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro
Jun 15 18:27:58 Lintec5 kernel: [ 2.743191] systemd[1]: Finished Remount Root and Kernel File Systems.
--
Jun 15 18:27:58 Lintec5 kernel: [ 4.350474] intel_powerclamp: No package C-state available
Jun 15 18:27:58 Lintec5 kernel: [ 4.394287] mt352_read_register: readreg error (reg=127, ret==-121)
Jun 15 18:27:58 Lintec5 kernel: [ 4.404710] nxt200x: nxt200x_readbytes: i2c read error (addr 0x0a, err == -121)
Jun 15 18:27:58 Lintec5 kernel: [ 4.404713] nxt200x: Unknown/Unsupported NXT chip: 00 00 00 00 00
Jun 15 18:27:58 Lintec5 kernel: [ 4.415323] lgdt330x 1-0059: i2c_read_demod_bytes: addr 0x59 select 0x02 error (ret == -121)
Jun 15 18:27:58 Lintec5 kernel: [ 4.431638] stv0297_readreg: readreg error (reg == 0x80, ret == -121)
Jun 15 18:27:58 Lintec5 kernel: [ 4.442065] mt312_read: ret == -121
--
Jun 15 18:28:00 Lintec5 kernel: [ 8.439280] r8169 0000:03:00.0 enp3s0: Link is Down
Jun 15 18:28:00 Lintec5 NetworkManager[583]: [1592238480.3393] Error: failed to open /run/network/ifstate
Jun 15 18:28:00 Lintec5 NetworkManager[583]: [1592238480.3521] modem-manager: ModemManager available
--
Jun 15 18:28:28 Lintec5 systemd-timesyncd[540]: Initial synchronization to time server 91.189.89.198:123 (ntp.ubuntu.com).
Jun 15 18:28:29 Lintec5 pulseaudio[826]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Jun 15 18:28:30 Lintec5 systemd[1]: systemd-hostnamed.service: Succeeded.

-----------------------------------------------------
----- ERRORS in xorg.log -----
-----------------------------------------------------------------------------------------
Ausgabe von:
[email protected]:/home/easyvdr# ls -l /usr/share/vdr/shutdown-hooks

insgesamt 24
-rwxr-xr-x 1 root root 3321 Apr 28 2018 10_shutdown.acpi
-rwxr-xr-x 1 root root 747 Jan 3 12:02 10_shutdown.custom
-rwxr-xr-x 1 root root 399 Jan 3 12:02 10_shutdown.handbrake-cli
-rwxr-xr-x 1 root root 96 Jan 3 12:02 10_shutdown.logrotate
-rwxr-xr-x 1 root root 520 Jan 3 12:02 10_shutdown.wol
-rwxr-xr-x 1 root root 1427 Jan 3 12:02 11_last_channel_volume

Ich kann nicht sagen woran es lag
Addons und Plugins sind die gleichen..

Gruss Helmut

RE: Neuinstallation mit easyVDR stable - bax2000 - 16.06.2020

Moin!

Leider kann ich jetzt keine log-Dateien liefern, möchte aber trotzdem mal kurz ein Problem schildern was ich nach meinem letzten update/upgrade hatte:

Das System startete neu und ich hatte immer nur kurz für knapp 2 Sekunden Bild und Ton, danach wurde es für 1 Sekunde schwarz und dann begann die ganze Sache von vorne. Also eine Schleife! Keine Reaktion auf FB oder Tastatur.

Ich habe dann über die WebUI alle Plugins deaktiviert - Reboot - Bild und Ton normal da.
Danach habe ich ein Plugin nach dem anderen aktiviert und jeweils einen kompletten Reboot gemacht. Ich dachte so das Problem eingrenzen zu können....dachte ich Wink

Am Ende waren exakt die selben Plugins aktiv wie vorher mit dem Problem, aber das System läuft jetzt schon ca. 1 Woche stabil.

Komische Sache das.....

Gruß!

RE: Neuinstallation mit easyVDR stable - Markus Liebig - 18.06.2020

Moin Team,

wann wurde das letzte (Zeit Datum (Bin ich der einzige der sowas mitschreibt. Oldschool)

stopvdr
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

Neustart gemacht?

Auf meinem Test VDR 5 klappt das stopvdr nicht immer beim ersten Versuch.

MfG
Markus

RE: Neuinstallation mit easyVDR stable - gb - 18.06.2020

Hallo Markus

Ich bin mir gerade nicht sicher ob du dich jetzt verschrieben hast, oder tatsächlich "stop vdr" eingibst.

Richtig wäre "stopvdr" "startvdr"

Testsystem heißt jetzt was?
( - mit dvb Devices, oder ohne
- mit Empfang, oder ohne
- ist am Internet angeschlossen, oder von der Welt abgenabelt )

Was sagt denn das Log?

Gruss Aaron

RE: Neuinstallation mit easyVDR stable - Markus Liebig - 19.06.2020

Moin Team,

danke für die Antwort. War ein verschreiber (Morgenmuffel noch kein Kaffee) ist berichtigt.

mein Testsystem aus signatur: Test easyvdr-5-alpha-010 stable mit DVB-T2 und Internetanbindung.
An die Logs komme ich im Moment nicht ran.

Es geht grundsätzlich um strukturiertes Testen, Dokumentieren. Einen Parameter ändern, sehen was passiert => Fehler behoben, oder nicht. Mitschreiben
=> Zielführend

Gruß
Markus

P.S.: Ist sehr komplex das ganze Thema

RE: Neuinstallation mit easyVDR stable - gb - 21.06.2020

Zur Info an uns..

Habe vor 2 Stunden und eben mal vollständig auf einem NVIDIA System neu aufgesetzt. Beim ersten Versuch ist die Installroutine schief gelaufen. Es konnten gewisse Pakete nicht geholt werden, daher zweiter Anlauf 2Stunden später.
Das Resultat sieht noch immer gut aus.
Am Ende Bild und Ton vorhanden.

Gruß Aaron

RE: Neuinstallation mit easyVDR stable - Connor1980 - 03.07.2020

(09.06.2020, 07:13)gb schrieb:
Code:
cat /proc/bus/input/devices

Zusätzlich wäre interessant, als was deine Karte beim ir Reciever setup angezeigt wurde.

Grüße Aaron

Die Ausgabe habe ich beigefügt.
Die Anzeige im Setup zeigt "Nova HD-S2"

RE: Neuinstallation mit easyVDR stable - gb - 04.07.2020

Hi, das ist merkwürdig, ist das cat usw. direkt unter easyVDR5.x, oder easyVDR3.x gemacht worden?

Zitat:I: Bus=0001 Vendor=0070 Product=6906 Version=0001
N: Name="cx88 IR (Hauppauge WinTV-HVR400"
P: Phys=pci-0000:04:00.0/ir0
S: Sysfs=/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/0000:04:00.0/rc/rc0/input24
U: Uniq=
H: Handlers=kbd event11
B: PROP=20
B: EV=100017
B: KEY=3ff 0 10afc312 214201700000000 0 118000 41a800004801 9e16c000000000 10000000
B: REL=3
B: MSC=10

..und...

Zitat:# Nova S2 HD
hw_name[23]="IR der Nova S2 HD"
hw_ident[23]="14f1:8800 0070:6906"
det_method[23]="chk_lspci3"
ins_method[23]="inst_lirc"
paraset_a[23]="ID_TXT"
paraset_b[23]="dev_input"
paraset_c[23]="Event"
paraset_d[23]="cx88 IR (Hauppauge WinTV-HVR400"
paraset_e[23]="cx88 IR"

Das sollte eigentlich passen.

Gruß Aaron

RE: Neuinstallation mit easyVDR stable - Connor1980 - 04.07.2020

(04.07.2020, 12:54)gb schrieb: Hi, das ist merkwürdig, ist das cat usw. direkt unter easyVDR5.x, oder easyVDR3.x gemacht worden?

das war natürlich Version 5 :-)

RE: Neuinstallation mit easyVDR stable - grumpf - 13.08.2020

(04.07.2020, 12:54)gb schrieb: Hi, das ist merkwürdig, ist das cat usw. direkt unter easyVDR5.x, oder easyVDR3.x gemacht worden?

Zitat:I: Bus=0001 Vendor=0070 Product=6906 Version=0001
N: Name="cx88 IR (Hauppauge WinTV-HVR400"
P: Phys=pci-0000:04:00.0/ir0
S: Sysfs=/devices/pci0000:00/0000:00:1c.3/0000:03:00.0/0000:04:00.0/rc/rc0/input24
U: Uniq=
H: Handlers=kbd event11
B: PROP=20
B: EV=100017
B: KEY=3ff 0 10afc312 214201700000000 0 118000 41a800004801 9e16c000000000 10000000
B: REL=3
B: MSC=10

..und...

Zitat:# Nova S2 HD
hw_name[23]="IR der Nova S2 HD"
hw_ident[23]="14f1:8800 0070:6906"
det_method[23]="chk_lspci3"
ins_method[23]="inst_lirc"
paraset_a[23]="ID_TXT"
paraset_b[23]="dev_input"
paraset_c[23]="Event"
paraset_d[23]="cx88 IR (Hauppauge WinTV-HVR400"
paraset_e[23]="cx88 IR"

Das sollte eigentlich passen.

Gruß Aaron

Also... ich habe gerade derzeit exakt das identische Problem! FB-Receiver ist die WinTV Nova S2 HD. Allerdings steuere ich das Ding nicht mit der RC5-Origialfernbediedung von Hauppauge an, sondern mit eine One-For-All mit Code 1272 (also Standard Infrarot RC6-Fernbedienung als MCE Microsoft-Media-Center-Edition).

Menu-Tasten, Volume-Up-Down, etc. funktioniert - aber keine 0, 1, 2, 4... 8, 9.

Beim ir-keytable ist die Rede von Table rc-hauppauge... unter 3.5 funktioniert es prima:

Code:

[email protected]:~# ir-keytable 

Found /sys/class/rc/rc0/ (/dev/input/event3) with:

    Driver cx88xx, table rc-hauppauge

    Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC RC-5-SZ other 

    Enabled protocols: RC-6 LIRC 

    Name: cx88 IR (Hauppauge WinTV-HVR400

    bus: 1, vendor/product: 0070:6906, version: 0x0001

    Repeat delay = 500 ms, repeat period = 125 ms

[email protected]:~# uname -a

Linux schimi 4.4.0-137-generic #163~14.04.1-Ubuntu SMP Mon Sep 24 17:14:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

[email protected]:~#

Unter 5-Alpha:

Code:

[email protected]:~# ir-keytable 

/sys/class/rc/rc0/ gefunden mit:

    Name: cx88 IR (Hauppauge WinTV-HVR400

    Treiber cx88xx

    Standardschlüsselcodeabbildung: rc-hauppauge

    Eingabegerät: /dev/input/event4

    Linux-Infrarotfernbedienung : /dev/lirc0

    tangefügte BPF-Protokolle: Vorgang wird nicht unterstützt

    unterstützte Kernelprotokolle: lirc rc-5 rc-5-sz rc-6 

    Aktivierte Kernelprotokolle: lirc rc-6 

    bus: 1, Anbieter/Produkt: 0070:6906, Version: 0x0001

    Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

[email protected]:~# uname -a

Linux schimi 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[email protected]:~#

Hat da jemand einen Tip für mich? Mir ist unklar, wie ich da debuggen kann...

Tschö

Gunther

RE: Neuinstallation mit easyVDR stable - Oberlooser - 14.08.2020

HI Gunther
Gibt den auf der Eingabe-Konsole irw etwas aus
wenn Du die Tasten drückst die nicht funktionieren.

irw auf der Konsole ausführen mit admin Rechten

Und Gunther leg Dir bitte eine Signatur an ,damit man sieht was für eine Hardware Du einsetzt.
Das erleichtert die Sache ungemein und reduziert einige Nachfragen etc..
Gruss Helmut

RE: Neuinstallation mit easyVDR stable - grumpf - 14.08.2020

Zuerst der EA5 (IR via NovaHDS2), keine Nachricht von 0... 9, der Rest sieht gut aus - die Physik RC6, lirc etc. scheint zu tun:

Code:

[email protected]:~# hostnamectl; ir-keytable; irw 

   Static hostname: schimi

         Icon name: computer-desktop

           Chassis: desktop

        Machine ID: 78fedbaa7faa580c0a4c04e75f315d94

           Boot ID: 548554b0173d4c98ae434f65a94494c7

  Operating System: Ubuntu 20.04.1 LTS

            Kernel: Linux 5.4.0-26-generic

      Architecture: x86-64

/sys/class/rc/rc0/ gefunden mit:

    Name: cx88 IR (Hauppauge WinTV-HVR400

    Treiber cx88xx

    Standardschlüsselcodeabbildung: rc-hauppauge

    Eingabegerät: /dev/input/event4

    Linux-Infrarotfernbedienung : /dev/lirc0

    tangefügte BPF-Protokolle: Vorgang wird nicht unterstützt

    unterstützte Kernelprotokolle: lirc rc-5 rc-5-sz rc-6 

    Aktivierte Kernelprotokolle: lirc rc-6 

    bus: 1, Anbieter/Produkt: 0070:6906, Version: 0x0001

    Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

000000008001018e 00 KEY_RED devinput

00000000800100ae 00 KEY_EXIT devinput

000000008001018f 00 KEY_GREEN devinput

0000000080010190 00 KEY_YELLOW devinput

0000000080010191 00 KEY_BLUE devinput

00000000800100ae 00 KEY_EXIT devinput

0000000080010172 00 KEY_SUBTITLE devinput

0000000080010182 00 KEY_TUNER devinput

^C

[email protected]:~# cat /etc/udev/rules.d/01-easyvdr-remote.rules | grep -v ^#

KERNEL=="event*", ATTRS{name}=="cx88 IR (Hauppauge WinTV-HVR400", SYMLINK+="input/ir-auto_dtc", GROUP="vdr"          

[email protected]:~# cat /etc/udev/rules.d/90-mce-ir.rules | grep -v ^#

ACTION=="add|change", SUBSYSTEM=="rc",    RUN+="/usr/bin/ir-keytable -c -w /etc/vdr/rc6_mce -p LIRC,RC-6"

ACTION=="add|change", SUBSYSTEM=="input", RUN+="/usr/bin/ir-keytable -c -w /etc/vdr/rc6_mce -p LIRC,RC-6"

[email protected]:~# ps -ef|grep lirc|grep -v grep

root        1021       1  0 12:23 ?        00:00:00 /usr/sbin/lircd --nodaemon

[email protected]:~# /usr/sbin/lircd --version

lircd 0.10.1

[email protected]:~# ls -la /dev/input/ir-auto_dtc 

lrwxrwxrwx 1 root root 6 Aug 14 12:22 /dev/input/ir-auto_dtc -> event4

[email protected]:~# evtest 2>&1 | grep -i cx

/dev/input/event4:    cx88 IR (Hauppauge WinTV-HVR400

/dev/input/event15:    cx88 IR (Hauppauge WinTV-HVR400 (lircd bypass)

^C

[email protected]:~# systemctl poweroff

Jetzt unter 3.5 mit funktionierenden 0... 9:

Code:

[email protected]:~# hostnamectl ; ir-keytable ; irw

   Static hostname: schimi

         Icon name: computer-desktop

           Chassis: desktop

           Boot ID: 445e40f90e5c4b0697a117cb3cccd184

  Operating System: Ubuntu 14.04.6 LTS

            Kernel: Linux 4.4.0-137-generic

      Architecture: x86_64

Found /sys/class/rc/rc0/ (/dev/input/event11) with:

    Driver cx88xx, table rc-hauppauge

    Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC RC-5-SZ other 

    Enabled protocols: RC-6 LIRC 

    Name: cx88 IR (Hauppauge WinTV-HVR400

    bus: 1, vendor/product: 0070:6906, version: 0x0001

    Repeat delay = 500 ms, repeat period = 125 ms

000000008001018e 00 KEY_RED devinput

00000000800100ae 00 KEY_EXIT devinput

000000008001018f 00 KEY_GREEN devinput

0000000080010190 00 KEY_YELLOW devinput

0000000080010191 00 KEY_BLUE devinput

0000000080010201 00 KEY_1 devinput

0000000080010202 00 KEY_2 devinput

0000000080010203 00 KEY_3 devinput

0000000080010204 00 KEY_4 devinput

0000000080010205 00 KEY_5 devinput

0000000080010206 00 KEY_6 devinput

0000000080010207 00 KEY_7 devinput

0000000080010208 00 KEY_8 devinput

0000000080010209 00 KEY_9 devinput

0000000080010200 00 KEY_0 devinput

0000000080010172 00 KEY_SUBTITLE devinput

0000000080010182 00 KEY_TUNER devinput

^C

[email protected]:~# cat /etc/udev/rules.d/01-easyvdr-remote.rules | grep -v ^#

KERNEL=="event*", ATTRS{name}=="cx88 IR (Hauppauge WinTV-HVR400", SYMLINK+="input/ir-auto_dtc", GROUP="vdr" # inserted_by_easyvdr-detect

[email protected]:~# cat /etc/udev/rules.d/90-mce-ir.rules | grep -v ^#

ACTION=="add|change", SUBSYSTEM=="rc",    RUN+="/usr/bin/ir-keytable -s $name -c -w /etc/vdr/rc6_mce -p LIRC,RC-6"

[email protected]:~# ps -ef|grep lirc|grep -v grep

root      2264     1  0 12:37 ?        00:00:00 /usr/sbin/lircd -n --output=/var/run/lirc/lircd --driver=devinput --device=/dev/input/ir-auto_dtc

[email protected]:~# /usr/sbin/lircd --version

lircd 0.9.0

[email protected]:~# ls -la /dev/input/ir-auto_dtc

lrwxrwxrwx 1 root root 7 Aug 14 12:36 /dev/input/ir-auto_dtc -> event11

[email protected]:~# evtest 2>&1 | grep -i cx

/dev/input/event11:    cx88 IR (Hauppauge WinTV-HVR400

/dev/input/event12:    MCE IR Keyboard/Mouse (cx88xx)

^C

[email protected]:~# reboot

Also für Spass.. ich tippe auf die "table rc-hauppauge".... der Rest ist identisch, und die rc-hauppauge.ko unter den Modules hat sich irgendwann geändert (bei 3.5 - der Kernel ist gehalten, die Module also auch). Ach ja, die RC6-Module musste/habe ich via /etc/modload.d/IRGENDWAS laden, weil der ir-keytable sie (bei 5, nicht bei 3.5!) nicht dynamisch lädt.

Habe fertig - Ideen?

RE: Neuinstallation mit easyVDR stable - gb - 14.08.2020

Endlich gibt mal jemand Resultate über irw aus.
Ideen ja, mit irkeytable die Codes identifizieren, von Tasten die nicht gehen und dann sehen wir weiter.

Gruß Aaron

RE: Neuinstallation mit easyVDR stable - grumpf - 14.08.2020

(14.08.2020, 13:09)gb schrieb: Endlich gibt mal jemand Resultate über irw aus.
Ideen ja, mit irkeytable die Codes identifizieren, von Tasten die nicht gehen und dann sehen wir weiter.

Gruß Aaron

JEZZ jezz - Du bist echt gut - aber WIE komme ich hinter die Codes, wenn irw nix gibt? mode2? Wie zum Teufel kann ich denn mit ir-keytable Code identifizieren??? Lass' mich nicht dumm sterben :-)

RE: Neuinstallation mit easyVDR stable - gb - 14.08.2020

Versuch es mal in etwa so:

Code:
ir-keytable -t -d /dev/input/ir-auto_dtc

Ps: ich rate gerade auch nur ins blaue, zu lange her Big Grin

RE: Neuinstallation mit easyVDR stable - grumpf - 14.08.2020

Okay... es ist "ir-keytable -t" und analog zu evtest muss alles auf dem Device gestoppt werden, also:

Code:

[email protected]:/usr/share/easyvdr# stopvdr; initctl stop easyvdr-desktop

easyvdr-frontend stop/waiting

easyvdr-vdr stop/waiting 

easyvdr-desktop stop/waiting

[email protected]:/usr/share/easyvdr# ir-keytable -t

Testing events. Please, press CTRL-C to abort.

1597404239.689985: event type EV_MSC(0x04): scancode = 0x800f040d

1597404239.689985: event type EV_KEY(0x01) key_down: KEY_MENU(0x0001)

1597404239.689985: event type EV_SYN(0x00).

1597404239.793980: event type EV_MSC(0x04): scancode = 0x800f040d

1597404239.793980: event type EV_SYN(0x00).

1597404240.043915: event type EV_KEY(0x01) key_up: KEY_MENU(0x0001)

1597404240.043915: event type EV_SYN(0x00).

1597404244.154119: event type EV_MSC(0x04): scancode = 0x800f0400

1597404244.154119: event type EV_KEY(0x01) key_down: KEY_NUMERIC_0(0x0001)

1597404244.154119: event type EV_SYN(0x00).

1597404244.258123: event type EV_MSC(0x04): scancode = 0x800f0400

1597404244.258123: event type EV_SYN(0x00).

1597404244.507914: event type EV_KEY(0x01) key_up: KEY_NUMERIC_0(0x0001)

1597404244.507914: event type EV_SYN(0x00).

^C

[email protected]:/usr/share/easyvdr# init 0

Das obige war jetzt ein Positiv-Test unter EA3.5 - und nun EA5:

Code:

[email protected]:~# stopvdr 

[email protected]:~# Sending 1 processes the TERM signal.terminated.

connect: Connection refused



[email protected]:~# systemctl stop e

e2scrub_all.timer                  easyvdr-systemstart.service

easyvdr-addon-acpi-wakeup.service  etc-setserial.service

easyvdr-program-changer.service    

[email protected]:~# systemctl stop easyvdr-systemstart.service 

[email protected]:~# systemctl stop lightdm.service 

[email protected]:~# 

[email protected]:~#  

[email protected]:~# ps -ef|grep X

root        3215    2246  0 13:30 pts/0    00:00:00 grep --color=auto X

[email protected]:~# ir-keytable

/sys/class/rc/rc0/ gefunden mit:

Name: cx88 IR (Hauppauge WinTV-HVR400

Treiber cx88xx

Standardschlüsselcodeabbildung: rc-hauppauge

Eingabegerät: /dev/input/event12

Linux-Infrarotfernbedienung : /dev/lirc0

tangefügte BPF-Protokolle: Vorgang wird nicht unterstützt

unterstützte Kernelprotokolle: lirc rc-5 rc-5-sz rc-6 

Aktivierte Kernelprotokolle: lirc rc-6 

bus: 1, Anbieter/Produkt: 0070:6906, Version: 0x0001

Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

[email protected]:~# ir-keytable -t

Ereignisse werden getestet. Bitte drücken Sie STRG-C, um abzubrechen.

185.646515: Linux-Infrarotfernbedienungsprotokoll(rc6_mce): Scancode = 0x800f040d umschalten=1

185.646535: Ereignistyp EV_MSC(0x04): Scancode = 0x800f040d

185.646535: Ereignistyp EV_KEY(0x01) key_runter: KEY_MENU(0x008b)

185.646535: Ereignistyp EV_SYN(0x00).

185.750521: Linux-Infrarotfernbedienungsprotokoll(rc6_mce): Scancode = 0x800f040d umschalten=1

185.750533: Ereignistyp EV_MSC(0x04): Scancode = 0x800f040d

185.750533: Ereignistyp EV_SYN(0x00).

185.876383: Ereignistyp EV_KEY(0x01) key_hoch: KEY_MENU(0x008b)

185.876383: Ereignistyp EV_SYN(0x00).

187.230596: Linux-Infrarotfernbedienungsprotokoll(rc6_mce): Scancode = 0x800f0400

187.230610: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0400

187.230610: Ereignistyp EV_KEY(0x01) key_runter: KEY_NUMERIC_0(0x0200)

187.230610: Ereignistyp EV_SYN(0x00).

187.334603: Linux-Infrarotfernbedienungsprotokoll(rc6_mce): Scancode = 0x800f0400

187.334615: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0400

187.334615: Ereignistyp EV_SYN(0x00).

187.460382: Ereignistyp EV_KEY(0x01) key_hoch: KEY_NUMERIC_0(0x0200)

187.460382: Ereignistyp EV_SYN(0x00).

So, das bedeutet, dass sowohl unter EA3.5 als auch unter EA5 die KEY_MENU(0x0001) und KEY_NUMERIC_0(0x0001) ankommen... aber die KEY_NUMERIC_0 tut nicht bei EA5.

Und jetzt bleibe ich auf EA5, nehme aber den socat nach lirc:

Code:

269.749319: Linux-Infrarotfernbedienungsprotokoll(rc6_mce): Scancode = 0x800f0403

269.749334: Ereignistyp EV_MSC(0x04): Scancode = 0x800f0403

269.749334: Ereignistyp EV_KEY(0x01) key_runter: KEY_NUMERIC_3(0x0203)

269.749334: Ereignistyp EV_SYN(0x00).

269.876382: Ereignistyp EV_KEY(0x01) key_hoch: KEY_NUMERIC_3(0x0203)

269.876382: Ereignistyp EV_SYN(0x00).

^C

[email protected]:~# socat UNIX-CONNECT:/var/run/lirc/lircd STDIO

000000008001008b 00 KEY_MENU devinput

000000008001008b 00 KEY_MENU devinput

^[email protected]:~# uname -a

Linux schimi 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[email protected]:~#

Was man nun nicht sehen kann, ist, dass ich zwischen KEY_MENU und KEY_MENU die 0 gerdückt habe. Also schluckt jemand die Tasten... und nach lircd ist keine KEY_NUMERIC_0 mehr da. Ich sehe mir jetzt die "devinput-Mappe" vom Lirc an..... und schicke das hier trotzdem ab, sonst ist die Code-Formatierung wieder kaputt.

RE: Neuinstallation mit easyVDR stable - gb - 14.08.2020

Am besten postest du mal den kompletten Inhalt der lircd.conf unter /etc/lircd. PS, lircd.conf ist ein symlink zu der eigentlichen Datei einen Ordner noch höher, glaube lircd.conf.dev_input

Gruß Aaron

RE: Neuinstallation mit easyVDR stable - grumpf - 14.08.2020

So, ich habe meinen Fehler.... bei laufendem VDR testen via irw, es muss so aussehen (man achte auf die KEY_6):

Code:

[email protected]:~# irw

000000008001008b 00 KEY_MENU devinput

0000000080010007 00 KEY_6 devinput

^C

[email protected]:~# uname -a

Linux schimi 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[email protected]:~#

Dann wird's etwas.... der eigentliche Fehler war meine eigene, falsche Map wie folgt:

Code:

[email protected]:~# cat /etc/udev/rules.d/90-mce-ir.rules |grep -v ^#

ACTION=="add|change", SUBSYSTEM=="rc",    RUN+="/usr/bin/ir-keytable -c -w /etc/vdr/rc6_mce -p LIRC,RC-6"

ACTION=="add|change", SUBSYSTEM=="input", RUN+="/usr/bin/ir-keytable -c -w /etc/vdr/rc6_mce -p LIRC,RC-6"

[email protected]:~# ls -ltra /etc/vdr/rc6_mce /etc/vdr/rc6_mce_keine_0_bis_9 /etc/vdr/rc6_mce.0_keine_menue_taste

-rw-r--r-- 1 root root 1423 Okt 18  2016 /etc/vdr/rc6_mce.0_keine_menue_taste

-rw-r--r-- 1 root root 1629 Okt 19  2016 /etc/vdr/rc6_mce_keine_0_bis_9

-rw-r--r-- 1 root root 1943 Aug 14 14:17 /etc/vdr/rc6_mce

[email protected]:~# sdiff /etc/vdr/rc6_mce /etc/vdr/rc6_mce_keine_0_bis_9

# table rc6_mce, type: RC6                    # table rc6_mce, type: RC6

# alt 2020: 0x800f0400 KEY_NUMERIC_0                  |    0x800f0400 KEY_NUMERIC_0

# alt 2020: 0x800f0401 KEY_NUMERIC_1                  |    0x800f0401 KEY_NUMERIC_1

# alt 2020: 0x800f0402 KEY_NUMERIC_2                  |    0x800f0402 KEY_NUMERIC_2

# alt 2020: 0x800f0403 KEY_NUMERIC_3                  |    0x800f0403 KEY_NUMERIC_3

# alt 2020: 0x800f0404 KEY_NUMERIC_4                  |    0x800f0404 KEY_NUMERIC_4

# alt 2020: 0x800f0405 KEY_NUMERIC_5                  |    0x800f0405 KEY_NUMERIC_5

# alt 2020: 0x800f0406 KEY_NUMERIC_6                  |    0x800f0406 KEY_NUMERIC_6

# alt 2020: 0x800f0407 KEY_NUMERIC_7                  |    0x800f0407 KEY_NUMERIC_7

# alt 2020: 0x800f0408 KEY_NUMERIC_8                  |    0x800f0408 KEY_NUMERIC_8

# alt 2020: 0x800f0409 KEY_NUMERIC_9                  |    0x800f0409 KEY_NUMERIC_9

0x800f0400 KEY_0                          <

0x800f0401 KEY_1                          <

0x800f0402 KEY_2                          <

0x800f0403 KEY_3                          <

0x800f0404 KEY_4                          <

0x800f0405 KEY_5                          <

0x800f0406 KEY_6                          <

0x800f0407 KEY_7                          <

0x800f0408 KEY_8                          <

0x800f0409 KEY_9                          <

# Ende Aenderungen 2020                          <

0x800f040a KEY_DELETE                        0x800f040a KEY_DELETE

0x800f040b KEY_ENTER                        0x800f040b KEY_ENTER

0x800f040c KEY_SLEEP                        0x800f040c KEY_SLEEP

# 0x800f040d KEY_MEDIA                        # 0x800f040d KEY_MEDIA

0x800f040d KEY_MENU                        0x800f040d KEY_MENU

0x800f040e KEY_MUTE                        0x800f040e KEY_MUTE

0x800f040f KEY_INFO                        0x800f040f KEY_INFO

0x800f0410 KEY_VOLUMEUP                        0x800f0410 KEY_VOLUMEUP

0x800f0411 KEY_VOLUMEDOWN                    0x800f0411 KEY_VOLUMEDOWN

0x800f0412 KEY_CHANNELUP                    0x800f0412 KEY_CHANNELUP

0x800f0413 KEY_CHANNELDOWN                    0x800f0413 KEY_CHANNELDOWN

0x800f0414 KEY_FASTFORWARD                    0x800f0414 KEY_FASTFORWARD

0x800f0415 KEY_REWIND                        0x800f0415 KEY_REWIND

...

# orig: 0x800f041a KEY_NEXT                    # orig: 0x800f041a KEY_NEXT

# orig: 0x800f045d KEY_YELLOW (siehe 0x800f045d)        # orig: 0x800f045d KEY_YELLOW (siehe 0x800f045d)

0x800f041a KEY_YELLOW                        0x800f041a KEY_YELLOW

# orig: 0x800f041b KEY_PREVIOUS                    # orig: 0x800f041b KEY_PREVIOUS

# orig: 0x800f045c KEY_GREEN  (siehe 0x800f045c)        # oirg: 0x800f045c KEY_GREEN  (siehe 0x800f045c)

0x800f041b KEY_GREEN                        0x800f041b KEY_GREEN

[code]0x800f041c KEY_NUMERIC_POUND                    0x800f041c KEY_NUMERIC_POUND

[code]0x800f041d KEY_NUMERIC_STAR                    0x800f041d KEY_NUMERIC_STAR

[code]0x800f041e KEY_UP                        0x800f041e KEY_UP

[code]0x800f041f KEY_DOWN                        0x800f041f KEY_DOWN

...

0x800f0481 KEY_PLAYPAUSE                    0x800f0481 KEY_PLAYPAUSE

[email protected]:~# cat /etc/modules-load.d/90-mce_lirc_rc6_modules.conf | grep -v ^#

rc-rc6-mce

ir-rc6-decoder

[email protected]:~#

Die udev-Regel vom 3.5 zieht natürlich auch beim EA5 - aber die beiden Protokolle rc-rc6-mce und/oder ir-rc6-decoder müssen via insmod vorhanden sein - sonst begreift ir-keytable das nicht und lädt es nicht.
Bei dem KEY_NUMERIC_0 ist ein Unterschied zu KEY_0 - das ist wahrscheinlich der relevante Unterschied zwischen EA3.5 und EA5 - vorher funktionierte es auch mit KEY_NUMERIC_0 bei mir, nun nur noch nach Änderung auf KEY_0.

Insgesamt ist aber jeder selbst schuld, der sich die obige Arie antut - einfache ist es, einen supporteten IR-Empfänger einzusetzen (was ich dann auch tun werde!) - das hier ist eher akademisch, ich möchte die alte Hardware vom 3.5er unter EA5 als Testgerät weiterbenutzen...

RE: Neuinstallation mit easyVDR stable - gb - 15.08.2020

Verstehe ich das richtig, entweder die remote.conf um key_numeric erweitern, oder die lircd.conf.dev_input tables anpassen und das wars?

RE: Neuinstallation mit easyVDR stable - grumpf - 15.08.2020

(15.08.2020, 07:41)gb schrieb: Verstehe ich das richtig, entweder die remote.conf um key_numeric erweitern, oder die lircd.conf.dev_input tables anpassen und das wars?

Neee... also so wie ich das sehe... in meinem Fall war es (bei funktionierender Physik!) die Änderung in der /etc/vdr/rc6_mce (die Datei ist von mir handgeklöppelt, nicht im VDR/EA5/EA3.5!) wie folgt:

Code:

[email protected]:~# ls -la /etc/vdr/rc6_mce*

-rw-r--r-- 1 root root 1943 Aug 14 14:17 /etc/vdr/rc6_mce

-rw-r--r-- 1 root root 1423 Okt 18  2016 /etc/vdr/rc6_mce.0_keine_menue_taste

-rw-r--r-- 1 root root 1530 Dez  7  2013 /etc/vdr/rc6_mce.1

-rw-r--r-- 1 root root 1629 Okt 19  2016 /etc/vdr/rc6_mce_keine_0_bis_9

-rw-r--r-- 1 root root 1454 Jan 14  2014 /etc/vdr/rc6_mce.orig

[email protected]:~# sdiff /etc/vdr/rc6_mce /etc/vdr/rc6_mce_keine_0_bis_9 | more

# table rc6_mce, type: RC6                    # table rc6_mce, type: RC6

# alt 2020: 0x800f0400 KEY_NUMERIC_0                  |    0x800f0400 KEY_NUMERIC_0

# alt 2020: 0x800f0401 KEY_NUMERIC_1                  |    0x800f0401 KEY_NUMERIC_1

# alt 2020: 0x800f0402 KEY_NUMERIC_2                  |    0x800f0402 KEY_NUMERIC_2

# alt 2020: 0x800f0403 KEY_NUMERIC_3                  |    0x800f0403 KEY_NUMERIC_3

# alt 2020: 0x800f0404 KEY_NUMERIC_4                  |    0x800f0404 KEY_NUMERIC_4

# alt 2020: 0x800f0405 KEY_NUMERIC_5                  |    0x800f0405 KEY_NUMERIC_5

# alt 2020: 0x800f0406 KEY_NUMERIC_6                  |    0x800f0406 KEY_NUMERIC_6

# alt 2020: 0x800f0407 KEY_NUMERIC_7                  |    0x800f0407 KEY_NUMERIC_7

# alt 2020: 0x800f0408 KEY_NUMERIC_8                  |    0x800f0408 KEY_NUMERIC_8

# alt 2020: 0x800f0409 KEY_NUMERIC_9                  |    0x800f0409 KEY_NUMERIC_9

0x800f0400 KEY_0                          <

0x800f0401 KEY_1                          <

0x800f0402 KEY_2                          <

0x800f0403 KEY_3                          <

0x800f0404 KEY_4                          <

0x800f0405 KEY_5                          <

0x800f0406 KEY_6                          <

0x800f0407 KEY_7                          <

0x800f0408 KEY_8                          <

0x800f0409 KEY_9                          <

# Ende Aenderungen 2020                          <

0x800f040a KEY_DELETE                        0x800f040a KEY_DELETE

0x800f040b KEY_ENTER                        0x800f040b KEY_ENTER

^C

[email protected]:~#

Nach der Änderung meiner handgemachten nicht-standard rc6_mce Keymapping oder Keytable von bisher:
KEY_NUMERIC_0

auf nun:
KEY_0

und schon kommt bei irw der KEY_0 und die Taste 0 bzw. alle numerischen Tasten der RC6-MCE funktionieren:

Code:

[email protected]:~# irw

000000008001000b 00 KEY_0 devinput

^C

[email protected]:~#

Vorher muss aber der IR-Empfänger geladen werden/funktionieren, er muss auch RC6 verstehen, die Keymap rc6_mce muss irgendwie via ir-keytable geladen werden.

Aber lirc_options.conf, remote.conf habe ich jetzt nicht angefasst.....

RE: Neuinstallation mit easyVDR stable - gb - 15.08.2020

Sorry wenn ich das so sagen muss...
Das bringt uns und der Allgemeinheit kein Stück weiter, wenn eigene Dateien irgendwie irgendwo reingefummelt werden. Wenn wir was default zum laufen bekommen wollen und das zukünftig immer, müssen schon die original zur Verfügung stehenden Systemdateien genutzt werden. Da der Bruch von lirc zwischen easyVDR3 zu easyVDR5 recht heftig ist/war, gehts nur so um den Problemkindern auf die schliche zu kommen.

Gruß Aaron

RE: Neuinstallation mit easyVDR stable - grumpf - 15.08.2020

(15.08.2020, 11:50)gb schrieb: Sorry wenn ich das so sagen muss...
Das bringt uns und der Allgemeinheit kein Stück weiter, wenn eigene Dateien irgendwie irgendwo reingefummelt werden. Wenn wir was default zum laufen bekommen wollen und das zukünftig immer, müssen schon die original zur Verfügung stehenden Systemdateien genutzt werden. Da der Bruch von lirc zwischen easyVDR3 zu easyVDR5 recht heftig ist/war, gehts nur so um den Problemkindern auf die schliche zu kommen.

Gruß Aaron

Das ist mir klar, dass mein Hack hier nichts für die Allgemeinheit bringt. Hast du einen Wiki-Eintrag für mich? Dann kann ich die Fehlersuche einmal dokumentieren - so ir-keytable -t, evtest, socat nach dem lirc, lsmod auf die rc-Treiber, der modload, für rc6, falls ein Treiber fehlt, lirc-make-devinput, ein Kommentar zu USB-HID-Tastauren, usw.?

Tschö

Gunther

RE: Neuinstallation mit easyVDR stable - nickinicki - 31.10.2020

So, jetzt mal uinter der richtigen Überschrift.....

Jep, mit USB Installation um einiges schneller. TBS Treiber ließen sich heute auch problemlos installieren! Dop! i7 CPU hat sofort ein Bild gebracht, egal ob SD oder HD.

...das war eine Testinstallation und jetzt möchte ich auf die SSD installieren, quasi offziell zum Verwenden.

Ich habe neben der SSD, auf die das System installiert werden soll, noch eine 1TB Festplatte für aufnahmen.

Wie gehe ich step by step vor, damit diese 1TB Platte mit eingebunden wird?

RE: Neuinstallation mit easyVDR stable - nickinicki - 31.10.2020

Ich habe jetzt mal versucht das ähnlich wie unter 3.5 manuell einzubinden. Aber dann kommt nach dem festlegen des Einbingunspfades /media/easyvdr01 der Hinweis "Löschen der Konfigurationsdateien fehlgeschlagen...."

Wie komme ich hier weiter?

RE: Neuinstallation mit easyVDR stable - mango - 31.10.2020

Hallo,

(31.10.2020, 17:02)nickinicki schrieb: TBS Treiber ließen sich heute auch problemlos installieren!

musste noch nee Firmware installiert werden?
Bitte die Ausgabe posten

Code:
sudo dmesg | grep dvb*

Gruss
Wolfgang