Posts by S:oren

    Auf meinem RockPro64 mit S2-6400 und vdr-2.5.1 ist skinnopacity in Version 1.0.6 deutlich schneller als in Version 1.1.5. Das macht wieder Spass, keine "Powerpoint-Animation" mehr im Detail-EPG-View.


    Nochmals vielen Dank,

    S:oren

    Zunaechst Vielen Dank! Ich haette nie zu hoffen gewagt, dass es so schnell eine vdr-2.4-taugliche Version des alten, fuer mich gut funktionierenden und nicht "ueberladenen" Stands von skinnopacity gibt.


    Leider crasht es gleich beim Start

    Code
    1. Feb 1 10:42:14 rockpro64 vdr: [609] initializing plugin: skinnopacity (1.0.5): 'nOpacity' Skin
    2. Feb 1 10:42:14 rockpro64 taskset[609]: vdr: magick/semaphore.c:606: LockSemaphoreInfo: Zusicherung »semaphore_info != (SemaphoreInfo *) NULL« nicht erfüllt.
    3. Feb 1 10:42:14 rockpro64 systemd[1]: vdr.service: Main process exited, code=killed, status=6/ABRT


    Gruss,

    S:oren

    Das Problem sind hier die ganzen Zusatzinformationen, wie Bilder, Banner, TVDB usw. und das dauert relativ lange.

    Das habe ich alles nicht. Auch im Setup deaktiviert, wo moeglich.

    Das Problem mit der Verzoegerung habe ich nur im Haupt-Recordings-Menue (breit, ist das auch von epgsearch ersetzt?), und nur beim ersten Erscheinen. Dort gibt es keine Bilder, Banner, und so Zeug, muss also etwas Anderes sein.


    Im Moment bin ich noch dabei, mir die Zusammenhänge klar zu machen, ich denke aber, da lässt sich einiges optimieren.

    Ich freu mich drauf. :-)


    Welche Version hattest Du da und welches Theme?

    commit 114fb900bb3fdbef09258eef5a2a8c3b08ab7ddc ("fixed channel info display"), default, vdr-2.2.0


    Gruss,

    S:oren

    Ich habe im letzten commit jetzt mal alle aus meiner Sicht unnötigen Flush()-Aufrufe auskommentiert, das sollte schon einiges Verbessern.

    Wie schon vorher geschrieben, solche Hacks hatte ich auch schon bei mir, aber eine saubere Loesung ist das aber nicht.


    Damit scheint es jetzt so zu sein, dass erstmal eine "leere" EPG-Deteilansicht erscheint, dann aber der ganze Text auf einmal. Ja, ist vom Gefühl angenehmer als vorher, aber vor den Aenderung mit den Tabs fuer die normale Info und Wiederholungen war es noch besser. Auch ist der Strich zwischen dem Titel- und Textbereich verloren gegangen, gefiel mir vorher besser, aber ueber Design kann man streiten...


    Die einzigen Verzögerungen, die ich momentan hier sehe, entstehen durch das Laden der Zusatzinformationen.

    Stell doch mal für das Aufnahmenverzeichnis die Menü-Breite auf schmal und das Video auf Fenster. Dann müssten die Verzögerungen deutlich geringer sein.

    Ich bin auch hier weniger an Hacks interessiert, mehr an Verstaendnis des Problems und einer eventuellen sauberen Loesung.

    Was genau fuer Zusatzinformationen sind das, wo kommen die her, welche Patches fuer was (vdr core, plugins,...?) braucht man da?


    Das schmale Aufzeichnungsmenue finde ich haesslich und schlecht lesbar, aber weniger Informationen werden da doch auch nicht angezeigt. Wieso macht das einen Unterschied? Testen laesst sich die Verzoegerung bei mir schlecht, meistens geht es verzoegerungsfrei, aber selten dauert die Anzeige des Aufzeichungsmenue so ca. 5 Sekunden. Da denkt man, man hat die Fernbedienung nicht richtig gedrueckt, dann springt man aber gleich drei Menues weiter.


    Gruss,

    S:oren

    Ich vermute, die ganze OSD-Library ist nicht thread-safe. Also dürfen genau genommen alle OSD-Aufrufe nur aus einem Thread kommen (nicht nur das Flush() ).


    Eine Verzögerung habe ich gelegentlich im Aufnahmen-Menue, nirgends sonst. Da hattest Du auch schon irgendwo Patches, ich habe allerdings den Ueberblick verloren. Mach bitte neue Forum-Threads auf fuer solche Sachen, sonst geht das unter. Gibt es da noch Verzoegerungen, und wenn ja, wieso?


    Gruss,

    S:oren

    Hier ist der Thread, wo ueber die Weiterentwicklung von skinnopacity diskutiert wird. Den habt ihr aber gut versteckt ;-)


    es macht ja keinen Sinn die erste Anzeige von skinnopacity komplett zu unterdrücken, deshalb habe ich das Handling der Kanalanzeige nochmal etwas optimiert.

    Also bitte nochmal den letzten commit testen, ob das so bleiben kann.

    Sehr schoen. Funktioniert einwandfrei auf einer S2-6400. Hatte es aber auch schon, bevor louis diesen Workaround fuer ein anderes Ausgabeplugin (kann mich nicht mehr erinnern, welches das war) eingebaut hat. Freut mich sehr, dass das wieder gefixt ist.


    Das liegt daran, das die Info und alle anderen Daten in einem separaten thread nachgeladen werden und wurde damals bewusst so eingebaut.

    Sehr aergerlich fuer mich. Deshalb habe ich skinnopacity jahrelang in der Version vor diesem Commit benutzt (mit vdr-2.2). Ich halte es fuer einen grossen Fehler, ein OSD Flush() aus mehreren Threads gleichzeitig unkoordiniert aufzurufen. So war das nie gedacht, funktioniert auf der HD-FF nur "aus Versehen ein bisschen".

    Daten in mehreren Threads laden ist OK, ob es wirklich signifikant etwas bringt, weiss ich nicht. Aber Flush() sollte nur aus dem Haupt-Thread aufgerufen werden. Und auf der S2-6400 möglichst selten (am besten nur 1x pro OSD-Menue), weil das Kopieren der Daten auf die Karte sooo viel langsamer ist, als alle Berechnungen vorher. Mit den vielen Flush()-Aufrufen entsteht die beschriebene "Powerpoint-Animation" mit nacheinander auftauchenden Bildelementen. Finde ich grueselig. Hatte schon ein paar der Flush()-Aufrufe fuer mich herausgeloescht, bin aber noch nicht dazu gekommen, einen vernuenftigen Patch zu bauen, der die Threads koordiniert oder weglaesst. Sehr schoen, wenn Du das nochmal ansehen willst.

    Ich kann diesen Effekt bei mir nicht erkennen.

    Ich sehe im Wesentlichen auch nur den Effekt nacheinander auftauchender Bildteile. Aber wie ich das sehe kann ein Flush() aus einem Thread auch halb-gezeichnete Sachen aus einem anderen Thread mit darstellen, was zu den merkwuerdigsten Effekten fuehren kann.


    Gruss,

    S:oren

    Wenn es aber das Problem mit Timerkonflikten ist, kannst Du bitte mal den letzten Stand von skinnopacity auf projects.vdr-developer.org testen, ob der crash damit weg ist.

    Scheint weg zu sein. Aber der Crash passierte nicht jedes Mal. Werde es weiter beobachten.


    Danke,

    S:oren

    Bei mir (auf einer S2-6400) crasht diese Version. (Noch) keine Ahnung, warum.

    Es war ein (bekanntes) Problem mit skinnopacity und epgsearch. osdteletext in Version d614fc0 funktioniert bei mir auf der S2-6400, Entschuldigung fuer den Fehlalarm.


    Würde meinem Ziel "Null Patches bei Arch Linux" auf jedem Fall wieder einen Schritt weiter helfen. Nur noch gefühlt tausende Plugins die geprüft werden müssen...

    Vielen Dank fuer das Pflegen der neuen Repositories. Ich steige gerne auf diese um, wenn man dann keine weiteren Patches mehr braucht.


    Gruss,

    S:oren

    Solange aber noch die Wahrscheinlichkeit besteht das jemand noch aktiv weiterentwickeln will ist auch schwer das an einer Stelle wieder zusammenzuführen.

    Ich sehe nur 2 sinnvolle Moeglichkeiten. Entweder einigen sich die vorhandenen Maintainer und uebernehmen gegenseitig die commits (auf Anfrage des jeweils anderen Maintainers oder einer anderen Person, genau wie bei Deiner Anfrage oben), sehr sinnvoll. Oder ein "Metamaintainer", wie auch immer man das nennen will, uebernimmt immer die Patches aller anderen, auch wieder auf Request von wem auch immer, und bleibt dabei immer am Ball, auch noch brauchbar.

    Problematisch wird es dann, wenn man sich nicht ueber die Qualitaet oder Sinnhaftigkeit von einzelnen Patches einigen kann, dann auch nicht bereit ist, verschiedene Branches zu pflegen, und sich im schlimmsten Fall noch einen "Krieg der Versionsnummern" liefert. Da helfen eigentlich nur klare Absprachen und Einigkeit ueber die jeweiligen Ziele der eigenen Entwicklungstätigkeit. Nicht immer wird das klappen, nicht jeder will den zusaetzlichen Aufwand investieren. Aber die Hoffnung stirbt vielleicht zuletzt. Selten streiten sich mehrere Maintainer ueber die Vorherrschaft, meistens werden doch neue Repos nur aufgemacht, wenn der bisherige Maintainer nicht (schnell genug) reagiert. Dann wird normalerweise das aktuellere Repo die neueren Versionsnummern haben, hier bei osdteletext hat es leider nicht funktioniert. Aber auch da will ich niemandem boesen Willen unterstellen. Vielleicht aergern sich viele Leute umsonst, haben einfach nur noch nicht nach einem Update gefragt. Hast Du ja gerade m.E. richtig gemacht. Ich war auch zu faul dazu.


    Allerdings bin ich zudem der Meinung das man es den "Mitwirkenden" so einfach wie möglich machen sollte.

    Klar, dem kann sicher jeder zustimmen. Aber dann wird es schon kompliziert. Ich persoenlich bevorzuge klar git-send-email, keine pull-requests auf irgendeiner Platform.

    Ich habe lokale git-Repositories mit mehreren remotes, haette auch kein Problem, parallel Aenderungen in verschiedene oeffentliche Repos zu pushen. Da sehe ich auch kein Problem mit mehreren Mirrors, solange sie konsistent sind.

    Ich moechte jedenfalls nicht von einem Workflow irgendeiner Platform abhaengig sein. Keiner weiss, wie lange diese Platform aktuell ist, keine komischen Aenderungen der Nutzungsbedingungen macht, irgendwann altbacken und "mies zu bedienen" ist. Auch ich sehe den Trend zu grafischen Benutzer-Oberflaechen, bleibe aber ein Freund der Kommandozeile. Mit git ist zum Glueck beides moeglich. Die verwendete Platform zur Veroeffentlichung sehe ich zweitrangig (ich veroeffentliche z.B. den saa716x-Treiber auf github, finde es als Platform aber nicht besonders toll).

    Was letztendlich zaehlt ist der Code, und es muss sich jemand finden, Patches einzupflegen. Auch da ist m.E. nicht unbedingt das Problem, dass niemand die Aufgabe uebernehmen will, sondern eher die Unklarheit, wie man zu dem Job kommt und wie man ihn wieder los wird.


    Gruss,

    S:oren

    Hoffe das war soweit verständlich...

    Ja, ist es. Ich stimme in vielen Aussagen ueberein. Fuer mich, mit etwas Abstand draufgeschaut, loest es in dieser Form aber wenig Probleme. Das mag fuer einen Distributor etwas anders sein, aber eigentlich sind die Interessen von "einfachen" Usern doch gar nicht so verschieden. (Dafuer die Ansichten zum "besten" Vorgehen sicher bei jedem individuell unterschiedlich. Und eine objektiv beste Vorgehensweise schwer zu finden.)


    Trotzdem wäre es in jedem Fall besser wenn sowas erstmal an den wahrscheinlichsten aktuellen Maintainer geht (in dem Fall https://github.com/rofafor/vdr…sdteletext/tree/vdr-2.3.x).

    Und das ist genau nicht so einfach. Ich habe gerade vor wenigen Tagen nach aktuellen Versionen dieses Plugins (osdteletext) gesucht (Umstieg von vdr-2.2.0 auf vdr-2.5.1). Die vdr-developer-Version ist 0.9.7, hat aber das Problem mit den Streifen in der ASCII-Art, die rofafor-Version ist 0.9.6, hat aber den Patch, der das behebt. Fuer mich war die aktuellere Version erstmal 0.9.7, und es hat einiges Suchen hier erfordert, den Status-quo zu erkennen.


    Das Problem an dieser Stelle ist also nicht, dass es zu wenige Maintainer gibt, sondern zu viele, und damit inkonsistente Versionen in verschiedenen Repositories. Idealerweise einigen sich die vorhandenen Maintainer auf ein Haupt-/Upstream-Repo, aber das kann man nun mal nicht erzwingen. Der Ansatz von vdr-developer war, dort die neuesten Versionen zu sammeln, auch neue Versionsnummern zu vergeben, damit eine aktuelle Pluginsammlung zu haben, wo man auch sieht, dass sie aktuell ist. Diesen Ansatz ("Meta-Maintainer," wo es keinen richtigen Maintainer gibt) halte ich immer noch fuer sehr gut und sehr hilfreich (fuer Nutzer und Distributoren), wenn er konsequent umgesetzt wird. Somit denke ich auch, dass man Tobi nicht gerecht wird mit "mies zu bedienender one-man-show".


    Alles Weitere wuerde hier in der Tat zu sehr off-topic.


    Gruss,

    S:oren

    Meine Gedanken zur Problematik, soll nicht heissen, dass dass ich speziell pbrb anzweifeln oder korrigieren will, nur weil die Zitate aus seinem Beitrag stammen.

    alle 3 sind damit aktuell "stale"

    Wieso? Das Plugin funktioniert einwandfrei (fuer mich, vermutlich auch andere), insbesondere in der rofafor-Version. Warum sollte es da staendig neue Commits geben?


    einer davon der 4bpp "hartcodiert"

    Das war vom Patch-Autor (powarman) als Hack fuer ein spezifisches Problem eines Users entwickelt worden. Wundert mich also nicht, dass das nicht in einem offiziellen Repo landet.


    Denkt denn keiner daran, daß dem "best-fork-of-the-month" mal irgendwas passieren kann und der möglicherweise nicht mehr zugreifbar ist?

    Ist alles GPL, man darf auch pullen ohne Pull-Request...


    Da ein Community-Projekt starkes Interesse haben sollte, daß die Forks wieder irgendwie in den Master zurück "contributen" sollten,

    Das scheint mir das Hauptproblem zu sein: es gibt keine Einigkeit, was der Master ist. Waere in der Tat schoen, wenn es eine zentrale Anlaufstelle für die aktuellen Plugins gaebe. Nach meinem Verstaendnis war vdr-developer dafuer gedacht, warum braucht man zusaetzlich github/gitlab/wasauchimmer? Das als offene Frage, wahrscheinlich gibt es gute Gruende. Und ja, sowas zu pflegen ist viel Arbeit, die selten angemessen gedankt wird.


    Gruss,

    S:oren

    empfehle ich auch ein selbstgebautes u-boot mit der angepassten Trusted-Firmware von hier (da könnte ich mal eine neue Version bauen).

    Ich habe einen Branch fuer die 2.4er ATF-Version mit ins Repository gelegt. Neuere RockPro64-U-Boot-Versionen (2020.10, 2021.01) sind uebrigens kaputt, ich verwende 2020.07.

    ich werde mich daran versuchen und berichten.

    Hat es mit dem PCIe-Switch funktioniert?


    Gruss,

    S:oren

    der neue Treiberpatch funktioniert!

    Da bin ich ja froh, dass wenigstens der Fix fuer meinen Treiberbug nicht kompletter Bloedsinn ist. ;-)

    Es wird zwingend ein reboot des kernels nötig.

    Eigentlich ein Reset der S2-6400, z.B. durch Neuladen des PCIe-Hostcontroller-Treiber-Moduls. Aber Reboot tut's auch, ist einfacher, und wird sowieso nie wieder gebraucht, wenn man nur den gefixten Treiber verwendet.

    Das bedeutet: wenn schon mal gepatch wurde dann kann man nicht nochmal einen anderen Patch darauf anwenden.

    Einen anderen Patch schon. Sinnvollerweise nicht nochmal den selben (ersten Teil).

    Ich kann natürlich mit meinem Skript auch alles löschen vor dem entpacken und patchen. Soll ich das so tun?

    Finde ich sinnvoll. Ein Update fuer einen ueber ein Jahr alten Treiberbranch ist kommt ja nicht so oft vor, dass man dafuer speziell optimieren muesste.


    Gruss,

    S:oren

    Jetzt wird die Sache schon etwas klarer.

    03:00.0 0480: 1131:7160 (rev 02)

    Subsystem: 13c2:300a

    Das sind die richtigen PCI-IDs (aus dem EEPROM):

    Vendor:Device 1131:7160 (Philips, SAA7160)

    Subvendor:Subdevice 13c2:300a (Technotrend, S2-6400 Production Version)

    Auf diese IDs wird der Treiber gematcht und offenbar auch geladen.

    03:00.0 0480: 1131:7160 (rev 02)

    Subsystem: 1131:0000

    Das sind die Hardware-IDs der PCIe-Bridge, wenn sie keinen EEPROM erkennt. Diese IDs sollten nicht auftauchen, insbesondere wenn der Treiber schon mit Hilfe der richtigen IDs geladen wurde.

    Es muss also etwas damit zu tun haben welcher Kernel läuft

    Welcher ist es denn?

    Das kann doch nicht der Eprom sein, oder wird der vom aktuellen Linuxsystem umgeschrieben?

    Nein.

    Wieso sonst bringt plötzlich lspci eine andere ID als Subsystem? Die Karte funktioniert ja korrekt und unter einem anderen System wird die richtige ID wieder erkannt.

    Das ist offenbar ein Bug. Wo genau der zu suchen ist, ist nun die Frage.


    Gruss,

    S:oren

    OK, aber wie geschieht das, den Eprom zerschiessen?

    Mir ist das schon mal beim Basteln mit PCIe-Adaptern (Projekt siehe hier) passiert. DIe genauen Umstaende sind (natuerlich) nicht klar. Ich wollte solche Fehler auch nicht absichtlich provozieren und da weiter testen.

    Es waren zum Glück nur ein oder 2 Bytes kaputt, die konnte mit i2c-tools wieder fixen.

    Und wieso wird die Karte wieder erkannt wenn ich eine Neuinstallation vomUSB-Stick mache, an der iso habe ich ja gar nichts angepasst, sie ist original.

    Damit wird im HW-Setup wieder TT-S2 6400 erkannt. Demnach müsste ja die originale HW-ID wieder funktionieren? Das könnte nicht sein wenn etwas am Eprom auf der Karte dauerhaft zerschossen wäre.

    Ich habe keinerlei Ahnung von Easyvdr und damit auch nicht von der dortigen Hardwareerkennung.

    Fuer mich sah es so aus, als ob eine neue ID in die Datenbank eingetragen werden soll, damit die Karte wieder erkannt wird (weil sie jetzt diese PCI-ID hat). Insbesondere:

    lspci bringt eine andere Hardware-ID aus als in der Datenbank hinterlegt ist

    kam mir bekannt vor. Heisst das, lspci gibt nach jedem Reboot andere PCI-IDs fuer die Karte aus?

    Denkbar ist schon, dass ein EEPROM etwas durcheinander kommt, wenn man mitten im Schreibzyklus die Power wegnimmt. Aber ein beliebiges anders Hardwareproblem kann ich natuerlich nicht ausschliessen.


    Gruss,

    S:oren