Zitat0x8000 war nur der Versuch, die Pid 0 für das CAM-Triggern zu verwenden. Das ging aber nicht und wurde daher wieder enfernt.
CA 11 (=0x11) oder 12 (=0x12) ist meiner Meinung nur erforderlch, wenn beide CI-Slots verwendet werden und einzelne Programme dem richtigen Slot zugeordnet werden sollen. Mit nur einem Modul gibt es ja keine große Auswahl, daher wird es auch nichts bringen.
LG Helmut
hier zum Testen
cinfo
ar 16 19:39:59 BM2LTS-N64native-MCLI rc.local[1595]: Error resolving ntp.ubuntu.com: System error (-11)
Kann auch nicht gehen:
Wieso fehlt das: /usr/sbin/dhcpcd: No such file or directory?
Da stimmt irgendetwas mt deiner Installation nicht. Du hast ja sehr häufig Fehler wegen fehlender Verzeichnisse, shared Libraries oder Zugriffsrechten. Möglicherweise gibt aber auch deine hdd den Geist auf.
LG Helmut
Alles anzeigenBeim Durchlesen deines vorletzten Commit auf github ist mir aufgefallen, das es durch die TriggerCam-Option ohne eingestecktem Modul und ohne --cam-disable in SetChannelDevice() immer Fehermeldungen geben müsste. Stimmt das, ode ist es nur ein Trugschluß von mir?
Im Anhang auf jedefall ein Patch für dein mcli-0.9.6_pre5 mit einigen kleineren Anpassungen dazu.
Deinen cam-disable Commit habe ich auch etwas vereinfacht, indem ich gleich in ProcessArgs() das DEBUG_BIT_Action_SkipTriggerCam Bit in m_debugmask entsprechend setzte. Damit entfallen später ein paar Überprüfungen.
LG helmut
es war schon Absicht, daß eine Option nicht explizit an der m_debugmask was ändert...hab vom Patch mal die anderen Teile übernommen, pre6 ist im "master".
cinfo baust du bitte den pre6 ... ich werde dann den testen.
cinfo
Ich habs mir angesehen.
0318b ist so wie zu erwarten - nach 30s wird das Datum ans CAM gesendet, dann hört die Enschlüsslung auf und durch die ScrambleDetection wird ein Retune veranlasst. Also alles ganz "normal" und (fast) unter Kontrolle.
In 0318a sieht im Netceiver alles normal aus und die Entschlüsslung sollte beginnen. Möglicherweise dauerte es aber immer etwas zu lange bis die ECMs empfangen wurden und die ScrambleDetection reagiert nach 3 sec mit CAM0: wan't decrypt channel...
Lass den VDR etwas länger auf die Entschlüsselung warten - z.B 5 Sekunden mit --scrtmo=5.
assuming manual start of VDRist nicht neu. Zum Setzten des inactivity-Timers versucht VDR festzustellen, ob es ein manueller Start oder ein Wakeup-Start für eine Timeraufnahme war. Bei Timeraufnahmen beended sich der VDR gleich nach der Aufnahme wieder, sonst erst nach der Inactivity-Zeit wie sie im Setup eingestellt ist - z.B. nach 2 Stunden ohne User Eingriff. Alsmanual start gilt, wenn in den nächsten 10 Minuten keine Aufnahme ansteht.
LG Helmut
Hast Du den Netceiver an einem VLAN hängen (eth0.2 -> VLAN 2). Ggf. hilft ein Switch zwischen VDR und Netceiver, damit die Links wenigstens immer aktiv sind (übliche 1 Gbps Switches brauchen weniger als 1 Watt). Alternativ die systemd-Konfig von VDR erweitern auf
Requires sys-subsystem-net-devices-eth0.device
After sys-subsystem-net-devices-eth0.device
(ggf. geht das sogar noch samt VLAN-Subinterface), prüf mal Dein System mit
systemctl -a |grep eth
Ja de NCV hängt am VLAN und alle Geräte hängen an einem switch der die Ports aktiv lässt (und der CISCO brät über 10W 
)
Das Problem ist, dass mcli mit failed returned wenn es das Device noch nicht gibt.
PreInitMcli: can't find specified device 'eth0.2'
Warum nicht einfach endlos warten bis das device da ist ? Ist doch besser als den vdr zu stoppen.
In BM2LTS ist es so, dass der Network-Manager niht zur Verwaltung verwendet wird, sondern das noch über network/interfaces läuft.
Bei einer statischen Konfig. hat man das Prob ohnehin nicht ...
root@BM2LTS-N64native-MCLI:~# systemctl -a |grep eth
sys-devices-pci0000:00-0000:00:1f.6-net-eth0.device loaded active plugged Ethernet Connection (10) I219-V
sys-devices-virtual-net-eth0.2.device loaded active plugged /sys/devices/virtual/net/eth0.2
sys-subsystem-net-devices-eth0.2.device loaded active plugged /sys/subsystem/net/devices/eth0. 2
sys-subsystem-net-devices-eth0.device loaded active plugged Ethernet Connection (10) I219-V
ifup@eth0.2.service loaded active exited ifup for eth0.2
ifup@eth0.service loaded active exited ifup for eth0 Requires sys-subsystem-net-devices-eth0.device
After sys-subsystem-net-devices-eth0.deviceICh vermute das würde nichts bringen, da das Netzwerk vom Router ja einige Male neu gebaut wird ....
Warum nicht einfach endlos warten bis das device da ist ? Ist doch besser als den vdr zu stoppen.
Hatte bisher noch keiner bestellt...probier mal den Branch:
https://github.com/pbiering/vd…/tree/add-interface-watch
https://github.com/pbiering/vd…ering:add-interface-watch
wartet jetzt max 180 sec in 5 sec Schritte, bis das Device da ist (so der Plan, kann's hier nicht testen).
und btw. wenn das Interface weg ist, ist die Verbindung zum Netceiver weg, d.h. dann geht erst mal nix mehr, weil der Multicast-Receiver dann nichts mehr empfangen kann.
Super Danke ... leider bin ich unfähig das zu bauen und hoffe auch cinfo.
Ich habe vor ca. 30 Jahren mit der SW Entwicklung aufgehört, um einer dieser Manager zu werden (das bereue ich immer noch ein wenig ,-) )...
Damals:
Assembler 6502 (Commodore), Pascal, Siemens-SPS, General-Electric-SPS, Telemechanique-SPS, Forth, Pascal, ein bisschen c.
Automatisierung v. Sägewerken (auch in Canada ... das war geil ), Laserscanner zur Vermessung von Stämmen, Schlachthäusern, ... dann Manager in der Automatisierungtechnik http://www.keba.com und heute in der IT im Gesundheitswesen http://www.ooeg.at)
Mein Wissen reicht grad noch um meine Simatic S7-200 im Haus und meine Heizkörperthermostate (HR20), die auch in c programmiert sind, am Laufen zu halten.
Ev. wäre ich in der Lage wenn mir cinfo die ganze Entwicklungsumgebung zippen würde "auf den Knopf zu drücken" und kleine Änderungen vorzunehmen, aber ich fürchte ich produziere mehr Supportaufwand als Nutzen
fein fein - > und hier was zum Testen in BM2LTS v3.4.36
cinfo
Mar 21 14:09:50 BM2LTS-N64native-MCLI vdr: [1121] mcli::PreInitMcli: found specified device 'eth0.2' in /proc/net/if_inet6 (after 145 sec)
Ich habe keine Eile mit einem neuen Release im Moment....meldet Euch einfach, wenn fertig.
HelmutB pbrb hängt das Problem dass das netcvupdate nicht mehr geht am mcli ? (ich kann aktuell nur mit den reels uploaden):
root@BM2LTS-N64native-MCLI:~# /usr/sbin/netcvupdate -d eth0.2 -i fe80::208:54ff:fe54:b261 -U /tmp/netceiver_C94_2lnb_30.conf
UUID fe80::208:54ff:fe54:b261: Uploading /tmp/netceiver_C94_2lnb_30.conf ... ftp: q: unknown option
Upload failed (ret=256)
root@BM2LTS-N64native-MCLI:/tmp# /usr/sbin/netcvdiag -s
connect failure to /var/tmp/mcli.sock: No such file or directoryAlles anzeigenHi,
MCLI - Tools sind ja OK
CodeAlles anzeigen/vdr-plugin-mcli/mcast/tool# ./netcvdiag -h ./netcvdiag: invalid option -- 'h' netcvdiag - NetCeiver diagnosis tool, version 0.99.34(__DATE____TIME__) (c) BayCom GmbH Usage: netcvdiag <options> Options: -a Show all -u Show UUIDs -t Show tuners -c Get NetCeiver count -S Show satellite settings -s Show tuner state -r <n> Repeat every n seconds -v Show HW/SW-versions -P <path> Set API socket /vdr-plugin-mcli/mcast/tool# ./netcvlogview mode:1 port:23000 mcg:1 [ ff18:5100:: ] /vdr-plugin-mcli/mcast/tool# ./netcvupdate -H ./netcvupdate: invalid option -- 'H' netcvupdate - NetCeiver update tool, version 0.99.34(__DATE____TIME__) (c) BayCom GmbH Usage: netcvupdate <options> <actions> Actions: -l List all seen NetCeivers and their UUID -L List available FWs -X <Update.tgz> Update with given file -U <configfile> Upload configfile -D Download configfile netceiver.conf -I <version> Inactivate FW version -E <version> Enable FW version -Z <version> Remove FW version -K Restart streaming server -R Issue reboot Options: -A Use all found NetCeivers (mcli must be running) -i <uuid> Use specific UUID (can be used multiple times) *** Either -A or -i must be given for most actions! *** Rare options: -d <device> Set network device (default: eth0) -F <ftp-command> Set ftp command/path *** ftp command must understand the -q (timeout) option! *** -P <path> Set API socket -u <user> Set username -p <password> Set password -r No reboot after update -q Be more quiet
nur der mcli.sock ist das Problem
Code/vdr-plugin-mcli/mcast/tool# ./netcvdiag -a connect failure to /var/tmp/mcli.sock: Connection refusedcinfo
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
