Handling von FBC-Tunern

[Don de Deckelwech]

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.

[nofx]

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

[Janus]

interessant ist ja, dass das Geheimnis die 8 Demuxer sind

Das ist wohl eins der Probleme von Neutrino.
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...

[Gorcon]

Kann man wohl ganz grob mit DHCP bei IPs vergleichen. Bei jedem Neustart neues Glück obs klappt.

[Janus]

ganz grob mit DHCP bei IPs vergleichen. Bei jedem Neustart neues Glück obs klappt

Mit der Fritzbox kann ich auch bei DHCP die IP an die Mac-Adresse binden. ("Diese IP immer vergeben")
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]

Ich zitiere mich mal selbst:

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.

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.
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]

Ist irgendwie seltsam, dass das anscheinend bei mir (Debian/Buster als VM unter Win10) auftritt, Euer Nightly aber anscheinend problemlos durchbaut.

ich nutze xubuntu .. bootet vom usbstick .. und bau ohne probleme u. ohne windows bzw. einer vm
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]

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]

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...

[Janus]

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:

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 ]  =================================================================

Die anschließende Warnung mit den 'nur' 1024 offenen Dateien ist hoffentlich keine Ursache für spätere Fehlfunktionen ??!??

[max_10]

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.

[Janus]

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...

[Janus]

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...

[jokel]

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

[Janus]

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)