Posts by S:oren

    -> leider noch kein Feedback bekommen

    Wenn man potentiellen Testern erzählt, dass sie das falsche Repository benutzen, und sie mit einer chaotischen Branch-and-Merge-Strategie (ok, vielleicht habe nur _ich_ das System nicht verstanden) ohne Tags alleine laesst, dann laeuft es eben darauf hinaus.

    Und ansonsten, Feedback innerhalb von 11 Stunden wuerde ich jetzt ohne spezielle Absprache nicht unbedingt voraussetzen.


    Release erstellt

    Releases v2.0.1 und v2.0.2 sind identisch, was vermutlich nicht so gedacht ist.

    Auch sind im master immer noch die tr() statt trNOOP() fuer st_modes drin. Auch das erscheint mir nicht sinnvoll.


    Und nein, _dieses_ Release v2.0.2 funktioniert immer noch nicht, meldet sich ja auch 2.0.1.


    Gruss,

    S:oren

    hmm, bei einem klappt die Übersetzung nun, beim anderen nicht...komisch.

    Wie schon bei den Beschriftungen der Knoepfe: tr() auf statischen Arrays funktioniert nur zufaellig abhaengig von der Initialisierungesreihenfolge (je nach Compiler und Compilerversion) und ist keine Loesung.

    Man müßte also entweder im laufenden Betrieb das "modes" Array neu aufbauen mit "tr(st_modes[i])"

    Das waere moeglich.

    oder es gibt eine schlauere Lösung

    Vielleicht. Wie machen es denn andere Nutzer von cMenuEditStraItem?

    oder es geht mit 2.0.1 jetzt final doch...

    Nein.


    Gruss,

    S:oren

    Danke für's Testen, umgestellt, im worst case wird nun versucht, st_modes doppelt zu übersetzen....

    Geht immer noch nicht, ist mir in der ersten Runde leider nicht aufgefallen.

    Warum sollte diese "Doppelübersetzung" irgendwie sinnvoll sein?


    Gruss,

    S:oren

    hab mal die "static" entfernt und die Texte nach setup.c ausgelagert, hier funktioniert's damit (immer) noch - komischerweise auch schon vorher.

    Ja, ist schoener so. Hat vorher auch funktioniert, weil 2 Kopien von Konstanten nur Platz verschwenden, ansonsten aber unkritisch sind.


    Aber ein Fix fuer das Uebersetzungsproblem, wie von FireFly  beschrieben, ist noch nicht drin. Deshalb funktioniert die Uebersetzung bei mir auch immer noch nicht.


    Gruss,

    S:oren

    OK, ich habe jetzt nochmal getestet, es liegt nicht an den .mo-Dateien. Meine Vermutung war also falsch.


    Anscheinend funktioniert die implementierte Uebersetzung in statischen Tabellen - st_modes, st_modesFooter - nicht (immer). Haengt wohl von der Initialisierungsreihenfolge ab.

    Mit

    sehe ich zumindest die uebersetzten Beschriftungen der Knoepfe. Das ist natuerlich nur ein Hack zum Test.

    Jedenfalls scheinen bei mir in den Tabellen die originalen unuebersetzten Strings zu liegen und erst der zweite Uebersetzungsversuch klappt. Alle Strings, die im Funktionskontext uebersetzt werden, sind korrekt, die in globalen Konstanten-Arrays nicht.


    Weil ich das gerade gesehen habe, es ist generell eine schlechte Idee, statische globale Variablen in Headern (setup.h) zu erzeugen, weil dann jede Uebersetzungeeinheit (hier insbesondere menu.o und osdteletext.o) eine private Kopie dieses Arrays (st_modes) bekommt.


    Gruss,

    S:oren

    Da ist (vermutlich) keine Übersetzung vergessen. Nur ist es ein Bug in einem Plugin, wenn die .mo-Dateien unterhalb von /usr/share/locale liegen muessen, damit sie genutzt werden. Der vdr hat eine Option --localedir=/path/to/locale. Die gibt an, wo nach den .mo-Dateien zu suchen ist. Und das klappt anscheinend nicht mit osdteletext.


    Gruss,

    S:oren

    Im "master" ist jetzt 1.9.9.dev.6, darin sind nun auf 10-Zeichen-Limit "angepaßte" Texte in Englisch und Deutsch.

    Danke. Es werden aber immer noch nur die englischen Knopf-Beschriftungen angezeigt, obwohl der Rest (z.B. channel switch menu) deutsch ist.

    Im "master" ist jetzt 1.9.9.dev.7, diverse Kleinigkeiten

    Gefaellt mir sehr gut.


    Gruss,

    S:oren

    Gefunden und gefixt,

    Ja, danke.


    bisher nimmt er nur den (übersetzten) Text

    Fehlt da nur die deutsche Uebersetzung? Im Gegensatz zu anderen Sachen werden die Beschriftungen der Knoepfe bei mir nicht uebersetzt.


    Frag eher, wieso seit längerer Zeit keiner das fehlende "break" bemerkt hat

    Weil auch sonst niemand verstanden hat, wozu man das braucht!? (nicht das break, die verschiedenen Cache-Formate)


    Gruss,

    S:oren

    paar Regressionstests wären super...

    Das "change channel"-Menue verschwindet ziemlich schnell, bevor man einen neuen Kanal eingeben kann, bleibt aber im Hintergrund irgendwie aktiv. Das hat frueher besser funktioniert.


    Keine Regression, aber fuer die Farbtasten-Beschreibung im 25-Zeilen-Modus stehen je Taste 10 Zeichen zur Verfuegung. Koennte hier entweder ein anderer Font oder zumindest ein passend langer Text verwendet werden ("Change cha", "24-Line-Mod")?


    Ansonsten nur interessehalber, welchen Sinn hat es, fuer den Seitencache verschiedene Formate zu unterstuetzen?


    Gruss,

    S:oren

    kann ich irgendwie prüfen ob es wirklich auf den Kernen 4-5 läuft?

    Das Kernel-Modul laeuft nicht auf bestimmten CPU-Cores, nur das Laden (und die probe-Funktion). Wenn das Modul da ist, hat das Laden auch geklappt. Ansonsten beschwert es sich ziemlich laut (synchronous external abort, so eine Art segfault).


    Dummerweise finde ich den IR-Receiver der Karte nicht mehr und bin mir deswegen unsicher, ob ich sie nicht einfach einschalten muss. Weiß hier zufällig jemand ob man die noch irgendwo kriegt, oder wohl eher ob es eine alternative zum originalen gibt?

    Einschalten?

    Ich glaube, Uwe hatte die IR-Receiver irgendwo mal gefunden, Pollin?


    Achja, brauche ich auch die Firmware der Karte und funktioniert das dvbhddevice noch?

    Treiber und Firmware brauchst Du natuerlich. Dann funktioniert auch das dvbhddevice.


    Gruss,

    S:oren

    und würde einen LibreELEC Fork mit deinen Patches bauen, wenn es ok ist.

    Der Treiber steht unter "GPL-2.0+"-Lizenz, die ATF unter "BSD-3-Clause". Du darfst alles damit machen, was diese Lizenzen erlauben. Mit LibreELEC kenne ich mich nicht aus, vermutlich ist das lizenztechnisch kein Problem. Und ansonsten habe ich natuerlich ueberhaupt kein Problem damit, wenn jemand meine Patches verwenden will.


    Ich habe noch eine Frage zur Stromversorgung. Hast du Riser card und TT-6400 am 4 pin DC out vom rockpro64 hängen?

    Hatte ich erst. Jetzt habe ich einen SATA-Stromstecker (mit Kabel) an die 12V vom PCIe-Slot (Unterseite RockPro64) geloetet und das da angeschlossen. So wird die S2-6400 beim Poweroff mit abgeschaltet und zieht keinen Strom mehr (ist sonst signifikant).


    Gruss,

    S:oren

    Da ich deinen Vorschlag auch sehr gut finde, bitte ich dich darum, dass du dich bitte darum kümmerst,

    Ich kümmere mich um den Treiber. Und ich nutze auf meinen 4 VDR nur selbstgebaute (Stable-)Kernel, keine Distro-Kernel. Somit sind andere Leute viel qualifizierter als ich, wenn's um Distro-Kernel geht. Da haben ja auch viele Leute schon gute Arbeit geleistet, worüber ich mich sehr freue.


    Ich habe keine Lust, mich im Detail in die verschiedenen Distributionen einzuarbeiten, und wie man da am besten Treiber integriert. Bei konkreten Fragen helfe ich gerne, bin da aber wie gesagt kein Experte. Auch bin ich hier im Forum kein Moderator, kann also nichts verschieben. Am besten eröffnet jeder, der Anleitungen oder Skripte pflegt, einen eigenen Thread, so kann dann auch immer der erste Beitrag passend aktualisiert werden.


    Gruss,

    S:oren

    wolfi.m und Trashcan


    Finde ich sehr gut, wenn ihr Anleitungen und Skripte baut, um den saa716x-Treiber einfach in verschiedene Distributionen zu integrieren.

    Ich schlage vor, das in jeweils einem eigenen Thread zu veröffentlichen, mit Nennung der Zieldistribution im Titel, vielleicht mit der aktuellen Version der Anleitung/des Skripts immer im ersten Post. So findet man das einfacher und hat im Thread weiter hinten auch genug Platz zum Diskutieren. Hier mit "18.04" im Titel erwartet man m.E. eher nicht etwas für Focal oder Buster.


    Gruss,

    S:oren

    Wenn in dem Verzeichnis mit den gepatchten Kernelsourcen zwar mit 'make menuconfig' eine korrekte .config gebaut wird, dann aber mit 'make modules' keine zugehoerigen Module, dann sollte es zumindest Fehlermeldungen geben (die man besser sieht, wenn man das make ohne -j aufruft).


    Ich sehe gerade:

    gibt es auch im Unterverzeichnis /drivers/media/common/saa716x/ die ganzen Quelldateien und ein passendes Makefile.

    Das ist nicht mein Treiber.


    Gruss,

    S:oren