Posts by Zabrimus

    Das Generic Image von CoreELEC muss vor dem Boot (nach dem Flash) noch bearbeitet werden.

    Es musste der richtige Device Tree kopiert werden.


    Eine Anleitung findet sich hier:

    CoreELEC DTB


    Und eine Liste der möglichen DTB ist dann hier zu finden:

    DTB Liste


    Wenn du direkt ein passendes Image von CoreELEC flasht, dann ist der richtige Devicetree schon an der richtigen Stelle und man muss nichts mehr machen. Aber bei dem Generic Image ist noch etwas Handarbeit notwendig.

    Ich meine ich hätte für den TANIX TX3 diesen DTB verwendet:

    S905X3 sm1_s905x3_4g_1gbit

    Die syscall_32.tbl finde ich auf dem Server nur noch in den alten Treiber Sourcen, die nur noch als Backup vorhanden sind. Alleine die Notwendigkeit, make oldconfig/prepare auszuführen deutet darauf hin, daß mit der Installation etwas nicht stimmt.

    Passen die Kernel Header Sources/Includes überhaupt zum laufenden Kernel? 5.15.0-47-generic sieht aus wie Ubuntu 22.04.

    Ich habe endlich den Build für x86_64 hinzugefügt. In den Releases gibt es aktuell nur das Update-tar, aber im nächsten Release sollte auch das x84_64 Image vorhanden sein.


    Diverse Versuche sind bisher nicht befriedigend/oder überhaupt gelöst und ich weiß auch nicht, wann ich die Energie wieder aufbringen kann:

    - webkit (Browser) mit directfb als backend

    - x86_64 ohne X (hängt am Ausgabedevice)


    Mal abgesehen von Updates der Pakete (sofern sie mir auffallen), scheint alles Feature-Complete zu sein.

    I can try to make a software decoder with OpenGL, the question is how really someone needs it.

    I fear this use case is not really a comon one and i don't know if it's really worth the effort. For development purposes it would be nice to have easy access to some isolated (easy to install, with snapshots) system with an output device. Exactly this use case is the reason why i started to try to get VDR running in KVM.

    Server side VDRs don't need an output device.


    I've installed MXLinux (xfce and KDE) into KVM and was impressed that both virtio and qxl directly works without any configuration or change.

    No openGL either?

    Opengl is available, but the GPU is a virtual one: virgl, virtio_gpu or qxl. The softhddevice (and also all others) tries to use vaapi or vdpau or cuvid which is not available at all for for virtual gpu.

    Your softhddevice e.g. iterates over all possible interfaces and decides then to use the noop driver.


    The softhddevice-drm plugin e.g. fails while trying to identify the planes. The virtual gpu has 2 planes (primary and cursor) and no dedicated overlay plane. And also the pixel format of the planes are not recognized.


    I checked xine-lib and it could be a possible solution, because in VirtualBox i was able to start VDR and got some output (but very slow). But one major issue still exists for my tests: Kodi doesn't start.

    I wants only a 'local machine' which is able to start LibreELEC/VDR in KVM/Qemu but working on two different problems in parallel (VDR and Kodi) is not really funny and i'm not sure if a solution is available at all.


    I'm unsure if i shall interrupt my investigations or if a dedicated additional graphic card is the better solution or if a reanimation of existing old hardware is better or no tests at all.

    Hallo,


    ich habe eine VM ohne Zugriff auf eine Intel/NVidia GPU. Alle Ausgabedevices, die ich probiert habe, wollen allerdings eine der beiden GPUs haben.

    Mit softhddevice (ua0lnj) habe ich zumindest Sound, aber eben auch keine Ausgabe. Worauf der Log-Eintrag

    video/noop: noop driver running on display ':0.0'

    auch eindeutig hinweist. Das OSD ist mit dem Control Plugin gut erreichbar.

    Meine Frage ist:

    Kennt jemand ein Ausgabeplugin, daß nicht auf eine der GPUs angewiesen ist? Oder gibt es eine - mir bisher unbekannte Konfiguration, so daß die Ausgabe funktioniert ohne das bestimmte Hardware vorausgesetzt wird?

    Es muss nicht schnell oder flüssig sein, aber zumindest irgendetwas sehen würde gerne.

    Ankündigung:

    Das alte Repository Zabrimus/CoreELEC existiert zwar noch, wird aber nicht mehr aktualisiert. In der Version gab es viele Dinge, die mich gestört haben. Als ich dann das LibreELEC Image für AMGLX kompilieren wollte, stellte ich zu meinem Vergnügen fest, das das nix wird.


    Jetzt gibt es ein neues Repository: Zabrimus/VDRSternELEC in dem grundlegende Änderungen stattgefunden haben. CoreELEC und LibreELEC werden als git submodule eingebunden, es gibt keine Branches mehr, die Build Konfiguration ist in Config-Dateien ausgelagert und hat wesentlich mehr Optionen.

    Wie man eine eigene Build-Konfiguration (LibreELEC, CoreELEC, Project, Device, Arch,...) erstellen kann steht auf der Github Seite. Es gibt natürlich schon Beispiele unter config/distro.


    Ein paar Ideen habe ich von durchflieger aus seinem Repository übernommen, rell hat ein paar sehr gute Tips beigetragen und auch die Konfiguration/Plugins/Patches für den LibreELEC/Allwinner/H6 Build.


    Insgesamt gesehen sollten jetzt alle möglichen (oder viele) CoreELEC oder LibreELEC Builds theoretisch möglich sein, wenn die Ausgabeplugins vorhanden sind oder hinzugefügt werden.


    Einen Github Workflow (privat) habe ich schon eingerichtet (endlich), mit dem ich die Builds automatisch starten und dazu das passende Release mit ausgewählten Binaries, erstellen kann. Ein erstes Release gibt es schon. Ich plane noch einen Cron-Job einzurichten, der dann (1x die Woche?) den Build automatisch startet.


    Achja. Plugin Aktualisierungen fanden statt und permashift ist hinzugekommen. Wobei permashift nicht im Release vorhanden ist.

    Lt. git history sollte es damit funktionieren. Kann es sein, dass das Update nicht ganz sauber war und das gegen tntnet 3.0 gebaute live mit alten libs laufen soll oder anders herum?


    tntnet war nur spontane Vermutung von mir, weil es die offensichtliche Änderung zu dem 19er Branch war. Die Fehlermeldung oben ist an der Stelle etwas dürftig und lässt keine Analyse zu:

    i) das Plugin live crashed den vdr


    Aber man sich ja die Libs anschauen, mit denen live verlinkt wurde: ldd /usr/local/lib/vdr/libvdr-live.so.2.6.1

    Wobei ich hier auf einer Box als Ergebnis dies erhalte /usr/lib/libtntnet.so.12. Welche Version von tntnet ist das denn?


    Vielleicht kann mal jemand den letzen 20er Build im Github Repository prüfen. Da wird tatsächlich alles neu frisch gebaut. Oder vor dem Bauen, das Verzeichnis build.CoreELEC-Amlogic-ng.arm-20-image-20-VDR löschen. Wobei der Rebuild wieder lange dauern kann.


    Der 20er Branch ist in Wallung, sprich, es gibt immer sehr umfangreiche Änderungen. Ich weiß nicht, was live tatsächlich wo und wie verwendet und ob die Änderungen im Branch Auswirkungen haben könnten.

    Der kodi fix sollte mit dem aktuellen CoreELEC jetzt überflüssig sein.

    tntnet.org ist auch wieder online - das würde ich eh nicht auf eine andere Quelle abändern, sonst holst du dir irgendwann die besagten merge Konflikte.


    lirc und eventlircd patches werden noch benötigt.

    Ich habe gerade den upstream fetch vollzogen. Darin befinden sich auch die 64-Bit Time Fixes. Die reverse patches habe ich erstmal wieder entfernt.

    Die Änderungen an tntnet und cxxtools kommen später.


    i) das Plugin live crashed den vdr

    Hmmm. Ist denn gesichert, daß live mit tntnet 3.0 funktioniert? Ansonsten müsste ich cxxtools und tntnet in einer älteren Version nach vdr-depends übernehmen.

    ii) ir-keytables crashed (obwohl ich keine Änderung vorgenommen habe)

    Vielleicht hängt das mit den Änderungen an lirc und eventlird zusammen. Im Upstream wurde die 64Bit Unterstützung wieder rausgenommen (Amlogic-CE) bzw. etwas umgangen, weil der verwendete Kernel wohl die notwendigen ioctl nicht unterstützt.
    Das Problem könnte behoben worden sein.

    So, habe mal einen Amlogic build probiert. lirc und eventlird scheitert daran, dass der alte Kernel das nicht kann. Die Patches

    Aber das sollte im upstream CoreELEC auch schon nicht bauen...

    Für das Problem mit lirc und eventlircd habe ich deinen reverse Patch übernommen und das funktioniert jetzt endlich. Die Probleme mit cxxtools und tntnet konnte ich dank deiner Hilfe auch lösen.


    Warum der upstream CoreELEC Branch bauen kann, ist mir ein Rätsel.


    Aber die gute Nachricht ist: Der 20er Branch baut endlich wieder.


    Ich fürchte zwar, das ich irgendwann merge Konflikte bekommen werde (cxxtools und tntnet), aber die werden gelöst, wenn es soweit ist.


    Edit:

    Wenn man darüber nachdenkt... Natürlich baut das upstream CoreELEC. Mal abgesehen von lirc und eventlircd (relativ einfach zu fixen, Patche entfernen oder einen reverse Patch nutzen), haben die größten Probleme die Packages für cxxtools und tntnet. Aber die stammen aus dem addon-depends Ordner. D.h. das die Probleme beim compilieren verschiedener Addons auftauchen und nicht beim Build CoreELEC selbst.

    Es sollte jetzt wieder alles bauen. Allerdings musste ich für den 20er Branch live und restfulapi deaktivieren.


    Da habe ich einen Patch für live drin. Das Problem bei mir ist, dass tntnet-config nicht 3.0.0 sonder 2.2.1 zurückliefert, dann fehlt das typedef.

    Oh danke!!

    Den Patch habe ich einfach mal für den 20er Branch übernommen. Eine ähnliche Lösung könnte dann das Problem für restfulapi lösen. Wenn die Hitze vorbei ist, schaue ich mal nach.

    Die Sourcen von tntnet und cxxtools kann ich dir geben, wenn du willst, ich hatte sie gezogen, bevor der Server down ging.

    Auf Github (https://github.com/maekitalo/) findet man die wohl offiziellen Repositories zu tntnet und cxxtools. Allerdings muss der Build leicht umgebaut werden, damit das configure Script direkt nach dem entpacken erstellt wird.

    Ich baue auf einem selfhosted Debian Bullseye über github actions. Das ist eigentlich ziemlich cool. Der lokale build hat mit dem live patch gestern funktioniert.

    Kann die workflows mal wo veröffentlichen, wenn du magst. Derzeit liegt das in einem privaten repo...

    Das mache ich auch :) Im 19.4-Matrix-VDR Branch finden sich die Workflows. Ich habe gerade eine neue Version getagged und die Workflows getriggert. Ich will sehen, ob der Build durchläuft.


    Nur ein Hinweis: Wenn sich die Toolchain geändert hat, musst du komplett neu bauen...

    Mein lokales Repository war dermaßen strubbelig, da habe ich alles gelöscht und neu von Github geholt. Und damit ging es dann viel weiter, als vorher.


    Aktuelle Probleme sind noch:

    - cxxtools / tntnet im 20er Branch

    - live und restfulapi im 20er Branch


    Jetzt warte ich noch auf etwas kühleres Wetter. Es ist mir gerade viel zu warm und ich fange an unnötige Fehler zu machen.

    was ist der Grund, warum du die time64 patches für lirc und eventlircd wieder rausgenommen hast?

    Ich versuche noch irgendwie, den 20er Branch zu kompilieren. lirc und eventlircd liesen sich bei mir lokal mit dem Patches nicht kompilieren.

    Da es aber wohl aber offizielle Builds gibt, kann es eigentlich nur am Host liegen. Aber einer Lösung bin ich noch keinen Schritt weiter gekommen.


    Das live-Plugin schlägt fehl mit "Cross Compiler Badness", weil Includes vom Host verwendet werden. Ursache noch unbekannt. Der Kodi Build schlägt fehl. Ursache auch unbekannt.


    Mein nächster Versuch ist der Build unter Ubuntu Focal in einer sauberen Maschine. Aber da gibt es jetzt wohl ein Problem mit einem Paket bzw. den Sourcen, die nicht mehr gefunden werden (cxxtools).


    Ich habe aber auch nirgends gefunden, daß CoreELEC auf z.B. neueren Ubuntu Versionen (22.04) offiziell gebaut werden soll. Oder das eine ganz andere Distribution offiziell unterstützt wird.


    Es ist einfach zu Haare raufen. Der 20er Branch ist im Moment ein Experimentierfeld, daß ich irgendwie durchbringen will.

    Ich wollte mir die Fehlermeldungen von epg2vdr mal genauer anschauen und habe einen Debian Unstable Container erstellt - mit gcc 12.1 und glibc 2.33.

    Und was soll ich sagen? Es läuft einfach durch. Keine Fehlermeldungen...


    Also müssen irgendwelche globalen CFlags oder Compiler Direktiven für die Fehlermeldungen verantwortlich sein. Oder es liegt am Cross-Compiler oder ... an irgendwas anderem.

    Ich bin ziemlich sicher, das Problem ist, dass für TARGET_ARCH=arm nun time_t auf 64bit gesetzt ist und jetzt die Unsauberkeiten auffallen. time_t ist jetzt nicht mehr zufällig so groß wie long int oder pointer ist...

    Der Versuch, das temp. wieder auf 32 Bit zu setzen funktionierte nicht.

    Offensichtlich wollte man nicht bis 2038 auf einen Überlauf bei time_t (long int) warten.

    aphistory baut, wenn man hier statt "long" "time_t" nimmt: https://github.com/vdr-project…r/zaphistorychannel.h#L32


    epg2vdr meckert auch time_t an, hier wirds ähnlich sein. Das Problem scheint, dass time_t im Code mit "long int" etc. vermischt wird.

    zaphistory habe ich entsprechend geändert und damit baut das Ganze.

    Das größere Problem ist epg2vdr, da Änderungen an /lib notwendig sind und da kommen wir dann in den Bereich der Mysql Datentypen und die Fehlermeldungen sind auch nicht schön. Ich fürchte, ich kann die Auswirkungen möglicher Änderungen nicht mehr einschätzen. Das ist nur ein Beispiel:

    Ich habe einen Downgrade des GCC auf 11.3.0 versucht - allerdings ohne Erfolg. Die glibc ist auf einem Stand der mal funktioniert hat.


    Bisher betrifft es die beiden Plugins epg2vdr und scraper2vdr. Nehme ich beide aus dem Build, fängt aber das Packet lirc mit Installationsproblemen an. Ich werde mal alles wegwerfen und ganz neu bauen lassen müssen. Es könnte sein, daß durch die vielen Up-/Down-/Upgrades da irgendwas durcheinander gekommen ist.


    So gerade mit ich mit dem 20er Branch sehr unzufrieden..