[gelöst] mcli ERROR: video data stream broken

pbrb · 30. März 2021

Code

/usr/sbin/netcvdiag -s
connect failure to /var/tmp/mcli.sock: No such file or directory

da läuft wohl vdr aktuell nicht mit dem mcli-Plugin, weil der Socket wird vom Plugin erstellt, good case:

Code

ll /var/tmp/mcli.sock 
srwxrwxrwx 1 vdr video 0 30. Mär 21:22 /var/tmp/mcli.sock

# man bemerke den user "vdr"

netcvdiag -s

UUID <fe80::208:54ff:fe**:****>:
      slot 0.0, type DVB-C, used:  12
      LOCK   , frequency 314000000Hz (314006.7kHz)
      strength f6f6, snr f7f7, ber 0000, unc 0000
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
...

Alles anzeigen

Allerdings:

Code

/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)

Das ist eine andere Baustelle...in der Online-Hilfe von "netcvupdate" (was btw. den Socket nicht benutzt), steht, daß nur ftp-Clients funktionieren, die "-q" unterstützen

Code

netcvupdate -h
netcvupdate: invalid option -- 'h'
...
 *** ftp command must understand the -q (timeout) option! ***

...hier mal reproduziert:

Code

netcvupdate -d eth1 -i fe80::208:54ff:fe**:**** -D
UUID fe80::208:54ff:fe**:****: Downloading netceiver.conf ... ftp: q: unknown option
Download failed (ret=256)

das liegt daran, weil sich "netcvupdate" die Implementierung eines FTP-Clients gespart hat und nur die Befehle wrappt....kann man so machen, kann aber auch später mal einen auf die Füße fallen.

Da ich auf die Schnelle keinen FTP-Client auf Fedora gefunden, der noch -q unterstützt, habe ich mal einen neuen Schalter "-n" eingefügt, der auf "lftp" umschaltet, damit tut es wenigstens wieder:

Code

/opt/reel/sbin/netcvupdate -q -n  -d eth1 -i fe80::208:54ff:fe**:**** -D
INFO  : disable verbose mode
INFO  : enable options for FTP client 'lftp'
UUID fe80::208:54ff:fe**:****: Downloading netceiver.conf ...
Download done

/opt/reel/sbin/netcvupdate -q -n  -d eth1 -i fe80::208:54ff:fe**:**** -U netceiver.conf
INFO  : disable verbose mode
INFO  : enable options for FTP client 'lftp'
UUID fe80::208:54ff:fe**:****: Uploading netceiver.conf ...
Upload done

Alles anzeigen

Viel Erfolg damit...(nach Installation von 'lftp') - Code ist im "master" aktualisiert.

cinfo · 31. März 2021

Zitat

Viel Erfolg damit...(nach Installation von 'lftp') - Code ist im "master" aktualisiert.

zum Testen

lftp

Code

sudo apt-get install -y lftp

Code

./netcvupdate -h
netcvupdate - NetCeiver update tool, version 0.99.35 (Mar 31 2021 06:12:54)
(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)
           -e                Enable debugging
           -h|?              This online help
  *** 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 in case '-n' is not used! ***
           -P <path>         Set API socket
           -u <user>         Set username
           -p <password>     Set password
           -r                No reboot after update
           -n                Use next-generation FTP client 'lftp'
           -q                Be more quiet

Alles anzeigen

Code

INFO  : enable options for FTP client 'lftp'
connect failure to /var/tmp/mcli.sock: No such file or directory (are you root?)

mcli.sock läuft nicht als root, damit geht es zur Zeit nicht

cinfo

pbrb · 31. März 2021

"netcvupdate" benutzt den Socket aber nicht für download/upload, aber mindestens bei "list":

Code

## VDR läuft

$ strace -f -e connect /opt/reel/sbin/netcvupdate -l
connect(3, {sa_family=AF_UNIX, sun_path="/var/tmp/mcli.sock"}, 110) = 0
fe80::208:54ff:fe**:****    AVR0038/FPGAC94
+++ exited with 0 +++

$ ll /var/tmp/mcli.sock
srwxrwxrwx 1 vdr video 0 31. Mär 07:32 /var/tmp/mcli.sock


## VDR gestoppt, Socket-Datei existiert noch (wird wohl nicht gelöscht beim Stop, aber auf der anderen Seite lauscht nix mehr...)

$ /opt/reel/sbin/netcvupdate -l
connect failure to /var/tmp/mcli.sock: Connection refused (are you root?)

$ /opt/reel/sbin/netcvupdate -q -n  -d eth1 -i fe80::208:54ff:fe**:**** -D
INFO  : disable verbose mode
INFO  : enable options for FTP client 'lftp'
UUID fe80::208:54ff:fe**:****: Downloading netceiver.conf ... 
Download done

Alles anzeigen

-> solange man die IPv6-Adresse vom Netceiver kennt, kommt man auch ohne Socket drauf...

BTW: gibt auch noch einen neuen Schalter "-e", da sieht man die gewrappte "Magie" (beim Download)

Code

DEBUG : execute FTP command: lftp --norc
DEBUG : execute FTP script
------
open fe80::208:54ff:fe**:****%eth1
user root root
cd /mmc/etc/
get netceiver.conf
quit
------

Analog der Upload...mehr macht das Binary in dem Fall nicht...

cinfo · 31. März 2021

Hm,

da läuft was schräg, kommt immer wieder das "mcli.sock" abgefragt wird?

VDR läuft:

Code

# strace -f -e connect netcvupdate -l
connect(3, {sa_family=AF_UNIX, sun_path="/var/tmp/mcli.sock"}, 110) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
connect failure to /var/tmp/mcli.sock: No such file or directory (are you root?)
+++ exited with 255 +++

Code

ll /var/tmp/mcli.sock
srwxrwxrwx 1 root root 0 Apr  1 08:32 /var/tmp/mcli.sock=

cinfo

pbrb · 31. März 2021

bei "-l" ist der Zugriff auf den Socket valide, denn damit bekommt "netcvupdate" raus, welche Netceiver denn so existieren (die das MCLI-Plugin via Multicast "einsammelt"). Für up/download ist aber nur die IPv6-Adresse interessant...die "-l" anzeigt, wenn man die nicht vorher schon weiß.

BTW: "netcvupdate" hat keinen eigenen Netceiver-Detector integriert (wobei man die via IPv6-Multicast auch ohne MCLI-Plugin und Socket finden würde):

Code

ping6 -c 1  ff02::16%eth1
PING ff02::16%eth1(ff02::16%eth1) 56 data bytes
64 Bytes von fe80::208:54ff:fe**:****%eth1: icmp_seq=1 ttl=64 Zeit=1.10 ms

--- ff02::16%eth1 ping statistics ---
1 Pakete übertragen, 1 empfangen, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.098/1.098/1.098/0.000 ms

cinfo · 31. März 2021

Super das hilft

Code

ping6 -c 1  ff02::16%eth0.2
PING ff02::16%eth0.2(ff02::16%eth0.2) 56 Datenbytes
64 Bytes von fe80::208:54ff:fe52:xxxx%eth0.2: icmp_seq=1 ttl=64 Zeit=8.06 ms

# netcvupdate -n -d eth0.2 -i fe80::208:54ff:fe52:xxxx -D
INFO  : enable options for FTP client 'lftp'
UUID fe80::208:54ff:fe52:dace: Downloading netceiver.conf ...
---- Löse Hostadresse auf...
---- 1  Adresse gefunden: fe80::208:54ff:fe52:dace%eth0.2
---- Verbinde mit fe80::208:54ff:fe52:xxxx%eth0.2 (fe80::208:54ff:fe52:xxxx%eth0.2) Port 21
<--- 220 netceiver FTP server (GNU inetutils 1.4.1) ready.
---> FEAT
<--- 500 'FEAT': command not understood.
---> AUTH TLS
<--- 500 'AUTH TLS': command not understood.
---> USER root
<--- 331 Password required for root.
---> PASS root
<--- 230 User root logged in.
---> PWD
<--- 257 "/" is current directory.
---- CWD path to be sent is `/mmc/etc'
---> CWD mmc
<--- 250 CWD command successful.
---> CWD etc
<--- 250 CWD command successful.
---> TYPE I
<--- 200 Type set to I.
---> SIZE netceiver.conf
<--- 213 19907
---> MDTM netceiver.conf
<--- 213 19800101000000
---> EPSV
<--- 229 Entering Passive Mode (|||1024|)
---- Verbinde Daten Socket mit (fe80::208:54ff:fe52:xxxx%eth0.2) Port 1024
---- Datenverbindung hergestellt
---> RETR netceiver.conf
<--- 150 Opening BINARY mode data connection for 'netceiver.conf' (19907 bytes).
<--- 226 Transfer complete.
---- Got EOF on data connection
---- Schließe den Daten Socket
---> QUIT
<--- 221 Goodbye.
---- Schließe den Kontroll - Socket
Download done

Alles anzeigen

cinfo

gggggg · 31. März 2021

Danke Euch, netcvupdate Up/Download/Kill funktionieren ... für die restl. Funktionen wo der sock benötigt wird müßte man den vdr als User vdr starten ...

Was ich nicht verstanden habe ist, wie die langfristige Lösung aussehen könnte ...

Da sieht man wer Aller noch alte reel Schätzchen (NCV,...) stehen hat .... hahaha

pbrb · 31. März 2021

Zitat von gggggg

Danke Euch, netcvupdate Up/Download/Kill funktionieren ... für die restl. Funktionen wo der sock benötigt wird müßte man den vdr als User vdr starten ...

Was ich nicht verstanden habe ist, wie die langfristige Lösung aussehen könnte ...

Versteh ich nicht so recht....davon abgesehen, daß der vdr sowieso als "vdr" laufen sollte und nicht als "root", die bisherigen Fehlermeldungen schauen eher so aus, als wäre die Socket-Datei gar nicht da oder hat falsche Berechtigungen.

hier sieht das wie folgt aus:

Code

lsof /var/tmp/mcli.sock
COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF  NODE NAME
vdr     1959  vdr    7u  unix 0x000000006342a9cf      0t0 40017 /var/tmp/mcli.sock type=STREAM

ll /var/tmp/mcli.sock
srwxrwxrwx 1 vdr video 0 31. Mär 17:41 /var/tmp/mcli.sock

-> der Socket kann von jedermann (root oder nicht-root) benutzt werden, falls (aus welchen Gründen auch immer) bei Deinem System der Socket "root" gehört und kein 777 als Berechtigung hat, mal temporär

Code

chmod 777 /var/tmp/mcli.sock

ausführen. Falls sich der Socket gar nicht an dieser Stelle befindet, dann mal prüfen, wieso nicht und ggf. Plugin-Option "sock-path" prüfen/justieren.

Zitat

Da sieht man wer Aller noch alte reel Schätzchen (NCV,...) stehen hat .... hahaha

Sogar zwei....eine umgebaute und eine Original....die umgebaute ist immer noch Developer-Kiste...nebenbei immer noch dabei, eHD stabil zu bekommen...zickt immer noch.

BTW: schon mal in einem anderen Forumsbeitrag gefragt: ich suche immer noch die Entwicklungsumgebung für eHD, um das MIPS-Linux-Image zu bauen und den MIPS-hdplayer zu kompilieren....denn ich habe da hdplayer und MIPS-Linux-Totalabstürze und muß da mal Debug und Loggingcode reinbauen....und ggf. auch an der Codequalität arbeiten, denn da wurde vor 10+ Jahren einiges mit heißer Nadel gestrickt...mir sind schon auf mcli/reelbox-pluginseite einige Problemstellen über den Weg gelaufen...

cinfo · 1. April 2021

Zitat

chmod 777 /var/tmp/mcli.sock

ausführen. Falls sich der Socket gar nicht an dieser Stelle befindet, dann mal prüfen, wieso nicht und ggf. Plugin-Option "sock-path" prüfen/justieren.

das passt eigentlich schon alles

Code

ll /var/tmp/mcli.sock
srwxrwxrwx 1 root root 0 Apr  1 08:32 /var/tmp/mcli.sock=

Code

strace -f -e connect netcvupdate -l
connect(3, {sa_family=AF_UNIX, sun_path="/var/tmp/mcli.sock"}, 110) = -1 ECONNREFUSED (Verbindungsaufbau abgelehnt)
connect failure to /var/tmp/mcli.sock: Connection refused (are you root?)
+++ exited with 255 +++

cinfo

pbrb · 1. April 2021

Die Exsistenz der Socket-Datei heißt noch nicht, daß da ein Prozeß auf der anderen Seite auch lauscht...was zeigt die Ausgabe von:

Code

lsof /var/tmp/mcli.sock

vermute nämlich nichts....weil VDR mit dem MCLI-Plugin aktuell nicht läuft....und hier ist der Socket-Server implementiert..

cinfo · 1. April 2021

Zitat

vermute nämlich nichts....weil VDR mit dem MCLI-Plugin aktuell nicht läuft....und hier ist der Socket-Server implementiert..

Code

lsof /var/tmp/mcli.sock

richtig nichts

der vdr läuft und mcli ist geladen

Code

--record=/media/hd/recordings
--video=/media/hd/recordings
--user=root
--grab=/tmp
--port=2001
--watchdog=0
--lirc=/var/run/lirc/lircd
--shutdown=/usr/sbin/power
--plugin=mcli --ifname eth0.2 --dvb-s2 6 --mld-reporter-disable --sock-path /var/tmp/mcli.sock
--plugin=softhddrm -f -d :0.0 -a hdmi  # oder sowas wie hw:card=HDMI,device=7 - das hängt von der eigenen Hardare ab -p hdmi -c PCM -g 1920x1080+0+0 -C HDMI-A-1 -r 50
--plugin=skindesigner -e /var/cache/vdr/ -l /usr/share/reel/channellogos -s /etc/vdr/plugins/skindesigner/skins/shady/
--plugin=bgprocess
--plugin=epgsearch
--plugin=extrecmenung
--plugin=femon
--plugin=iptv -d 4
--plugin=live --port=8008 --ip=192.168.10.136 --epgimages=/var/cache/vdr/
--plugin=markad -l /opt/vdr/plugins/markad
--plugin=menuorg
--plugin=osd2web -p 4444 -l /usr/share/reel/channellogos -s png -e /var/cache/vdr
--plugin=osdteletext -d /run/shm/vtx -n 48 -s packed
--plugin=streamdev-server
--plugin=systeminfo
--plugin=tvguideng -l /usr/share/reel/channellogos/ -e /var/cache/vdr/ -i /etc/vdr/plugins/tvguide/icons/
--plugin=vnsiserver
--plugin=weatherforecast

Alles anzeigen

cinfo

pbrb · 1. April 2021

Das ist ja eigenartig, mach mal

Code

lsof | grep sock

Aber egal, was da rauskommt: VDR stoppen, Socket-Datei mal von Hand löschen und VDR wieder starten, danach sollte die Socket-Datei wieder da sein und lsof was zeigen...ansonsten muß ich mal den Code anschauen und paar Checks/Debug-Statements einbauen, damit man den Fehler eingrenzen kann...

cinfo · 1. April 2021

ich denke mcli.sock wird erstellt aber auch gleich wieder beendet nach dem VDR-Start

Code

# lsof | grep sock
systemd       1                            root   29u     unix 0xffff9e79c2293000      0t0      19079 /run/rpcbind.sock type=STREAM
systemd       1                            root   40u     unix 0xffff9e79c2292c00      0t0      19105 /run/systemd/journal/socket type=DGRAM
systemd       1                            root   62u     unix 0xffff9e79c21d2000      0t0      22813 /run/acpid.socket type=STREAM
systemd       1                            root   63u     unix 0xffff9e79c21d1400      0t0      22819 /run/avahi-daemon
socket type=STREAM
systemd       1                            root   64u     unix 0xffff9e79c21d3400      0t0      22823 /run/cups/cups.sock type=STREAM
systemd       1                            root   65u     unix 0xffff9e79c21d1000      0t0      22827 /run/dbus/system_bus_socket type=STREAM
systemd-j   430                            root    5u     unix 0xffff9e79c2292c00      0t0      19105 /run/systemd/journal/socket type=DGRAM
rpcbind     526                            _rpc    3u     unix 0xffff9e79c2293000      0t0      19079 /run/rpcbind.sock type=STREAM
rpcbind     526                            _rpc    9u     sock                0,8      0t0      20268 protocol: UDPv6
avahi-dae   744                           avahi    3u     unix 0xffff9e79c21d1400      0t0      22819 /run/avahi-daemon
socket type=STREAM
cupsd       747                            root    3u     unix 0xffff9e79c21d3400      0t0      22823 /run/cups/cups.sock type=STREAM
dbus-daem   751                      messagebus    3u     unix 0xffff9e79c21d1000      0t0      22827 /run/dbus/system_bus_socket type=STREAM
dbus-daem   751                      messagebus    5u     sock                0,8      0t0      26393 protocol: NETLINK
dbus-daem   751                      messagebus    9u     unix 0xffff9e79c21d1800      0t0      26396 /run/dbus/system_bus_socket type=STREAM
...

Alles anzeigen

ist mcli ist nicht dabei

EDIT: ist mein Fehler diese Installation läuft in der VM, da hatte ich kein VLAN aktive -- also alles gut

cinfo

pbrb · 1. April 2021

Zitat von cinfo

EDIT: ist mein Fehler diese Installation läuft in der VM, da hatte ich kein VLAN aktive -- also alles gut

Gut zu hören, hätte mich schon arg gewundert..werd aber trotzdem mal das Logging an der Stelle erweitern, damit man das schneller sieht...

gggggg · 1. April 2021

bei mir heist die Datei .socket ... kein Aprilscherz

Code

root@BM2LTS-N64native-MCLI:~# ll /var/tmp/mcli.socket
srwxrwxrwx 1 root root 0 Apr  1 17:37 /var/tmp/mcli.socket=

kommt das vom mcli.conf ?

--ifname eth0.2 --dvb-s2 3 --debugmask 0x40 --mld-reporter-disable --sock-path /tmp/mcli.socket

Nach Änderung in .sock

Code

root@BM2LTS-N64native-MCLI:~# netcvdiag -s

UUID <fe80::208:54ff:fe54:b261>:
      slot 0.0, type DVB-S2, used:   9
      LOCK   , frequency 12460000kHz (1859.9MHz), position <19.2E>
      strength ffff, snr d884, ber 0000, unc 0000
      NIMCurrent 6
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 0.1, type DVB-S2, used:   0
      NO LOCK, frequency 12421000kHz (1821.1MHz), position <19.2E>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 1.0, type DVB-S2, used:   0
      NO LOCK, frequency 12574000kHz (1974.0MHz), position <19.2E>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 1.1, type DVB-S2, used:   0
      NO LOCK, frequency 12515000kHz (1915.0MHz), position <19.2E>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 2.0, type DVB-S2, used:   0
      NO LOCK, frequency 12343000kHz (1742.1MHz), position <19.2E>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 2.1, type DVB-S2, used:   0
      NO LOCK, frequency 12544000kHz (1944.2MHz), position <19.2E>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0

Alles anzeigen

gggggg · 1. April 2021

"Mühsam ernährt sich das Eichhörnchen"

mcli und Streamdev-Server ... ich denke da ist ein Prob ... oder ich steh wieder mal auf dem Schlauch ... hoffe ihr habt die zündende Idee:

[streamdev-server] Prioritäten richtig setzen um LiveTv und Recordings zu bevorzugen

cinfo · 1. April 2021

Zitat von gggggg

Bei mir heist die Datei .socket ... kein Aprilscherz

Zitat

Falls sich der Socket gar nicht an dieser Stelle befindet, dann mal prüfen, wieso nicht und ggf. Plugin-Option "sock-path" prüfen/justieren.

in der mcli.conf zu finden

cinfo

gggggg · 2. April 2021

Das hat nichts mit dem mcli.sock zu tun, der halt in der Distri falsch benannt war.

[streamdev-server] Prioritäten richtig setzen um LiveTv und Recordings zu bevorzugen

Da geht es darum, dass mcli den LiveTV Tuner zu Gunsten des niedriger priorisierten Streamdev-Severs wechselt. Das passiert selbst dann, wenn andere Tuner frei wären ... die Ursache kann eig. nur vdr / mcli / sreamdev sein ... vermute ich.

gggggg · 3. April 2021

Ich verstehe nicht warum sich die Tuner meines NCV nicht schlafen legen. Von 3 Tunern sollten 2 Tuner ruhen ... wenn nur LiveTV
Stromsparmodus = NO LOCK = ber deaddead, unc deaddead= NIMCurrent 0

pbrb habe ich das richtig verstanden, dass du auch den Netceiver source hast ? Ev. sieht man da was Alles das Standbytimout zurück setzt

HelmutB welche debug_mask ist das Minimum um zu sehen wann mcli was von einem Tuner will ?

Solange ich nach dem Hochfahren den Kanal nicht wechsle ist Alles wie erwartet. Von den 6 (der NUC auf dem ich teste hat 3 zugeteilt) schlafen 5:

Code

UUID <fe80::208:54ff:fe54:b261>:
      slot 0.0, type DVB-S2, used:   8
      LOCK   , frequency 12460000kHz (1859.6MHz), position <19.2E>
      strength ffff, snr d9f8, ber 0000, unc 0000
      NIMCurrent 9
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 0.1, type DVB-S2, used:   0
      NO LOCK, frequency 0kHz (0.0MHz), position <180.0W>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 1.0, type DVB-S2, used:   0
      NO LOCK, frequency 0kHz (0.0MHz), position <180.0W>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 1.1, type DVB-S2, used:   0
      NO LOCK, frequency 0kHz (0.0MHz), position <180.0W>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 2.0, type DVB-S2, used:   0
      NO LOCK, frequency 0kHz (0.0MHz), position <180.0W>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe54:b261>:
      slot 2.1, type DVB-S2, used:   0
      NO LOCK, frequency 0kHz (0.0MHz), position <180.0W>
      strength 0000, snr 0000, ber deaddead, unc deaddead
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0

Alles anzeigen

_NUC_096p6p2_0403a_3tun_SIXX-TOGGO_NcvSoftReboot.txt:

Nach umschalten auf TOGO sind 2 Tuner aktiv und keiner der Beiden geht in den Standby.

_NUC_096p6p2_0403b_3tun_TOGGO_NcvSoftReboot.txt:

Ich habe dann den NCV mit netcvupdate ... -R rebootet und dieses log aufgezeichnet. Auch danach sind 2 Tuner aktiv

_NUC_096p6p2_0403c_3tun_SIXX_NcvPowerOffOn.txt:

Ich habe dann den NCV mit stromlos gemacht und dieses log aufgezeichnet. Auch danach sind 2 Tuner aktiv

Erst nach einem service vdr restart sind sofort wieder 5 im Standby ...

Hier liegen obige syslogs und ncvlogs...

pbrb · 3. April 2021

Zitat von gggggg

brb habe ich das richtig verstanden, dass du auch den Netceiver source hast ? Ev. sieht man da was Alles das Standbytimout zurück setzt

ich habe nur eine all-in-one ReelBox im Betrieb, der Netceiver darin ist 1:1 mit dem Mainboard verkabelt, wacht mit dem VDR auf und geht mit dem VDR auch wieder schlafen...

[gelöst] mcli ERROR: video data stream broken

Jetzt mitmachen!

Teilen