Jetzt bin ich wieder bei der /etc/network/interfaces
um dies dauerhaft einzustellen ?
So:
/etc/network/interfaces
Jetzt bin ich wieder bei der /etc/network/interfaces
um dies dauerhaft einzustellen ?
So:
/etc/network/interfaces
So etwas, sollte es für den VDR und das osd2web Plugin geben, aber davon sind wir ja noch Lichtjahre entfernt.
Das passt ja schonmal.
Dass, wenn Du dass ddci2 als erstes lädst, dann auch als erstes die "Hardware CAMs" geladen werden, ist klar. Was mich aber wundert ist, dass bei Dir die Zuordnungen nicht passen?
Bei mir ist es z.B, so dass zuerst die "harten" und dann die "weichen" CAMs geladen werden, allerdings passt die Zuordnung, CAM 1, CAM 2, etc, immer.
grep "CAM 1:" /log/messages
Aug 04 18:16:17 [vdr] [19901] CAM 1: module present
Aug 04 18:16:18 [vdr] [19901] CAM 1: module ready
Aug 04 18:16:20 [vdr] [19901] CAM 1: AlphaCrypt, 01, 4A20, 4A22
Aug 04 18:16:20 [vdr] [19901] CAM 1: system ids: 098C
Aug 04 18:16:21 [vdr] [19901] CAM 1: replies to QUERY - multi channel decryption (MCD) possible
Aug 04 18:16:21 [vdr] [19901] CAM 1: supports multi transponder decryption (MTD)
Aug 04 18:16:21 [vdr] [19901] CAM 1: activating MTD support
Aug 04 18:16:29 [vdr] [19835] CAM 1: ready, master (AlphaCrypt)
vdr01_64 ~ #
vdr01_64 ~ # grep "CAM 2:" /log/messages
Aug 04 18:16:17 [vdr] [19905] CAM 2: module present
Aug 04 18:16:19 [vdr] [19905] CAM 2: module ready
Aug 04 18:16:22 [vdr] [19905] CAM 2: Irdeto Access, 01, CAFE, BABE
Aug 04 18:16:26 [vdr] [19905] CAM 2: system ids: 06CB
Aug 04 18:16:29 [vdr] [19905] CAM 2: doesn't reply to QUERY - only a single channel can be decrypted
Aug 04 18:16:29 [vdr] [19835] CAM 2: ready, master (Irdeto Access)
vdr01_64 ~ #
Alles anzeigen
Ich gebe Dir aber insoweit Recht, dass die Lösung mit der "cam.data" noch nicht der Weisheit letzter Schluss ist und kann Dir nur empfehlen, diese einfach von Hand anzulegen und dann auf schreibgeschützt zu setzten.
Aber der VDR muss trotzdem gepacht sein, damit gaphtft-ng baut und läuft.
Nun, eine gültige HD+ Karte brauchst Du schon, sonst funktioniert das nicht.
Nun ja, wenn Du graphtftng nicht verwendest, brauchst Du den ja auch nicht.
[...] HD+ bietet wohl ab sofort den Bundesligateil, der nicht bei Sky gezeigt wird, gegen Einwurf kleiner Münzen versteht sich. ...
Kostet 5€ pro Monat. --> https://www.hd-plus.de/web-shop/eurosport-paket
Wer eine HD+ Karte hat, muss diese aber freischalten lassen. (3 Monate gratis)
Wo finde ich denn den XEN-Kernel, der zu openSUSE 42.3 passt? ...
Hier? --> https://software.opensuse.org/package/kernel-xen
Auch interessant: --> https://doc.opensuse.org/docum…on/book.virt_color_en.pdf
acpitz-virtual-0 klingt in der Tat nach irgendwas Virtuellem.
Hast Du sensors-detect ausgeführt?
acpitz steht für "ACPI thermal zone" damit werden die Temperaturen der CPU nicht vom integrierten Sensor ausgelesen, sondern kommen vom BIOS.
Bei mit passt es:
vdr01_64 ~ # dvb-fe-tool -a0 -f0 -m -v -c10
Device STV0910 (/dev/dvb/adapter0/frontend0) capabilities:
CAN_2G_MODULATION
CAN_FEC_AUTO
CAN_INVERSION_AUTO
CAN_MULTISTREAM
CAN_QPSK
DVB API Version 5.10, Current v5 delivery system: DVBS2
Supported delivery systems:
DVBS
[DVBS2]
DSS
Got parameters for DVBS2:
FREQUENCY = 4293253296
INVERSION = AUTO
SYMBOL_RATE = 22000000
INNER_FEC = 2/3
MODULATION = PSK/8
PILOT = ON
ROLLOFF = 35
POLARIZATION = OFF
STREAM_ID = 0
DELIVERY_SYSTEM = DVBS2
Lock (0x1f) Signal= -33,95dBm C/N= 14,40dB preBER= 0
Lock (0x1f) Signal= -33,92dBm C/N= 14,30dB preBER= 0
Lock (0x1f) Signal= -33,84dBm C/N= 14,40dB preBER= 0
Lock (0x1f) Signal= -33,84dBm C/N= 14,30dB preBER= 0
Lock (0x1f) Signal= -33,88dBm C/N= 14,40dB preBER= 0
Lock (0x1f) Signal= -33,93dBm C/N= 14,30dB preBER= 0
Lock (0x1f) Signal= -33,88dBm C/N= 14,40dB preBER= 0
Lock (0x1f) Signal= -33,91dBm C/N= 14,40dB preBER= 0
Lock (0x1f) Signal= -33,85dBm C/N= 14,20dB preBER= 0
Lock (0x1f) Signal= -33,89dBm C/N= 14,50dB preBER= 0
SEC: set voltage to OFF
ERROR FE_SET_VOLTAGE: Die Operation ist nicht erlaubt
vdr01_64 ~ #
Alles anzeigen
femon taugt nichts, nimm dvb-fe-tool.
[...] Das Pin-Plugin baut, funktioniert auch teilweise, hängt sich aber auf wenn man beispielsweise eine Sendung zur Sperrliste hinzufügt - sprich das Menü bleibt offen und der VDR bleibt unbedienbar...
Dann verstehe ich Dein Problem nicht, dann ist doch der VDR für das Kind "gesichert".
Versuche es mal mit einem aktuellen Kernel.
Zum Thema "Konfliktprüfung" würde mich interessieren, ob es eine Möglichkeit gibt, epgsearch beizubringen mit verschlüsselten Sendern in Verbindung mit einem CAM umzugehen?
Der VDR unterstützt ja mittlerweile grundsätzlich mal MTD/MCD, leider aber unterstützten das ja bekanntermaßen nicht alle CAMs.
Die Frage ist nun, ob man epgsearch evtl. sagen kann, welches CAMs MTD, bzw. MCD unterstützten und dann ggf. einen Konflikt meldet?
3PO: epgsearch hat mehr oder weniger den Code von device.c im vdr kopiert, um Konflikte zu erkennen. Das ganze ist allerdings auf einem älteren Stand. Mit verschlüsselten Sendern und CAMs kann ich nichts testen, deshalb traue ich mich da nicht ran. ...
Nun, eigentlich könnte man man das über eine simple *.conf lösen. In der cam.data steht ja schon drin, welcher Kanal, mit welchem CAM entschlüsselt werden kann.
Jetzt bräuchte man doch nur noch ein Config File, das epgsearch mitteilt, wie viele Kanäle, das jeweilige CAM gleichzeitig decodieren kann.
Z.B. so:
Wie wird denn X bei Dir gestartet, bzw. wer startet es?
Läuft denn irgendein Displaymanager, z.B. lightdm?