Handling von FBC-Tunern
- Don de Deckelwech
- NI - Team
- Beiträge: 1619
- Registriert: Di 12. Apr 2016, 17:13
- Wohnort: Wuppertal
- Box: Tank / HD51 / Protek 4K für Kabel
- Has thanked: 5 times
- Been thanked: 21 times
- Kontaktdaten:
Re: Handling von FBC-Tunern
Hi,
ich lese interessiert mit und wünsche euch viel Erfolg. Vermutlich ist es wieder nur so eine Kleinigkeit, wer weiss.
Eine kurze Googlesuche zum Thema FBC-Tuner hat mich auf 2 Grundlagenartikel gebracht:
https://satellitenempfang.info/fbc-tuner.html
https://wiki.vuplus-support.org/index.p ... Twin-Tuner (kA, wer da von wem abgeschrieben hat! )
Das wisst ihr natürlich. Aber interessant ist ja, dass das Geheimnis die 8 Demuxer sind, und keine 8 (quasi)Tuner. Die Tuner tunen jeweils nur eine Satebene, die Demuxer "empfangen" dann den jeweiligen Transponder. Aber können diese Demuxer dann auch nen anderen Transport-Stream auf demselben Transponder demuxen??? Das ist die grosse Frage.
Also wäre ein genauerer Blick in demux.c wohl angebracht. Vllt lauern da im Neutrino-code noch Altlasten, die auf veralteten Annahmen fussen, wo von FBC noch keine Rede war.
Nuff said.
Ciao,
DdD.
ich lese interessiert mit und wünsche euch viel Erfolg. Vermutlich ist es wieder nur so eine Kleinigkeit, wer weiss.
Eine kurze Googlesuche zum Thema FBC-Tuner hat mich auf 2 Grundlagenartikel gebracht:
https://satellitenempfang.info/fbc-tuner.html
https://wiki.vuplus-support.org/index.p ... Twin-Tuner (kA, wer da von wem abgeschrieben hat! )
Das wisst ihr natürlich. Aber interessant ist ja, dass das Geheimnis die 8 Demuxer sind, und keine 8 (quasi)Tuner. Die Tuner tunen jeweils nur eine Satebene, die Demuxer "empfangen" dann den jeweiligen Transponder. Aber können diese Demuxer dann auch nen anderen Transport-Stream auf demselben Transponder demuxen??? Das ist die grosse Frage.
Also wäre ein genauerer Blick in demux.c wohl angebracht. Vllt lauern da im Neutrino-code noch Altlasten, die auf veralteten Annahmen fussen, wo von FBC noch keine Rede war.
Nuff said.
Ciao,
DdD.
"Ein Log, ist besser als kein Log!"
Re: Handling von FBC-Tunern
Hallo zusammen, schöne das hier bewegung drin ist, leider kann ich hier nicht unterstützen, das einzige was ich machen kann ist testen wenn es was zu testen geben sollte ,
Kann mir jederzeit eine vu wieder beschaffen, war schon eine sehr schöne box - jedoch muss ich immer wieder sagen ich bin so froh das meine tank dank des supports von Knicko wieder läuft und läuft und läuft
Kann mir jederzeit eine vu wieder beschaffen, war schon eine sehr schöne box - jedoch muss ich immer wieder sagen ich bin so froh das meine tank dank des supports von Knicko wieder läuft und läuft und läuft
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Das ist wohl eins der Probleme von Neutrino.interessant ist ja, dass das Geheimnis die 8 Demuxer sind
Die verfügbaren "Subtuner" - so nenne ich sie gerne - werden mit Status und entsprechender notwendiger Empfangskonfiguration in einer verknüpften dynamischen Liste verwaltet. Das umfasst bei den FBC-Tunern auch die Zuweisung jeweils eines verfügbaren Demuxers. Das erfordert auch für die Demuxer eine sichere Mitführung des jeweiligen Demux-Status in einer entsprechenden dynamischen Liste.
Soll heißen, dass bei einem Programmwechsel oder weiterem Programm nach einem freien Subtuner auch ein freier Demuxer zugewiesen werden muss.
Ich denke, dass in Neutrino aktuell nur eine statische Zuweisung beim Start erfolgt...
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Mit der Fritzbox kann ich auch bei DHCP die IP an die Mac-Adresse binden. ("Diese IP immer vergeben")ganz grob mit DHCP bei IPs vergleichen. Bei jedem Neustart neues Glück obs klappt
Funktioniert einwandfrei. Bleibt selbst dann konstant, wenn ich DHCP ausschalte.
Das ware allerdings bei FBC kontraproduktiv. Da sollte auch beim Neustart wieder der Anwendungsfall entscheiden, welcher Demux verwendet werden kann/soll/darf...
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Ich zitiere mich mal selbst:
Der oben angesprochene Fehler (mit entsprechenden Folgefehlern) liegt an der Filestruktur im Source-Verzeichnis und durch den 'mehrschichtigen' Zugriff auf ni-libstb-hal aus ni-neutrino heraus. Irgendwo in den zwischengeschobenen "Umschalt-Dateien" verliert der Compiler die Übersicht über die Verzeichnisstruktur. Die #include-Anweisungen sind anscheinend nicht zielführend. sodaß die in diesen Dateien erforderlichen Header nicht gefunden werden.
Ist irgendwie seltsam, dass das anscheinend bei mir (Debian/Buster als VM unter Win10) auftritt, Euer Nightly aber anscheinend problemlos durchbaut. Ich habe mal angefangen, die #include-Anweisungen mit den entsprechenden Pfandangaben zu 'erweitern'. Das klappt dannn auch bis zur nächsten Verwirrung.
So habe ich dann 5, 6 Stellen geflickt bis ich an einer Stelle eigentlich zwei Pfadteile in einer Anweisung gebraucht hätte. Da habe ich dann die VM abgeschaltet.
Vielleicht hat Jemand eine Idee wo der Fehler in meiner Hardware-Umgebung steckt oder wie man die Pfade zu den Headerdateien pflegeleicht zentraler verwalten kann ?!?
Es scheint doch nicht an mir zu liegen. Im Rahmen der "Werkbank"-Einrichtung bin ich von einem aktuellen GIT-Stand von Heute ausgegangen und habe mir eben für die Duo4K aus dem Master-Branch mit dem neu gebauten Crosstool ein Basis-Ausgangsimage bauen wollen.Wie erwartet, steigt der wieder bei dem Zugriff auf dmx-Sourcen aus LibSTB-HAL aus. (Datei nicht gefunden)
Da ich den Fehler in Verkennung der Komplexität wahrscheinlich selbst eingebaut habe, scheint mir der oben beschriebene Weg - von Grund auf damit "neu" anzufangen - noch mehr Sinn zu machen.
Der oben angesprochene Fehler (mit entsprechenden Folgefehlern) liegt an der Filestruktur im Source-Verzeichnis und durch den 'mehrschichtigen' Zugriff auf ni-libstb-hal aus ni-neutrino heraus. Irgendwo in den zwischengeschobenen "Umschalt-Dateien" verliert der Compiler die Übersicht über die Verzeichnisstruktur. Die #include-Anweisungen sind anscheinend nicht zielführend. sodaß die in diesen Dateien erforderlichen Header nicht gefunden werden.
Ist irgendwie seltsam, dass das anscheinend bei mir (Debian/Buster als VM unter Win10) auftritt, Euer Nightly aber anscheinend problemlos durchbaut. Ich habe mal angefangen, die #include-Anweisungen mit den entsprechenden Pfandangaben zu 'erweitern'. Das klappt dannn auch bis zur nächsten Verwirrung.
So habe ich dann 5, 6 Stellen geflickt bis ich an einer Stelle eigentlich zwei Pfadteile in einer Anweisung gebraucht hätte. Da habe ich dann die VM abgeschaltet.
Vielleicht hat Jemand eine Idee wo der Fehler in meiner Hardware-Umgebung steckt oder wie man die Pfade zu den Headerdateien pflegeleicht zentraler verwalten kann ?!?
- jokel
- Beiträge: 2517
- Registriert: Mi 31. Mär 2021, 14:23
- Box: ZGEMMA H7/C
- Has thanked: 22 times
- Been thanked: 28 times
Re: Handling von FBC-Tunern
ich nutze xubuntu .. bootet vom usbstick .. und bau ohne probleme u. ohne windows bzw. einer vmIst irgendwie seltsam, dass das anscheinend bei mir (Debian/Buster als VM unter Win10) auftritt, Euer Nightly aber anscheinend problemlos durchbaut.
hatte nur einmal probleme .. beim image bau .. image wurde gebaut, aber lies sich nicht booten
das wiederum bei eine zgemma h7 ohne not-start nicht so schön ist.
vanhofen .. werden eure images mittels vm gebaut?
- vanhofen
- Administrator
- Beiträge: 2968
- Registriert: Di 5. Apr 2016, 00:05
- Has thanked: 15 times
- Been thanked: 33 times
Re: Handling von FBC-Tunern
Die werden auf dem gleichen Server gebaut, auf dem auch der Webserver läuft. Dort läuft ein etwas angegammeltes Debian 9. Ob das beim Hoster eine VM ist, weiß ich nicht. Lokal baue ich in einer VM (Debian 10) unter Windows.
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Ich denke, ich habe den "Fehler" gefunden.
Nachdem ich Buster in der VM eben aktualisiert hatte, habe ich nochmal meine boxorientierte Verzeichnistruktur nach 'Art des Hauses' kontrolliert.
Da beim Build der Images die Versionsnummern unvollständig waren, hatte ich vor einiger Zeit versucht, mit einem "Rückwärtslink" -> 'bs' auf ni/bs/ in dem boxorientierten Verzeichnis diesen Mangel zu beseitigen. Hat nicht geklappt, aber den Link habe ich nicht entfernt.
Daher gab es zwei Wege zum Source. Einmal über den normalen Link 'source' nach ../bs/source/ und dann über den o.g. Hilfslink 'bs' nach ni/bs/source. Ich fürchte, dadurch ist die "Verwirrung" entstanden. Hab' den bs-Link gelöscht.
"master" hat jedenfalls anschließend durchgebaut...
Nachdem ich Buster in der VM eben aktualisiert hatte, habe ich nochmal meine boxorientierte Verzeichnistruktur nach 'Art des Hauses' kontrolliert.
Da beim Build der Images die Versionsnummern unvollständig waren, hatte ich vor einiger Zeit versucht, mit einem "Rückwärtslink" -> 'bs' auf ni/bs/ in dem boxorientierten Verzeichnis diesen Mangel zu beseitigen. Hat nicht geklappt, aber den Link habe ich nicht entfernt.
Daher gab es zwei Wege zum Source. Einmal über den normalen Link 'source' nach ../bs/source/ und dann über den o.g. Hilfslink 'bs' nach ni/bs/source. Ich fürchte, dadurch ist die "Verwirrung" entstanden. Hab' den bs-Link gelöscht.
"master" hat jedenfalls anschließend durchgebaut...
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Ich werd' zum Elch !
Am nächsten Tag ging weder 'master' noch 'devel' an der Klippe vorbei.
Also habe ich nochmal Alles kontrolliert, was ich an Konfiguration 'gebastelt' habe.
Dann wollte ich nach einem make all-clean komplett neu bauen.
Jetzt gibt es beim Crosstool gleich zu Beginn eine Abfrage in Bezug auf die Kernel-Header:
Die anschließende Warnung mit den 'nur' 1024 offenen Dateien ist hoffentlich keine Ursache für spätere Fehlfunktionen ??!??
Am nächsten Tag ging weder 'master' noch 'devel' an der Klippe vorbei.
Also habe ich nochmal Alles kontrolliert, was ich an Konfiguration 'gebastelt' habe.
Dann wollte ich nach einem make all-clean komplett neu bauen.
Jetzt gibt es beim Crosstool gleich zu Beginn eine Abfrage in Bezug auf die Kernel-Header:
Code: Alles auswählen
Version of linux
> 1. 5.2.17 (LINUX_V_5_2)
2. 5.1.21 (LINUX_V_5_1)
3. 5.0.19 (LINUX_V_5_0)
4. 4.20.17 (LINUX_V_4_20)
5. 4.19.282 (LINUX_V_4_19)
6. 4.18.20 (LINUX_V_4_18)
7. 4.17.19 (LINUX_V_4_17)
8. 4.16.18 (LINUX_V_4_16)
9. 4.15.18 (LINUX_V_4_15)
10. 4.14.314 (LINUX_V_4_14)
11. 4.13.16 (LINUX_V_4_13)
12. 4.12.14 (LINUX_V_4_12)
13. 4.11.12 (LINUX_V_4_11)
14. 4.10.17 (LINUX_V_4_10)
15. 4.9.335 (LINUX_V_4_9)
16. 4.4.302 (LINUX_V_4_4)
17. 4.1.49 (LINUX_V_4_1)
18. 3.16.85 (LINUX_V_3_16)
19. 3.13.11 (LINUX_V_3_13)
20. 3.12.74 (LINUX_V_3_12)
21. 3.10.108 (LINUX_V_3_10)
22. 3.4.113 (LINUX_V_3_4)
23. 3.2.101 (LINUX_V_3_2)
choice[1-23?]: 1
* Linux >=5.3 requires rsync
*
Kernel verbosity:
> 1. Simplified (KERNEL_LINUX_VERBOSITY_0)
2. Full commands (KERNEL_LINUX_VERBOSITY_1)
3. Exec reasons (KERNEL_LINUX_VERBOSITY_2)
choice[1-3?]: 1
Check installed headers (KERNEL_LINUX_INSTALL_CHECK) [Y/n/?] (NEW) y <===== meine Eingabe !!
*
* Common kernel options
*
Build shared libraries (SHARED_LIBS) [Y/n/?] y
[INFO ] Performing some trivial sanity checks
[WARN ] Number of open files 1024 may not be sufficient to build the toolchain; increasing to 2048
[INFO ] Build started 20230510.123244
[INFO ] Building environment variables
[INFO ] =================================================================
- max_10
- NI - VIP
- Beiträge: 163
- Registriert: Di 12. Apr 2016, 13:06
- Has thanked: 1 time
- Been thanked: 1 time
Re: Handling von FBC-Tunern
Dein BS scheint nicht auf dem aktuellen stand zu sein.
laut config für crosstool, wäre kernel 1 6.3 und nicht 5.17, daher stimmt da was local nicht bei dir.
siehe NI git
https://github.com/neutrino-images/ni-b ... onfig#L304
Number of open files 1024, kannst du vernachlässigen ist eine Warnmeldung und hat keine Spätfolgen, kann man aber im eigen Linux system anpassen, einfach mal googel befragen.
laut config für crosstool, wäre kernel 1 6.3 und nicht 5.17, daher stimmt da was local nicht bei dir.
siehe NI git
https://github.com/neutrino-images/ni-b ... onfig#L304
Number of open files 1024, kannst du vernachlässigen ist eine Warnmeldung und hat keine Spätfolgen, kann man aber im eigen Linux system anpassen, einfach mal googel befragen.
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Danke für die Info!
Habe Gestern vorher noch das BS und Neutrino aktualisiert. Letzter BS-Commit : crosstool-ng: bump version to 9433647
Danach mit 'make all-clean' inklusive Löschen des cross-Verzeichnisses und Neu-Aufbau nach Anweisungen von "make help" komlett neu gebaut. Die Ausgabe von "Linux >=5.3 requires rsync" hat mich da eher nicht stutzig gemacht, weil es 5.2.17 'übergeht'.
Unabhängig davon hat es Gestern danach Alles durchgebaut.
Sowohl meine "normalen" Branches 'master' und 'mine', wie auch die neuangelegten "Werkbank"-Branches 'devel' und 'm(ine)devel'. Ich scheine also ein Problem schonmal gelöst zu haben. (Im Prinzip habe ich die im Laufe der Zeit entstandenen Branch-Wechselscripte 'vereinheitlicht')
Ich schau mir aber die Sachen mit den Kernelversionen noch genauer an...
Habe Gestern vorher noch das BS und Neutrino aktualisiert. Letzter BS-Commit : crosstool-ng: bump version to 9433647
Danach mit 'make all-clean' inklusive Löschen des cross-Verzeichnisses und Neu-Aufbau nach Anweisungen von "make help" komlett neu gebaut. Die Ausgabe von "Linux >=5.3 requires rsync" hat mich da eher nicht stutzig gemacht, weil es 5.2.17 'übergeht'.
Unabhängig davon hat es Gestern danach Alles durchgebaut.
Sowohl meine "normalen" Branches 'master' und 'mine', wie auch die neuangelegten "Werkbank"-Branches 'devel' und 'm(ine)devel'. Ich scheine also ein Problem schonmal gelöst zu haben. (Im Prinzip habe ich die im Laufe der Zeit entstandenen Branch-Wechselscripte 'vereinheitlicht')
Ich schau mir aber die Sachen mit den Kernelversionen noch genauer an...
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Um auf den ursprünglichen Fall mit den zwei unterschiedlichen Zugriffskonfigurationen zurückzukommen:
Nach einem
echo -n 1 > /proc/stb/frontend/1/fbc_connect
habe ich erstmals von der Motorschüssel ( konfiguriert auf Tuner B ) einen Sender auf den Bildschirm bekommen.
Vorher hatte ich nur Zugriff auf Astra 1 und Hotbird ( Multischalter konfiguriert auf Tuner A ). Die damalige Antwort (rf_switch anpassen) war also im Prinzip richtig.
Mit dem Drehen klappt es zwar noch nicht, das liegt aber eher an der bestehenden Frontend-Konfiguration/ ~Steuerung von Neutrino.
Aber ein erster kleiner Schritt ist gemacht. Mal sehen, wie weit ich noch komme...
Bevor für die Box die eigentliche Arbeit losgeht, müssen ja erstmal die Werkzeuge scharf gemacht werden.
Kurze Frage:
Wo wird die Initialisierung solcher Sachen im Code abgearbeitet ?
Die erste Aufgabe wird sein, die Möglichkeiten als solche festzustellen.
* Kann die Box FBC (bool can_FBC)
* Hat die Box dann auch FBC-Tuner und wenn,
* wieviele (int has_FBC=Anzahl)
* und welche (z.B. TWIN, DVB-Typ etc.)
Da hatte ich schonmal in libstb-hal für mene Duo4K was eingebaut.
Danach Tuner-EIgenschaften festlegen, indizierte Listen anlegen und Verkettung definieren.
Ich werde mich erstmal in "verketteten Listen in C" einlesen...
Nach einem
echo -n 1 > /proc/stb/frontend/1/fbc_connect
habe ich erstmals von der Motorschüssel ( konfiguriert auf Tuner B ) einen Sender auf den Bildschirm bekommen.
Vorher hatte ich nur Zugriff auf Astra 1 und Hotbird ( Multischalter konfiguriert auf Tuner A ). Die damalige Antwort (rf_switch anpassen) war also im Prinzip richtig.
Mit dem Drehen klappt es zwar noch nicht, das liegt aber eher an der bestehenden Frontend-Konfiguration/ ~Steuerung von Neutrino.
Aber ein erster kleiner Schritt ist gemacht. Mal sehen, wie weit ich noch komme...
Bevor für die Box die eigentliche Arbeit losgeht, müssen ja erstmal die Werkzeuge scharf gemacht werden.
Kurze Frage:
Wo wird die Initialisierung solcher Sachen im Code abgearbeitet ?
Die erste Aufgabe wird sein, die Möglichkeiten als solche festzustellen.
* Kann die Box FBC (bool can_FBC)
* Hat die Box dann auch FBC-Tuner und wenn,
* wieviele (int has_FBC=Anzahl)
* und welche (z.B. TWIN, DVB-Typ etc.)
Da hatte ich schonmal in libstb-hal für mene Duo4K was eingebaut.
Danach Tuner-EIgenschaften festlegen, indizierte Listen anlegen und Verkettung definieren.
Ich werde mich erstmal in "verketteten Listen in C" einlesen...
- jokel
- Beiträge: 2517
- Registriert: Mi 31. Mär 2021, 14:23
- Box: ZGEMMA H7/C
- Has thanked: 22 times
- Been thanked: 28 times
Re: Handling von FBC-Tunern
leider habe ich keinen fbc tuner .. aber es ist immer besser einen plan zuhaben ..
als keinen plan zuhaben .. viel glück auf deinem weg .. der weg ist das ziel
als keinen plan zuhaben .. viel glück auf deinem weg .. der weg ist das ziel
- Janus
- NI - VIP
- Beiträge: 1157
- Registriert: Di 12. Apr 2016, 19:41
- Box: HD1, Zee, Neo, Tank, HD51, Duo4K
- Has thanked: 4 times
- Been thanked: 5 times
Re: Handling von FBC-Tunern
Ich fürchte, ich habe zu spät damit angefangen.
Im Master-Branch sind mir zu viele Fehler, die ich hier längst beseitigt habe.
(DiSEqC-Managment, Frontend-/ Scan-Einstellungen im UI)
In meinem eigenen Branch sind zudem viele kleinere Sachen auf meine Bedürfnisse optimiert.
Leider muss ich dazu noch feststellen, dass nicht nur meine C-Kenntnisse stark verbesserungswürdig sind, sondern auch meine Konzentrations- und Merkfähigkeit in letzter Zeit stark abnimmt. Alles eher Nix für komplexe Programmiervorhaben.
Vielleicht findet sich ja doch noch ein Neutrino-Anhänger in weniger fortgeschrittenem Alter und bereits vorhandenen C-Skills.
Ich werde jedenfalls erstmal meine Duo4K wieder auf OpenATV 7.3 flashen und damit weiter ein - auf 7.2 begonnenes - "Neutrino-Feeling für Senioren" basteln. (Meine Tastenbelegungen sind schon ziemlich ähnlich)
Im Master-Branch sind mir zu viele Fehler, die ich hier längst beseitigt habe.
(DiSEqC-Managment, Frontend-/ Scan-Einstellungen im UI)
In meinem eigenen Branch sind zudem viele kleinere Sachen auf meine Bedürfnisse optimiert.
Leider muss ich dazu noch feststellen, dass nicht nur meine C-Kenntnisse stark verbesserungswürdig sind, sondern auch meine Konzentrations- und Merkfähigkeit in letzter Zeit stark abnimmt. Alles eher Nix für komplexe Programmiervorhaben.
Vielleicht findet sich ja doch noch ein Neutrino-Anhänger in weniger fortgeschrittenem Alter und bereits vorhandenen C-Skills.
Ich werde jedenfalls erstmal meine Duo4K wieder auf OpenATV 7.3 flashen und damit weiter ein - auf 7.2 begonnenes - "Neutrino-Feeling für Senioren" basteln. (Meine Tastenbelegungen sind schon ziemlich ähnlich)