Fragen und Anregungen zum Code

[udog]

moin
obwohl ich selbst NI baue ist mir dass garnicht aufgefallen
Die Beule ist wohl mit 2 commit von 'dbt' reingekommen....
die Knöppe rot und grün fehlen

https://github.com/Duckbox-Developers/n ... e35442d3cc

Bei abgeschalteten Menü Hinweisen wurden durch das ResetModules(); bei paintHint(...) immer alle Objekte gekillt / genullt.
Nun sind die footer da....

hier der Patch von DboxOldie (BP) Board

menu-widget-footer.patch.txt

(435 Bytes) 247-mal heruntergeladen

[vanhofen]

Ich habe das mal abgetrennt.

Was die Footer betrifft ... die sind hier vorhanden. Sowohl auf der Box als auch am PC ist soweit alles OK.

Der Commit von dbt gefällt mir aber in anderer Hinsicht auch nicht. Ich hatte nämlich vorher die volle Höhe der Menüs (full_height) inclusive der Footer berechnet. Die hat dbt aber da wieder rausoperiert. Warum er das tat, weiß ich aber nicht.

[vanhofen]

Was die Footer betrifft ... die sind hier vorhanden. Sowohl auf der Box als auch am PC ist soweit alles OK.

Es ist Montag ... Ich merke es deutlich ...
Ich sollte besser lesen. OK, wenn ich die Hintboxes abschalte, sind die Footer auch hier weg.

[DboxOldie]

Ist auch nur aufgefallen, weil die Wohnzimmer Box ohne Menü Hints betrieben wird.
( Regierungswunsch )

[DboxOldie]

Noch eine Sache mit den Commits zu den Menu Widget Footer ist mir aufgefallen....

Mit PLAY den Moviebrowser öffnen > dann ROT zum sortieren:

Dann mit Exit oder igendeiner Sortierung zurückgehen :

Bleibt ein Loch im OSD, der Bereich wo der Footer sitzt wird nicht zurückgemalt.

[vanhofen]

Da triggert meine oben angesprochene Kritik mit full_height. Ich richte das wieder. Danke.

[vanhofen]

Ich komme nicht dazu. Ich schreibe es mal bei DB2W. Vielleicht kümmert sich dbt drum.

[Miky]

Manche Sachen haben aber auch mehr als 12 Stunden Zeit wieder gefixt zu werden. Gut, wenn wirklich was wichtiges kaputt ist sollte man schnell sein, aber sowas hat doch locker Zeit. Also stress Dich doch nicht so

[DboxOldie]

Die footer_height ist in full_height weiterhin enthalten : ( s. calcSize )

Code: Alles auswählen

full_height = height + footer_height + OFFSET_SHADOW/* + OFFSET_INTER*/; // hintbox is handled separately

Mit dem Patch ist das OSD Loch bei mir weg.

menu-widget-footer-osd-hole.patch.txt

(1.54 KiB) 286-mal heruntergeladen

Die Zentrierung passt auch wieder wie vorher.
Mit dem Patch oben ( menu-widget-footer.patch ) funktioniert hier nun alles wie es soll.

PS: Warum ist die Endung .patch nicht erlaubt zum anhängen ?

[vanhofen]

Danke. diff und patch sind nun in Anhängen erlaubt.

[Janus]

Ich hätte da mal 'ne Anregung.

Die Anwenderbeeinflussung der Provider-Bezeichner ist nicht korrekt, was die eindeutige Zuordnung betrifft. Es fehlt - wie in den frühen Neutrino-Bouquets - die Auswertung der Broadcaster-IDs (Sat-Position, Kabel-NetzID).

Das "Werkzeug" /var/tuxbox/config/providermap.xml hilft dabei, die Liste der Providerbouquets klein und übersichtlich zu halten. Insbesondere wenn man in der neutrino.conf einstellt (infobar_show_channeldesc=true), dass die Providerbezeichner hinter dem Service-Namen erscheinen.

Für Besitzer von Multifeed - oder Motoranlagen ein nicht zu unterschätzender Vorteil. Auch wenn man wegen der Pairing-Belästigung einen Dummy-Satelliten (pos=191) für die Modul-Nutzung eingerichtet hat.

Ich habe mal meine aktuelle providermap.xml (Hotbird, Astra 1+, Astra 1, UnityMedia) angehängt.

providermap.xml

(9.82 KiB) 268-mal heruntergeladen

Dazu gehört ein Diff gegen den Source vom 06.09.2017

add_bcid_in_providermap.diff

(6.25 KiB) 278-mal heruntergeladen

Wer's auch nützlich (und richtig) findet, kann es ja - dank NI-Buildsystem - gerne in sein eigenes Image einbauen. Ich verwende einen eigenen Branch 'ni/mine' den ich vor make update-all wechsle und nach dem Update mit 'ni/tuxbox' wieder "rebase".

Wenn sich "richtig" als "allgemein richtig" herausstellt, kann das natürlich - inklusive der Musterdatei - auch ins Repo. Wäre einfacher für GIT-Laien...


p.s.
Vielleicht gibt es eine Option für's BS per config.local nicht nur den Branch für's Update/Kompilieren einzustellen, sondern das zu trennen in
a) Branch zum Update (default) und zusätzlich
b) Branch zum Kompilieren.

git checkout ni/tuxbox und git rebase ni/mine sollte wegen vergessener Commits und Mergefehlern weiterhin manuell bleiben.

Immer wieder
NI_NEUTRINO_BRANCH = ni/mine
vor dem Update auskommetieren und danach wieder reaktivieren zu müssen, wäre damit überflüssig.

[vanhofen]

Das würde ich dir sehr gern einchecken, aber so, wie ich den Code lese, macht es eine existierende providermap.xml beim User unbrauchbar, weil nun der neue BC-Tag außenrum stehen muss. Wenn das so ist, ist der Patch leider unbrauchbar. Wir können nicht die Handarbeit der User kaputt machen.

[Janus]

Jou, so ist es.
Habe selbst nach einer automatischen Upgrade-Möglichkeit gesucht und keine gefunden habe, weil die Einträge im schlimmsten Fall ohne Rückgriff auf die Quelle total durcheinander gehen. Leider ist damals auch mein frühzeitiger 'Einspruch' gegen das fehlerhafte Handling bei CST nicht angenommen worden.

Wobei ich ziemlich überzeugt bin, dass sich die "Handarbeit" für ein zusätzliches Struktur-Tag auf Sat- und Netzbetreiber-Ebene
<BC bcID="192">
</BC>
bei Denjenigen, die das wirklich nutzen, in Grenzen hält. Und die werden sicher wissen, was sie machen müssen. Zumal das Ganze ja sowieso Handarbeit ist - was die Zahl der 'betroffenen' Anwender ziemlich einschränken dürfte. Und letztlich ist das eine einmalige "Arbeit" die das Ganze zumindest nicht verschlechtert.

Die aktuell mitgelieferte providermap.xml ist ja uralt und betrifft eh nur Astra 1.
Da kann man auch meine entsprechend aufgebaute "Vorlage" mit ins Repo nehmen. Darin heißt "Digital+" sogar schon "MovieStar".


Andererseits ist diese "Angst" vor Überforderung von Anwendern schon immer ein Grund für Neutrino gewesen, ziemlich lange hinter Irgendwas herzuhinken. (wenn ich mal an Stress mit identischer ONID/TSID oder DiSEqC 1.1 oder Motorsteuerung denke)

Na ja, wer will kann es ja nun selbst einbauen wenn er möchte.
Und vielleicht kann man es ja auch auf eine Liste für das nächste Hauptnummern-Update legen.
Oder bei einem Upgrade auf Neutrino-UHD klammheimlich unterschieben...

[Janus]

Da sich immer noch Niemand um eine Lösung für eventuell fehlende BC-StrukturElemente in aktuellen Neutrino-Images gekümmert hat, werde ich mich wohl selbst mal daran machen, eine abwärtskompatible Option für eine von CST hingehuddelte Notlösung aus der frühen dbox-kompatiblen "Only Astra/Hotbird"-Periode (z.B. mit "Sky de", "Sky it" und evtl. noch "Sky gb" in einem einzigen Provider-Bouquet) in einer ansonsten funktionierenden korrekten Lösung des Providermappings zu suchen.

Dabei taucht aktuell wieder mal die Frage nach dieser Art von "Alterssicherung" (wir behalten das Gewohnte, auch wenn es noch so falsch ist) auf.

Ich würde gerne das ziemlich fehleranfällige DiSEqC-Handling von Grund auf überarbeiten. Für meine Begriffe ist auch der inzwischen vorhandene Code basicartig spaghettisiert.

Die jetzige Version von zusammengepfriemelten Erweiterungen für (fast) jede neue DiSEqC Definition ist
a) für Standard-Anwender (mit Plug&Play-Sucht) nicht wirklich einfach, und
b) für Anwender mit komplexen Anlagen und fortgeschrittenen Anforderung unvorhersehbar richtig ... oder auch ebenso unvorhersehbar falsch.

Im Ergebnis soll dadurch dann bei der Konfiguration unterschieden werden zwischen
* "einfachen" Installationen - idR mit einem einzigen Steuer~/Schaltelement - und
* "fortgeschrittenen" Installationen mit mehreren kaskadierten Elementen und/oder
* "professionellen" Installationen mit jeweils angepassten Sequenzen, gezielten Wiederholungen, Slave-Adressierung und Timings für einzelne oder Gruppen von Positionen.

Und je nach Wahl durch den Anwender sollen im UI nur die dafür relevanten Eingaben verlangt werden. Und wenn es sich anbietet, bei identischen Sachen auch nur einmal.

Soweit der Plan.
Macht aber für mich nur Sinn dafür Zeit zu investieren, wenn das gewünscht und nach Fertigstellung auch genutzt wird.

Dazu wäre es dann schön, wenn daraus ein Community-Projekt entstehen könnte.
Denn wie gesagt, ich bin schon recht alt und nicht wirklich fit in C und Linux.

Ansonsten bügel ich hier eigene Probleme mit meiner komplexen Anlage - wie die Sache mit dem 08/15 - Providermapping - durch Codeanpassung in meinem eigenen Branch zu Hause aus.

[Thomas]

das bekommst du doch eh nicht hin

[Miky]

das bekommst du doch eh nicht hin

Super! So motiviert man Leute. Respekt

[BPanther]

das bekommst du doch eh nicht hin

Janus macht sich immerhin Gedanken darüber, wie man bestimmte Probleme beheben kann und Du kommst mit einem solchen Kommentar? Du bist einfach nur noch peinlich.

[Thomas]

Nein er möchte das jemand anderes das macht da er das eh nicht hinbekommt, deshalb wird es immer mal wieder erneuert, das mit dem umbau und disec das geht schon über 3 Jahre

und BP nur damit du es nun villeicht verstehst - du kannst das Tuner FCB Zeug bei VU nicht lösen - hattest du ja geschrieben und einschätzung ist richtig.
und Janus kann nicht coden - also sieh doch realistisch welchen Sinn das hätte, keinen

[Miky]

Bitte back to Topic. Ich möchte hier nicht morgen deutlicher eingreifen

[Janus]

Nun ja,
immerhin habe ich früher mal das komplette Konzept für eine Branchenlösung entwickelt und im weiteren Verlauf fast 10 Jahre anwenderfreundliche Überarbeitung und fachliche Aktualisierung des gesamten Codes ziemlich alleine gemacht.
Aber weder unter Linux, noch in C, aber dafür ohne die Heute vorhandenen Entwickler-Hilfsmittel. pMate musste reichen...

Richtig ist dabei sicher, dass ich das angedeutete Projekt ohne Unterstützung alleine schon vom Umfang her nicht als Einzelkämpfer stemmen kann. Und EInzelkämpfer-Arbeit macht noch weniger Sinn, wenn das Ergebnis Niemand braucht. Oder die, die es nicht brauchen, das schlicht ablehnen.

Deshalb meine Idee, das als Community-Projekt anzulegen. Da kann Jeder der sich damit identifizieren kann, seinen Beitrag im Rahmen seiner Möglichkeiten leisten.

Und wenn man sich das DiSEqC-ReWork in ein ebenfalls neu gedachtes Frontend-Konzept einbindet, könnte dabei ja vielleicht auch ein eventuelles FBC-Problem gleich mit erschlagen werden.


Meine Vorstellung davon ist im Moment eine Connector-Klasse, die die Verbindung zwischen den Hardware-Devices und den Source-Quellen managt. Die Verbindung zwischen einem Connector - z.B. /dev/dvb/adapter0/frontend0 - zu einer Quelle - z.B. Astra1 - wird über eine child/parent - Verknüpfung von benötgten Schalt-Objekten z.B. im DiSEqC-Bereich Switch-Objekte und Motor-Objekte realisiert.
Dabei wissen die jeweils verknüpften Schaltelemente mit ihren Methoden selbst, wie sie den vom Connector angewiesenen Schaltweg einstellen müssen.

Die Connector-Klasse braucht sich dann nur noch um ihre eigene Verwaltung innerhalb des Connector-Managments (geeignet, aktiv, busy, blocked usw.) kümmern. Die Eignung kann ja jeweils über hardware-capabilities geregelt werden.

Diese Methoden würden per Vererbung auf die jeweiligen Connector-Typen 'kopiert', sodass sich der Gesamt-Codeaufwand auch in Grenzen hält. Ich vermute, die Objektorientierung unter C++ arbeitet wie unter C# mit einer "globalen" Methodentabelle, sodass auch der RAM-Bedarf in Grenzen bleibt. Zumal der bei aktueller Hardware locker reichen würde. Ich habe hier bei meiner HD51 mit MultiBoot-Image von insgesamt 1004 MB nur 724 MB belegt und noch 280 MB frei. Auf meiner Duo4K sollte das später dann noch besser aussehen.

Das User-Interface muss dann nur noch den im Dialog schon angebotenen Hardware-Devices den auf Grund der Eignung und der Empfangseinrichtung möglichen Pfad zum Source mit den 'vorliegenden' Schaltobjekten zusammenbauen.

Hat man also eine Box mit einem Sat-Tuner, bekommt man im EInstellungsdialog vollautomatisch nur einen
"DVB-Sat - Connector" zur Konfiguration angeboten.

Angenommen, der Tuner ist nur geeignet für DiSEqC 1.0 bekommt man für das (erste) Switch-Objekt 2-fach Schalter (Optionsschalter A/B, Positionsschalter A/B) und 4-fach Schalter (DiSEqC 4/x = AA AB BA BB) angeboten.

Angenommen, man hat nur einen Optionsschalter und wählt den, wird im letzten Schritt nach den dabei nur 2 Möglichkeiten mit einer Auswahlliste der verfügbaren Sat-Positionen gefragt.

Daran anschließend werden - wie jetzt auch - der LNB-Typ (inkl. Benutzerdefinition), Wiederholung und - bei höheren DiSEqC-Modi oder in komplexeren Installationen - weitere Parameter erfasst. Das ist aber schon eine Sache, die über die Properties der jeweiligen Objekte gesteuert werden kann und muss. Ein DiSEqC 2.0 Element muss nicht nach uncommited-Einstellungen fragen, aber sehr wohl nach eine Antwort an den Master.
Allerdings nur, wenn der Master (der Connector) die 2.x Capability hat.

edit: typo