Neue Struktur für NetCeiver Software

SHF · 30. Mai 2023

Mein Vorschlag sollte keine Änderung des Verhaltens verursachen, sondern lediglich die Warnung entfernen.

Die Warnung kommt, weil die Definition von "true" geändert wird.

Man muss lediglich die alten Definitionen entfernen und nicht einfach "drüber" definieren, ist man die Warnungen los. (War bei mir zumindest immer der Fall.)

Es fehlt IMHO also nur ein #undef vor dem erneuten #define.

Und das #ifdef davor ist nur zur Sicherheit, falls sich mal was ändert und es nicht definiert sein sollte.

M-Reimer · 30. Mai 2023

Vielleicht ist das eine gute Gelegenheit das mal als Issue für die Library zu führen. Ich finde die optimale Lösung wäre wenn man die defines durch ein Include von stdbool.h ersetzen könnte. Im Prinzip könnte ich auch mal einen Branch so vorbereiten zum Testen.

Wenn das "bool" nur für logische Operationen genutzt wird, dann ist der Wert von "true" nämlich eigentlich egal. Außerdem müsste man erstmal prüfen ob "!false" nicht auch eine "1" ist. Oft ist das so. Ich erinnere mich da aber noch an gewisse BASIC Dialekte zurück wo "true" tatsächlich mit "-1" belegt war.

M-Reimer · 30. Mai 2023

Mal ein paar Gedanken zu dem "bool"-Thema. Ich hab grad mal ein bisschen durch den Sourcecode gegrept und es scheint als wären das die einzigen drei "bool" die in "libnetceiver" genutzt werden: https://github.com/vdr-project…62888/lib/mld.h#L285-L288

Und: Soweit ich das beurteilen kann werden die im Sourcecode gar nicht belegt. Was ich allerdings jetzt auf die Schnelle nicht beurteilen kann, ist, ob die Struktur "conf" irgendwo im Protokoll binär über's Netz geht. Wenn dem so ist, dann wäre die Abfolge der Bytes kritisch. Wenn nicht, dann könnte man die drei "bool" einfach rauslöschen. In jedem Fall sollte es aber gehen die drei statt mit "bool" mit "int" zu deklarieren. Die Abfolge würde sich dabei nicht ändern und wie gesagt: Im Code werden die drei ohnehin nicht genutzt.

Eigentlich hatte ich gar nicht vor "libmcli" so tief zu analysieren. Idee war eigentlich: Lass mal so viel wie möglich auf dem Stand "never touch a running system".

M-Reimer · 30. Mai 2023

Hacky fix/workaround for an "bool redefined" warning. · vdr-projects/libnetceiver@bb44350

This should be reworked at some time!

github.com

Qualifiziert bestenfalls als "übler Hack" aber libnetceiver kompiliert nach wie vor und die doppelten Definitionen sind so definitiv raus.

Die struct behält so erstmal das gleiche Layout. Die fraglichen Einträge habe ich aber bewusst auch umbenannt damit man merkt ob doch irgendwer darauf zugreift.

netcv2dvbip kompiliert so sicher nicht mehr, aber da hab ich keine Schmerzen damit an den richtigen Stellen einfach "stdbool.h" zu includen.

FALLS die Bytefolge in der struct kritisch sein SOLLTE, dann wäre hier (in mld.h) "stdbool.h" keine Option. Das "bool" aus "stdbool.h" ist ein Byte lang während in mld.h auf "int" definiert wurde (was 4 Byte lang ist).

cinfo · 30. Mai 2023

fein fein -- habe ich mal getestet - jetzt bauen auch die /tools hier auch aus den Root-Verzeichnis

Warning gibts aber immer noch viele

Code

cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o ci_handler.o ci_handler.c
In file included from headers.h:20,
                 from ci_handler.c:9:
interfaces.h:13: warning: "bool" redefined
   13 | #define bool    int
      | 
In file included from /usr/include/unicode/umachine.h:52,
                 from /usr/include/unicode/utypes.h:38,
                 from /usr/include/unicode/ucnv_err.h:88,
                 from /usr/include/unicode/ucnv.h:51,
                 from /usr/include/libxml2/libxml/encoding.h:31,
                 from defs.h:232,
                 from headers.h:12,
                 from ci_handler.c:9:
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h:33: note: this is the location of the previous definition
   33 | #define bool    _Bool
      | 
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o mmi_handler.o mmi_handler.c
In file included from headers.h:20,
                 from mmi_handler.c:12:
interfaces.h:13: warning: "bool" redefined
   13 | #define bool    int
      | 
In file included from /usr/include/unicode/umachine.h:52,
                 from /usr/include/unicode/utypes.h:38,
                 from /usr/include/unicode/ucnv_err.h:88,
                 from /usr/include/unicode/ucnv.h:51,
                 from /usr/include/libxml2/libxml/encoding.h:31,
                 from defs.h:232,
                 from headers.h:12,
                 from mmi_handler.c:12:
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h:33: note: this is the location of the previous definition
   33 | #define bool    _Bool
      | 
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o logging.o logging.c
cc  -shared mld_common.o mld_client.o mld_reporter.o mcast.o recv_tv.o recv_ccpp.o tools.o tca_handler.o tra_handler.o satlists.o interfaces.o api_server.o ciparser.o ci_handler.o mmi_handler.o logging.o -lxml2 -lpthread -lz -lm -Wl,-soname="libnetceiver.so.1" -o libnetceiver.so.1.0.0
ln -sf libnetceiver.so.1.0.0 libnetceiver.so
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/lib“ wird verlassen
make -C tools/ all
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/tools“ wird betreten
cc -c -O2 -DAPI_SOCK -I/usr/include/libxml2 -I../lib/ -DCLIENT -D_REENTRANT -D_GNU_SOURCE -o netcvdiag.o netcvdiag.c
In file included from ../lib/headers.h:20,
                 from netcvdiag.c:6:
../lib/interfaces.h:13: warning: "bool" redefined
   13 | #define bool    int
      | 
In file included from /usr/include/unicode/umachine.h:52,
                 from /usr/include/unicode/utypes.h:38,
                 from /usr/include/unicode/ucnv_err.h:88,
                 from /usr/include/unicode/ucnv.h:51,
                 from /usr/include/libxml2/libxml/encoding.h:31,
                 from ../lib/defs.h:232,
                 from ../lib/headers.h:12,
                 from netcvdiag.c:6:
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h:33: note: this is the location of the previous definition
   33 | #define bool    _Bool
      | 
cc -L../lib -pthread netcvdiag.o -lnetceiver -o netcvdiag
strip netcvdiag
cc -c -O2 -DAPI_SOCK -I/usr/include/libxml2 -I../lib/ -DCLIENT -D_REENTRANT -D_GNU_SOURCE -o netcvupdate.o netcvupdate.c
In file included from ../lib/headers.h:20,
                 from netcvupdate.c:15:
../lib/interfaces.h:13: warning: "bool" redefined
   13 | #define bool    int
      | 
In file included from /usr/include/unicode/umachine.h:52,
                 from /usr/include/unicode/utypes.h:38,
                 from /usr/include/unicode/ucnv_err.h:88,
                 from /usr/include/unicode/ucnv.h:51,
                 from /usr/include/libxml2/libxml/encoding.h:31,
                 from ../lib/defs.h:232,
                 from ../lib/headers.h:12,
                 from netcvupdate.c:15:
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h:33: note: this is the location of the previous definition
   33 | #define bool    _Bool
      | 
cc -L../lib -pthread netcvupdate.o -lnetceiver -o netcvupdate
strip netcvupdate
cc -c -O2 -DAPI_SOCK -I/usr/include/libxml2 -I../lib/ -DCLIENT -D_REENTRANT -D_GNU_SOURCE -o netcvlogview.o netcvlogview.c
In file included from ../lib/headers.h:20,
                 from netcvlogview.c:1:
../lib/interfaces.h:13: warning: "bool" redefined
   13 | #define bool    int
      | 
In file included from /usr/include/unicode/umachine.h:52,
                 from /usr/include/unicode/utypes.h:38,
                 from /usr/include/unicode/ucnv_err.h:88,
                 from /usr/include/unicode/ucnv.h:51,
                 from /usr/include/libxml2/libxml/encoding.h:31,
                 from ../lib/defs.h:232,
                 from ../lib/headers.h:12,
                 from netcvlogview.c:1:
/usr/lib/gcc/x86_64-linux-gnu/11/include/stdbool.h:33: note: this is the location of the previous definition
   33 | #define bool    _Bool
      | 
cc -L../lib -pthread netcvlogview.o -lnetceiver -o netcvlogview
strip netcvlogview
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/tools“ wird verlassen

Alles anzeigen

M-Reimer · 30. Mai 2023

Teste mal den aktuellen Stand. Ja, ich hab leider tatsächlich noch so ein "#define bool" übersehen. In der Version 0.0.5 sollten jetzt aber alle raus sein.

Bis auf die eine Stelle, an der ich nicht sicher bin wegen der "struct" wird aktuell kein "bool" intern genutzt und ich sehe keinen Grund wozu eine "Treiber-Library" so eine Definition mitbringen sollte. Ich fixe dann später noch "netcv2dvbip". Das baut nämlich fest auf diese eingebauten "bool-Typen" und braucht jetzt eine Anpassung.

cinfo · 30. Mai 2023

Code

root@BM2LTS-DD:/usr/src/ENTWICKLUNG_VDR/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver# make
make -C lib/ all
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/lib“ wird betreten
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o mld_common.o mld_common.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o mld_client.o mld_client.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o mld_reporter.o mld_reporter.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o mcast.o mcast.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o recv_tv.o recv_tv.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o recv_ccpp.o recv_ccpp.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o tools.o tools.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o tca_handler.o tca_handler.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o tra_handler.o tra_handler.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o satlists.o satlists.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o interfaces.o interfaces.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o api_server.o api_server.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o ciparser.o ciparser.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o ci_handler.o ci_handler.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o mmi_handler.o mmi_handler.c
cc -c -O2 -fPIC -Wall -DCLIENT -DLIBRARY -D_REENTRANT -D_GNU_SOURCE -DAPI_SOCK -I/usr/include/libxml2 -O3 -o logging.o logging.c
cc  -shared mld_common.o mld_client.o mld_reporter.o mcast.o recv_tv.o recv_ccpp.o tools.o tca_handler.o tra_handler.o satlists.o interfaces.o api_server.o ciparser.o ci_handler.o mmi_handler.o logging.o -lxml2 -lpthread -lz -lm -Wl,-soname="libnetceiver.so.1" -o libnetceiver.so.1.0.0
ln -sf libnetceiver.so.1.0.0 libnetceiver.so
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/lib“ wird verlassen
make -C tools/ all
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/tools“ wird betreten
cc -c -O2 -DAPI_SOCK -I/usr/include/libxml2 -I../lib/ -DCLIENT -D_REENTRANT -D_GNU_SOURCE -o netcvdiag.o netcvdiag.c
cc -L../lib -pthread netcvdiag.o -lnetceiver -o netcvdiag
strip netcvdiag
cc -c -O2 -DAPI_SOCK -I/usr/include/libxml2 -I../lib/ -DCLIENT -D_REENTRANT -D_GNU_SOURCE -o netcvupdate.o netcvupdate.c
cc -L../lib -pthread netcvupdate.o -lnetceiver -o netcvupdate
strip netcvupdate
cc -c -O2 -DAPI_SOCK -I/usr/include/libxml2 -I../lib/ -DCLIENT -D_REENTRANT -D_GNU_SOURCE -o netcvlogview.o netcvlogview.c
cc -L../lib -pthread netcvlogview.o -lnetceiver -o netcvlogview
strip netcvlogview
make[1]: Verzeichnis „/usr/local/src/!VDR/01-Master/01-Master-2.6.4-BM2LTS/PLUGINS/libnetceiver/tools“ wird verlassen

Alles anzeigen

M-Reimer · 30. Mai 2023

An "netcv2dvbip" musste ich nichtmal etwas anpassen. Dort wird ein C++-Compiler genutzt welcher einen "bool"-Datentyp dann schon mitbringt. Neu definiert wird "bool" trotzdem: https://github.com/vdr-project…ip/blob/master/misc.h#L10 Aber an der Stelle frage ich jetzt nicht mehr nach dem Grund. Die "warning" ist mir an der Stelle dann lange gut. Davon abgesehen das es beim Kompilieren des Projekts ohnehin auch andere (gravierendere) Warnungen wirft.

wirbel · 30. Mai 2023

Hmm, 'bool' in C-code zu verwenden ist so eine Art von Vergehen. Warum 'C', wenn man doch eher den Luxus von C++ möchte?

Wenn man das möchte, dann ist der Wechsel auf C++ sinnvoller.

Ansonsten bleibt man bei den fast gleichen Integer Konstrukten, die ebenso gut lesbar sind (-> kein inhaltlicher Nachteil!).

Oder erfordert im Makefile C99 (im Fall von gcc ja eher höher, weil es dort den Sprung auf C11 mit gcc-5.5(?) gab) plus stdbool.h, was alle aktuellen compiler kennen, und denkt daran, dass im Hintergrund _Bool anstelle von bool gemeint ist und 'true' und 'false' ebenso nur #define's sind. Was passiert, wenn ein solches #define true bei einem Compiler (plus pre processor) gar nicht definiert ist??

Code

#if true
   // (foo bar)
#endif

Falls hier 'true' nicht definiert ist, ergibt sich ein ganz kleiner Wechsel des Programm Ablaufes...

Aus so einem Konstrukt Daten mit einem selbstdefinierten "bool" zu einem Zweitrechner zu senden/empfangen macht dann die Sache um so schlimmer.

Aber das kennen wir doch alltäglich von unendlichen Zeichenkodierungen. UTF-8 vs ISO8859.....

SHF · 31. Mai 2023

Ich habe gestern zu kompliziert gedacht, (!0) muss einen festen Integerwert ergeben, sonst ginge int i=(!0); nicht.

Meine gestrige Vermutung der Autor wollte das Verhalten von if (i) und if (i == true) angleichen, ist falsch. Das kann nie gehen, da true ja nur ein Integerzahlenwert ist.

(!0) ist 1. Das sagt schon mein ganz altes C-Buch, das sollte also eigentlich mit jedem Compiler gehen.

D.h. die Definition ist mit der in der stdbool.h faktisch identisch, man kann also einfach auf stdbool.h umstellen.

Wirklich geschickt ist die Definition !false aber nicht, das ist zumindest unnötig verwirrend. Und nachher hat man dann doch auf irgend einem exotischen System Ärger ...

... was aber auch für das #ifdef true und #ifdef false gilt.

Es funktioniert bei mir wie es soll. Aber wenn man es mit einem Tag Abstand sieht, sieht es echt schräg aus.

gggggg · 14. März 2024

Leider funktionieren die Netceiver Tools im Zusammenhang mit lftp nicht mehr.

Könnt ihr Wissenden bitte mal einen Blick drauf werfen...

Ich vermute dass entweder Änderungen am default Verhalten von lftp oder Ubuntu oder der Umbau an mcli, zur "Disfunktion" der Netceivertools geführt haben.

Beitrag

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

@cinfo @M-Reimer:
"ftp Download vom NCV defekt" - Zusammenfassung des aktuellen Probs bez. der Netceiver tools & mcli

Hier hat @pbrb die Fehler erstmals behoben:
vdr-portal.de/forum/index.php?…ostID=1348090#post1348090
Bis zur mcli0.97(ev. auch 1.0) hat Alles wunderbar funktioniert.
Ich vermute dass entweder Änderungen am default Verhalten von lftp oder Ubuntu oder der Umbau an mcli, zur "Disfunktion" der Netceivertools geführt haben.
vdr-portal.de/forum/index.php?thread/135644/
Im BM2LTS…

gggggg

13. März 2024

cinfo · 15. März 2024

Zitat von gggggg

Leider funktionieren die Netceiver Tools im Zusammenhang mit lftp nicht mehr.
Könnt ihr Wissenden bitte mal einen Blick drauf werfen...
Ich vermute dass entweder Änderungen am default Verhalten von lftp oder Ubuntu oder der Umbau an mcli, zur "Disfunktion" der Netceivertools geführt haben.

Beitrag

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

@cinfo @M-Reimer:
"ftp Download vom NCV defekt" - Zusammenfassung des aktuellen Probs bez. der Netceiver tools & mcli

Hier hat @pbrb die Fehler erstmals behoben:
vdr-portal.de/forum/index.php?…ostID=1348090#post1348090
Bis zur mcli0.97(ev. auch 1.0) hat Alles wunderbar funktioniert.
Ich vermute dass entweder Änderungen am default Verhalten von lftp oder Ubuntu oder der Umbau an mcli, zur "Disfunktion" der Netceivertools geführt haben.
vdr-portal.de/forum/index.php?thread/135644/
Im BM2LTS…

gggggg

13. März 2024

das war der letzte Stand

Code

Verwendung der NetCeiver-Tools
Peter Bieringer hat diese Seite bearbeitetam 21. Juni 2023 · 4 Überarbeitungen
NetCeiver-Informationen zum Client
Anforderungen:

Bekannte und IPv6-fähige Schnittstelle, mit der der NetCeiver auf Layer 2 (Link-Local) verbunden ist.
Listen Sie alle NetCeiver unter dem Link auf
erfordert:

Ausführen von vdr mit mcli-Plugin und Zugriff auf Socket /var/tmp/mcli.sock
/usr/bin/netcvupdate -l
fe80::208:54ff:fe**:****    AVR0038/FPGAC94
NetCeiver-Informationen über IPv6-Multicast
Zeigt Informationen an, die per IPv6-Multicast von NetCeiver empfangen wurden
/usr/bin/netcvlogview enp4s0 
mode:1 port:23000 mcg:1 [ ff18:5100:: ]
slot 0/1 | count   6 | freq  586006739 | status 1f |    ff18:3001:0:fff:86c4:8005:4ac0:8000 | signal eded | snr e9e9 | ber 000001e7 | unc 0000066c | LOCK
slot 2/1 | count  12 | freq  314006739 | status 1f |    ff18:3001:0:fff:86c4:8005:4cc0:4000 | signal f9f9 | snr f8f8 | ber 00000000 | unc 00000000 | LOCK
slot 4/1 | count   1 | freq  618000000 | status 00 |    ff18:3001:0:fff:86c4:8005:86c0:8000 | signal f6f6 | snr cfcf | ber 000fffff | unc 0000040f | 
MLD MCGs: 26 Subscribers: 26
00.CAM status: MISSING 
01.CAM status: MISSING 
...
(wird fortgesetzt bis STRG-BREAK)

NetCeiver-Informationen über mcli-Plugin
Abrufen von NetCeiver-Informationen über das mcli-Plugin (Socket: /var/tmp/mcli.sock)

/usr/bin/netcvdiag -a
Count: 1
NetCeiver 0:
  UUID <fe80::208:54ff:fe**:****>, ALIVE, tuners 3
  OS <2.4.32-uc0>, App <0.99.34>, FW <AVR0038/FPGAC94>, HW <0055>
  Serial <33d900000*****>, Vendor <BayCom GmbH>, state 0
  SystemUptime 11052, ProcessUptime 11040
  TunerTimeout 3600
  CI-Slot 0: State <MISSING>, Mode <CA_SINGLE>, CAPMT-Flag: 0, SIDs 0/1, CAM <>
  CI-Slot 1: State <MISSING>, Mode <CA_MULTI_TRANSPONDER>, CAPMT-Flag: 0, SIDs 0/4, CAM <>
  Tuner 0: <Philips TDA10023 DVB-C>,  SatList: <>, Preference 0
  Tuner 1: <Philips TDA10023 DVB-C>,  SatList: <>, Preference 0
  Tuner 2: <Philips TDA10023 DVB-C>,  SatList: <>, Preference 0


UUID <fe80::208:54ff:fe**:****>:
      slot 0.0, type DVB-C, used:   6
      LOCK   , frequency 458000000Hz (458006.7kHz)
      strength f3f3, snr f7f7, ber 0000, unc 0000
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe**:****>:
      slot 1.0, type DVB-C, used:  12
      LOCK   , frequency 314000000Hz (314006.7kHz)
      strength f9f9, snr f8f8, ber 0000, unc 0000
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
UUID <fe80::208:54ff:fe**:****>:
      slot 2.0, type DVB-C, used:   6
      LOCK   , frequency 450000000Hz (450006.7kHz)
      strength f3f3, snr f7f7, ber 0000, unc 0000
      NIMCurrent 0
      RotorStatus 0, RotorDiff 0.0
NetCeiver-Konfigurationsverwaltung/-steuerung
Erfordert:

Link-lokale IPv6-Adresse von NetCeiver
bekannte Schnittstelle, mit der der NetCeiver verbunden ist (bei mehreren Schnittstellen auf dem Client)
geht davon aus, dass der installierte FTP-Client ftpumbenannt oder mit einem Hard- oder Softlink versehen wirdtnftp
Optional:

lftpClient installiert, ausgewählt nach Option -nim Beispiel unten
Download der NetCeiver-Konfiguration
mit 'tnftp'
/usr/bin/netcvupdate -d eth1 -i fe80::208:54ff:fe**:**** -D
INFO  : found in PATH FTP client 'tnftp'
UUID fe80::208:54ff:fe**:****: Downloading netceiver.conf ... 
Download done
mit 'lftp'
/usr/bin/netcvupdate -n -d eth1 -i fe80::208:54ff:fe**:**** -D
INFO  : enable options for FTP client 'lftp'
UUID fe80::208:54ff:fe**:****: Downloading netceiver.conf ... 
...
Download done
Hochladen der NetCeiver-Konfiguration
mit 'tnftp'
/usr/bin/netcvupdate -d eth1 -i fe80::208:54ff:fe**:**** -U netceiver.conf
INFO  : found in PATH FTP client 'tnftp'
UUID fe80::208:54ff:fe**:****: Uploading netceiver.conf ... 
Upload done
mit 'lftp'
/usr/bin/netcvupdate -n -d eth1 -i fe80::208:54ff:fe**:**** -U netceiver.conf
INFO  : enable options for FTP client 'lftp'
UUID fe80::208:54ff:fe**:****: Uploading netceiver.conf ... 
...
Upload done
NetCeiver-Neustart
Erfordert:

tnftpEingerichtet
Version > 21.06.2023 (älter/ lftphat ein Problem: https://github.com/vdr-projects/libnetceiver/issues/1 )
/usr/bin/netcvupdate -d eth1 -i fe80::208:54ff:fe**:**** -R
INFO  : found in PATH FTP client 'tnftp'
UUID fe80::208:54ff:fe**:****: Issue Reboot... Reboot done

Alles anzeigen

M-Reimer · 15. März 2024

Was "lftp" hier bemängelt ist ja eigentlich recht klar kommuniziert. Scheinbar ist es möglich lftp ohne IPv6 zu kompilieren, was hier auch getan wurde. Auf jeden Fall ist IPv6 bis in den FTP Client zwingend erforderlich. Der NetCeiver hat ausschließlich eine IPv6-Adresse.

Es gab auch weitere Probleme mit lftp weshalb mehr oder weniger der empfohlene Client letztlich wieder tnftp war. Der muss aber auch zwingend so konfiguriert sein das er IPv6 unterstützt. Ich hatte das bei Arch vor vielen Jahren mal als Bug gemeldet, was ignoriert wurde. Aus diesem Grund gibt es für Arch https://aur.archlinux.org/packages/tnftp6

Viel weiter werde ich aber nicht helfen können. Ich hatte nochmal Zeit in das Netceiver-Thema gesteckt weil ein guter Freund von mir einen voll ausgestatteten NetCeiver gekauft hat und wir den irgendwie sauber nutzbar machen wollten. Das hat auch halbwegs funktioniert aber dann ist der NetCeiver plötzlich komplett ausgefallen. Auch die LEDs geben keine Auskunft. Das Ding ist einfach mausetot ohne feststellbare Ursache. Nachdem jetzt schon so viel Zeit in das Thema geflossen ist, war mein Vorschlag er soll sich bei Kleinanzeigen oder so nach einer neuen Hauptplatine umschauen in die man die 3 Doppeltuner stecken könnte. Ob er den Weg geht weiß ich nicht. Eventuell wäre es hier auch an der Zeit auf etwas "modernes" zu wechseln.

gggggg · 15. März 2024

Danke. Es gibt sicher noch NCVs zu kaufen. Ich könnte ev. Kontakt herstellen. Was am NCV f. mich einfach 1a ist, ist die Multitransponerunterstüzung, womit man so wie wir ÖSIs einfach die ORF KArte in ein CAM in den NCV steckt und alle Clients die Streams dekodiert bekommen.

Zurück zum lftp. D.h. cinfo muss "nur" den IPV6 support beim builden berücksichtigen ?

cinfo · 15. März 2024

Zurück zum lftp. D.h. cinfo muss "nur" den IPV6 support beim builden berücksichtigen ?

Wie macht man das?

gggggg · 26. März 2024

M-Reimer

- was müsste bitte geändert werden um bei LFTP IPv6 support zu bekommen

- Weshalb trägt mcli 9 devices ein. im mcli.conf sind 3 eingetregen und der Netceiver hat insg. 6

setup.conf: PrimaryDVB = 9

Code

Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::PreInitMcli: found specified device 'eth0.2' in /proc/net/if_inet6 (after 5 sec)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 1 (card index 1)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] cTimeMs: using monotonic clock (resolution is 1 ns)
Mar 26 09:49:34 BM2LTS-MC vdr: [1507] device 1 section handler thread started (pid=1422, tid=1507, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 2 (card index 2)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1508] device 2 section handler thread started (pid=1422, tid=1508, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 3 (card index 3)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1509] device 3 section handler thread started (pid=1422, tid=1509, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 4 (card index 4)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1510] device 4 section handler thread started (pid=1422, tid=1510, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 5 (card index 5)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1511] device 5 section handler thread started (pid=1422, tid=1511, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 6 (card index 6)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1512] device 6 section handler thread started (pid=1422, tid=1512, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 7 (card index 7)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1513] device 7 section handler thread started (pid=1422, tid=1513, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 8 (card index 8)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::cMcliDevice: USING VDR PACKET BUFFER 
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] mcli::Initialize: successful
Mar 26 09:49:34 BM2LTS-MC vdr: [1514] device 8 section handler thread started (pid=1422, tid=1514, prio=low)
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] initializing plugin: softhddrm (3.22-BM2LTS): A software and GPU emulated UHD/HLG HDR device
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] new device number 9 (card index 9)
...
Mar 26 09:49:34 BM2LTS-MC vdr: [1422] setting primary device to 9

Alles anzeigen

M-Reimer · 26. März 2024

Ich hatte den NetCeiver bei einem guten Kumpel, der 30 km entfernt wohnt, in Betrieb gehabt. Ich hab den mit Hilfe hier aus dem Board irgendwie zum Laufen gebracht. Zunächst mit minisatip und dann mit gleichen Einstellungen mit dem mcli Plugin. Meine Möglichkeiten, noch etwas nachzuvollziehen, tendieren aber gegen Null. Wie schon erwähnt habe ich keinen funktionsfähigen NetCeiver mehr. Ich selber habe und hatte nie Interesse am NetCeiver. Das war eine Idee des Vaters meines Kumpels, welcher den NetCeiver entgegen meinen Rat dann "spontan" bestellt hatte. Bei den Preisen "guter" Sat>IP Server glaube ich am ehesten das da jetzt wieder PC-Hardware mit eingebauten Tunern hinkommt. Oder ein ARM mit PCI-Express um bestehende Tuner stecken zu können.

Ich glaube "lftp" wurde ursprünglich eingebaut um einen "gängigeren" FTP Client zu nutzen. Allerdings gab es dann zumindest in einem Fall ein Problem das mit lftp nicht lösbar ist: https://github.com/vdr-projects/libnetceiver/issues/1

Schon aus diesen Grund würde ich empfehlen nicht lftp sondern tnftp zu nutzen und wie der mit IPv6 konfiguriert wird steht hier: https://aur.archlinux.org/cgit…it/tree/PKGBUILD?h=tnftp6

cinfo · 26. März 2024

ich habe s mal für das nächste Image neu gebaut mit IPv6

Code

configure:  === Configuration results ===
configure: Package:               tnftpd 
configure: Prefix:                /usr
configure: CC                     gcc
configure: CFLAGS                 -g -O2
configure: CPPFLAGS               
configure: LDFLAGS                
configure: LIBS                   -lresolv -lcrypt 
configure: YACC                   bison -y
configure: YFLAGS                 
configure: --enable-builtinls     yes
configure: --enable-ipv6          yes
configure: --with-blocklist       no
configure: --with-pam             no
configure: --with-sia             no
configure: --with-skey            no
configure:  =============================

Alles anzeigen

gggggg · 27. März 2024

mcli:

Danke M-Reimer .

Nochmal zu den 9 registrierten mcli devices und dazu dass das Primary-DVB device nun lt. setup.conf wieder mal=9 ist.

Damals schrieb pbrb

Da hat sich was im Plugin-Start geändert, so daß sich mcli nicht vordrängelt...was zu anderen Übelkeiten führen konnte...besser ist es, wenn softdevice als primary device ganz vorne steht.

Hast du denn daran was geändert ? Weil das PrimaryDVB ist beim alten mcli 0.97 (ohne der netceiverlib) immer =1 gewesen.

ftp: Hab hier mal kurz die Historie zusammengefasst

Wir hatten ja den lftp eingebaut, weil der ftp die -q (timeout) Option nicht mehr unterstütz hatte. Siehe hier.

Ab dem Zeitpunkt nutzen wir den lftp mit dem switch switch --netcvupdate-use-lftp im mcli.conf

Dann hatte M-Reimer 2023 ein Prob bei lftp bez. der -R Option gemeldet und @Pbiering kommentiert:

site exec reboot -d 5 has to be pushed to background by the FTP server as otherwise blocking the client. Strangewise lftp is not proper supporting "&" (it throws itself - the client - somehow in the background), but found that tnftp client is working well.

Aktuell ist es so dass als default client tftp genutzt wird. ACHTUNG ob beim ftp die -q(timout) Option wieder funkt wissen wir nicht !

Unten der Codeauszug von ncvupdate der 2021 wegen dem nicht mehr funktionierenden -q beim ftp zum Einbau des lftp geführt hat

Code

    if (strlen(tmpdir)) {
//        snprintf(cmd, sizeof(cmd),"cd %s; %s -q %i -n %s",tmpdir,ftp_cmd,timeout,verbose?"":"-V");
        if (ftp_client_lftp == 1) {
            snprintf(cmd, sizeof(cmd),"cd %s; %s --norc %s %s",tmpdir,ftp_cmd, (verbose == 0) ? "" : "-d", pipeout);
        } else {
            snprintf(cmd, sizeof(cmd),"cd %s; %s -n %s %s",tmpdir,ftp_cmd, (verbose == 0) ? "" : "-V", pipeout);
        };
    } else {
        if (ftp_client_lftp == 1) {
            snprintf(cmd, sizeof(cmd),"%s --norc %s %s",ftp_cmd,(verbose == 0) ? "" : "-d", pipeout);
        } else {
            snprintf(cmd, sizeof(cmd),"%s -q %i -n %s %s",ftp_cmd,timeout, (verbose == 0) ? "" : "-V", pipeout);
        };
    };

Alles anzeigen

Der lftp funkt ja aktuell wegen dem IPv6 Thema aber möglicherweise auch beim -R nicht mehr.

cinfo. Weil du oben Folgendes gepostet hast !

configure: === Configuration results ===configure: Package: tnftpd

Der tftp funkt ja bez. IPv6. Wir brauchen es aber beim Build des lftp.

Hier hab ich bez lftp u IPv6 was gefunden.

Ev. ist das der Build switch: #if INET6 && defined(HAVE_IFADDRS_H)

oder ist das gesetzt --disable-ipv6

und das nicht --enable-ipv6 + IPv6 support

cinfo · 27. März 2024

wir nutzen die aktuelle Version von Lftp, diese unterstützt auch IPv6

lftp Version (4.9.2-1build1)

Lftp ist ein Werkzeug für das Abrufen von Dateien. Es unterstützt die Protokolle FTP, HTTP, FISH, SFTP, HTTPS, FTPS sowohl unter IPv4 als auch unter IPv6.

Neue Struktur für NetCeiver Software

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema