Posts by S:oren

    Mit dvdhddevice habe ich keine Probleme in osdteletext-1.0.5 festgestellt. Hoffe mal, das ist die neueste Version, bei den vielen Merges...


    Danke fuer die ganzen Verbesserungen,

    S:oren

    Hatte ja schon vermutet, dass es am Font liegt, deshalb mein Hinweis darauf. Der teletext-Font ist speziell.

    Ist mit der zusaetzlichen "Luft" nicht die "ASCII-Art" (z.B. stilisierte Senderlogos auf Seite 100) kaputt mit haesslichen Streifen?


    Aber wie gesagt, ohne Offset alles schick bei mir. Kann von mir aus bleiben wie es ist.


    Gruss,

    S:oren

    Das würde mich auch interessieren, was Du da gemacht hast.

    Der Code ist in imagescaler.[ch], es gibt einen Eintrag in der HISTORY (wieso ist da die Reihenfolge der Versionen jetzt so merkwierdig?) dazu. Die Idee hatte ich mit einem Freund in der Kaffeepause im Buero diskutiert, er hat das dann schnell zusammengehackt und dankenswerterweise zur Verfuegung gestellt. Die Einbindung koennte verbessert werden, aber ich wuerde dann gleich noch den Rest der *magick 'rauswerfen, die m.E. viel mehr Probleme verursacht, als loest.


    Wenn Du also noch Patches hast für den light_version Branch, immer her damit.

    Bisher mehr Ideen als Patches. Aber wenn ich mich da austoben darf, kann ich mir vielleicht mal Zeit nehmen. Die spannenden Sachen sind natuerlich nicht die vernuenftigen, also erstmal Bug fixen. Andererseits kann ja jeder auch die existierenden Versionen benutzen, wenn die neuen nicht gefallen. Der nervigere Bug war der segfault bei den Messages.


    Vermutlich werden die Distri-Leute recht ungluecklich, wenn es 2 aktive Branches in einem Plugin gibt. Nicht so ideal.


    Gruss,

    S:oren

    ... ist man für jeden konstruktiven Hinweis dankbar.

    Freut mich! Wirklich.


    Das habe ich nicht ganz verstanden.

    Da kommen die Reflexe als U-Boot-Board-Maintainer und Linux-Progammierer durch. ;-)

    Dort ist es absolut verpoent, Aenderungen von Whitespace (Leerzeichen, Tabs) und funktionale Aenderungen in einem Patch zu mischen. Das wird nicht akzeptiert. So eine Policy gibt es hier natuerlich nicht. In eigenen Projekten versuche ich dennoch, mich an die Linux-Regeln zu halten, weil ich die sehr gelungen finde.


    Die eigentliche Ursache für das "Powerpoint" ähnliche Verhalten lag an diesem Flush.

    Wie bereits gesagt, jeder im Skin erfundene Flush ist einer zuviel. Die aus meiner Sicht einzig richtige Loesung waere, den Code so umzustellen, dass sowas nicht noetig ist.


    Jetzt sehe ich auch, was Du mit den neuen Threads meinst. Das sind keine neuen Threads, das dient nur zur eindeutigen Identifikation in den Logs, diese Threads gab es vorher auch schon.

    Muss ich zugeben, habe ich nicht genau hingesehen. Da lag ich falsch.

    Das generelle Problem aber bleibt. Das Anlegen von Threads ist eine sehr teure Operation. Warum in aller Welt startet man staendig dynamisch neue Threads, laesst die ueberwiegend gar nicht parallel laufen, handelt sich Synchronisationsprobleme damit ein und spart am Ende gar nichts, im Gegenteil?


    Ja, in einer idealen Welt... Leider wollen viele Anwender halt ein Bling-Bling.

    Und die Anwender, die einfachen und schnellen Code wollen, muessen sich mit dem ganzen Overhead herumaergern!?


    Ganz im Ernst, was ist denn eigentlich die Zielgruppe fuer die verschiedenen louis -Skins? (Welche gibt es ueberhaupt mittlerweile?)


    Aus meiner Sicht:

    Zuerst war skinnopacity, tolles Design, frische Ideen (z.B. schmale Menues), großartig! Das war fuer mich ein HD-VDR!

    Ein bisschen behaebig, (z.B. durch dynamische Objekte sogar fuer jeden menuitem, Verwendung von imagemagick), noch benutzbar auch auf sparsamer/langsamer Hardware. Den damals fuer mich größten Performancekiller konnte ich durch Einbringen eines einfachen und schnellen Image-Skalers beseitigen. So habe ich das jahrelang verwendet und verwende es heute noch.

    Dann kam skinnopacity-1.1.0, der Versuch, alles denkbare in dieses Plugin hineinzuquetschen. Fuer mich das Ende von Performance und Wartbarkeit. Zu irgendwelchen Aufraeumarbeiten am Code kam es nicht mehr, weil auch louis nichts mehr mit dem Code zu tun haben wollte (so sah es zumindest fuer mich aus).

    Stattdessen kam skindesigner. Viel zu langsam fuer mich, aber die Feature-Spielwiese, die viele Leute mit potenter Hardware haben wollten. Fein.


    Wie soll nun die Zukunft aussehen?

    Ich wuensche mir ein Skin mit look&feel von skinnopacity, ohne viel Bling-Bling (nur Channel-Logos), aber ohne Kompromisse bei Codequalitaet und Geschwindigkeit. Das sehe ich durch Weiterentwicklung (vielleicht auch Abspecken) des 1.0.x-Branch gegeben. (Vorher wuerde ich gerne noch den letzten verbliebenen Bug fixen: die durch das nicht vdr-konforme Handling der Menueeintrage fehlende Möglichkeit, im remote-Plugin eine Fernbedienung anzulernen.)
    Das vertraegt sich leider nicht mit Deinem Ansatz, noch mehr Konfigurierbarkeit einzubauen und alle bestehenden Erker beizubehalten. Und dann sogar den Code der schon jetzt verschiedenen Plugins wieder zu vereinheitlichen. Das kann die vorhandene Komplexitaet nur weiter steigern.


    Wie loest man diesen Widerspruch am besten? Gute Frage!

    Waere interessant, welche Features der verschiedenen Skins wirklich aktiv genutzt werden.


    Gruss,

    S:oren

    Ich habe dazu mal einen Branch Devel unter gitlab.com/kamel5/SkinNopacity angelegt.

    Oh ha, das gibt es ja eine Menge Aenderungen in dem Devel-Branch.

    Wenn Du mich danach fragst, kann ich ja mal ein kleines Review machen. Sind natuerlich alles unverbindliche Anregungen und sicher nicht der Weisheit letzter Schluss.


    Zunaechst finde ich einen Devel-Branch gut, so ein Fix eines Fixes mit sofort einer neuen Versionsnummer sieht immer nach uebereiltem Commit aus. Meistens bringt es etwas, wenn andere Leute vor einem Release etwas ansehen oder testen.


    Zu den Patches selbst:

    - "Cleanup imgCache declaration" finde ich gut, wollte ich auch schon machen (in einer neuen Version nach meinen letzten Patches). Nur passen Patch-Titel und -Beschreibung (die mir irgendwie bekannt vorkommen) m.E. nicht. Hier wird ja nicht die Deklaration aufgraeumt, sondern ein Objekt global abgelegt, was vorher lokal war und immer explizit weitergereicht wurde. Im Ergebnis ergibt es aber viel Sinn, den imgCache genau wie den geoManager anzusprechen.

    Nur warum gibt es 2 Patches mit dem selben Titel? Zuerst den zweiten Teil vergessen? Dafuer gibt es 'git rebase -i' und "fixup"...

    - "Cleanup optimized Start()", "Fixed an error in Displaychannel - the clock wasn't updated.", "Eliminate init in nopacity.c"

    Ergibt alles fuer mich Sinn. Wenn man "Erbsen zaehlen" will, Patch-Titel sind immer (sonst) im Imperativ, also "Fix error" statt "Fixed an error".

    - "Rename detailview.* to view.*", "Rename menudetailview.* to detailview.*"

    In Umbenennungen sehe ich keinen Wert, aber ich kenne auch die anderen Skins nicht, zu denen man hier offenbar kompatibel sein will.

    - "Some cosmetic changes"

    An sich sinnvoll. Wie ich es gelernt habe, gehoeren Whitespace-Cleanup und funktionale Aenderungen (long -> int in for-Schleifen) nicht in einen Patch.

    - "Cleanup menuView declaration"

    Das halte ich fuer einen Fehler. Globale Variablen sind immer eher schlecht. Hier wird auch noch eine Klasse DisplayMenuView, die nur in DisplayMenu benutzt wird, global abgelegt. Ergibt fuer mich wenig Sinn. Fuer mich gehoert die ganze Klasse DisplayMenuView komplett in die Klasse DisplayMenu integriert. Macht alles viel einfacher und erlaubt weitere Codeoptimierungen.

    - "Eliminate cNopacityDisplayMenuView::SetAvrgFontWidth", "Make cView::SetFonts privat"

    Ergibt fuer mich Sinn.

    - "Some simplifications"

    Hab ich nicht im Detail angesehen, vereinfacht aber den Code, ergibt somit Sinn.

    - "Eliminate detailView in cNopacityDisplayMenu"

    Das verstehe ich nicht, da fehlt mir zumindest eine Erklaerung. Auch bläht es den Code extrem auf, erscheint mir nicht sinnvoll. Scheint auch neue Threads zu erzeugen, was ich fuer einen großen Fehler halte (langsam, fehleranfaellig, unuebersichtlich).

    - "Faster display info"

    Auch wieder ein zusaetzlicher Thread, wobei ich gar nicht sehe, wo der gestartet wird.

    Nach der "reinen Lehre" soll ein Skin nur darstellen, was der VDR vorgibt. Dabei soll ein Skin keine zusaetzlichen Flush()-Operationen erfinden (was bei der S2-6400 extrem langsam ist), sondern nur dann einen osd->Flush() ausfuehren, wenn vom VDR ein Flush() angefordert wird. Das ist hier, was die Performance-Verbesserung bringt.

    Auch soll ein Skin eigentlich keine eigenen Threads haben. Wie schon vorher geschrieben, im Hintergrund Bilder laden, die vielleicht skalieren und und in Pixmaps wandeln, OK, wenn man es richtig macht und die Threads richtig synchronisiert. Aus mehreren Threads auf ein OSD schreiben, m.E. immer verkehrt.

    Ja, das Faden geht nur mit eigenen Thread, aber dann bitte nach dem kompletten Aufbau des OSD nur noch das Alpha aendern. Wobei ich nie ein Fade-In verwendet habe (nur ein Fade-Out frueher mit skinelchi, kann skinnopacity gar nicht), und auch das ist mittelmäßig unschoen, wenn man von einem Menue auf ein anderes umschaltet, was man als Skin leider nicht (einfach) erkennen kann. Auch zum Scrollen von Menueeintraegen braucht man vermutlich Threads, habe ich mir noch nicht im Detail angesehen. Ansonsten machen zusaetzliche Threads nichts schneller, nur komplizierter.


    Es wäre schön, wenn Du das mal auf Deiner Hardware testen könntest.

    Hab die selbe Hardware, die Uwe beschrieben hat.


    Wie schon vorher geschrieben, den 1.1.x-Branch mit den ganzen Threads halte ich fuer kaputt. Der 1.0.x-Branch funktioniert fuer mich ohne "Powerpoint-Effekt", nur diesen Branch finde ich als Ausgangspunkt fuer weitere Entwicklungen geeignet (ein paar Ideen haette ich da noch).


    Ich hoffe, ich habe mich jetzt nicht zu unbeliebt gemacht...


    Gruss,

    S:oren

    Wird die Firmware nicht geladen, erscheint meist auch kein passender Eintrag im lspci.

    Sowas habe ich bei PCI-Karten noch nie gesehen, nur bei USB-Devices. Generell auszuschließen ist es nicht, kommt aber bei einer S2-6400 definitiv so nicht vor.


    Der lspci Eintrag ist aber da, auch ohne dass Modul und Firmware geladen wären.

    Yep!

    Bis vor einem Monat war ein Bug im Treiber, dass _nach_ dem Laden des Moduls die PCI-IDs kaputt waren, ist jetzt gefixt.


    Gruss,

    S:oren

    Normalerweise gibt es sehr wenige Änderungen für alte Treiberversionen. Eine Ausnahme war ein Bugfix vor einem Monat, den ich auf alle Branches ab 4.20 backportiert habe (dort hatte ich den Bug eingebaut).

    Neue Features gibt es ansonsten nur für neue Kernel, z.B. läuft der Treiber vermutlich erst ab 5.6 auf arm64. Sowas kann ich gerne auch für ältere Branches zur Verfügung stellen, falls Interesse besteht. Ansonsten ist mir das Testen für alle Branches ab 4.12 zu viel Aufwand.

    Ich selbst nutze immer nur den neuesten Branch (ggf. mit zusätzlichen Patches von linux-stable) oder sogar schon die letzten -rc-Versionen eines neuen Mainline-Kernels, damit es den Treiber zeitnah für jede neue Linux-Version gibt. Distro-Kernel habe ich nicht auf meinen VDRs, somit bin ich immer froh, wenn jemand hier herausfindet, wie man den Treiber in die verschiedenen Distro-Kernel integriert.


    Gruß,

    Sören

    Ich habe noch ein paar Patches fuer den 1.0.x-Branch von skinnopacity. Neben Aufraeumarbeiten ist insbesondere ein Segfault gefixt fuer den Fall, dass bei Wiedergabe mit modeOnly-Display (z.B. Pause) eine Message dargestellt werden soll.


    Insgesamt habe ich die Darstellung der Messages etwas vereinheitlicht, was jetzt normale Message-Boxen auch fuer replay- und channel-Displays ergibt.


    Vielleicht moechte das jemand anschauen, testen, kommentieren, uebernehmen...


    Ist etwas viel, um es hier als Patches anzuhaengen, deshalb zu finden hier.


    Gruss,

    S:oren

    Bei skinnopacity ist es so, das die Senderlogos iin einem extra Schritt entsprechend vorbereitet werden müssen.

    Das habe ich nie gemacht, trotzdem sind die Senderlogos "richtig".

    Ich habe allerdings "Hintergrund für Kanallogos benutzen" in "Allgemeine Einstellungen" auf "ja". Vielleicht braucht man das alternativ.


    Selbsterklaerend sind einige Einstellungen leider nicht, ja.


    Gruss,

    S:oren

    Waere nett gewesen, den ganzen Commit zu uebernehmen. Ein bisschen Erklaerung, warum etwas so gemacht wurde, schadet nicht. Auch ist es zumindest guter Stil, den Autor von Patches beizubehalten.


    Trotzdem danke,

    S:oren

    Da Version 1.0.6 von skinnopacity so gut fuer mich funktioniert, habe ich nochmal gesucht, warum die Control-Icons (Play/Pause/...) in der Wiedergabeanzeige immer kurzzeitig kaputt erscheinen. Diese kleine Unschoenheit stoert mich schon lange.


    Git-Patch anbei. Vielleicht will es jemand testen oder uebernehmen. Vermutlich passt der Patch zu den 1.1.x und 1.0.x-Branches von skinnopacity.


    Gruss,

    S:oren