Posts by Zabrimus

    Beim cefbrowser verwende ich das neuste vorkompilierte Release vom 20.10.2023

    Ah du je. Die Releases habe ich ja komplett vergessen. Diese Version des Browsers ist stark veraltet und die Wahrscheinlichkeit ist hoch, daß Services nicht vorhanden oder geändert wurden.

    Ich habe versuchsweise die Releases neu bauen lassen, allerdings sind die Archive unvollständig. Ich denke, daß viele Änderungen bzgl. der Installation erst nach 2023 entstanden sind. Das Release werde ich gleich wieder löschen, weil es so nicht brauchbar ist und ich erst die Github Workflows ändern muss.

    Bevor ein weiterer Test sinnvoll ist, muss erst der Browser aktualisiert werden. Dazu gibt es 2 Möglichkeiten:
    - warten, bis ich die Github Workflows geändert habe, so daß es wieder passt, oder
    - den Browser selbst kompilieren.

    Es ist sinnvoll, das richtige Archiv zu laden und prüfen. Den Build habe ich wieder neu angestossen und das Release ist wieder verfügbar. Bitte teste mal die letzte Version des Browsers.

    Die Libs/Binaries sind auch nicht gestripped. Puhh.

    Von alleine passiert das auch nicht. Da muss schon jemand die Verbindung immer wieder neu aufbauen. Sieht man auch am immer wieder anderen lokalen Port.

    Einen Client lasse ich z.B. nur einmal erzeugen und mein Denkfehler dürfte wohl sein: 1 Client <-> 1 Connection, aber dies ist offensichtlich nicht der Fall. Wobei mir das immer noch nicht klar ist.

    Weitere Versuche haben ergeben, daß ich die Anzahl der Connections sehr stark reduzieren kann, wenn ich im Server set_keep_alive_max_count erhöhe. Welcher Wert üblicherweise sinnvoll ist (pro Komponente) werde werde ich wohl ausprobieren müssen.

    Ich habe mal ein Ticket geöffnet, weil ich nicht dahinter komme, was ich eigentlich falsch mache. Selbst meine Micro-Testprogramme haben dasselbe Problem. Ich hoffe, ich bekomme dazu eine Antwort.

    Hmm. Das ist works as designed. Im Übrigen mein Lieblingsgrund für die Rückgabe von Tickets ;)
    Ich bin mir aber nicht sicher, daß es so korrekt ist. Zumal ich keep-alive gesetzt habe und auch den Client zwischendurch nicht wirklich schließe. Da würde ich nicht erwarten, daß jedesmal eine neue Verbindung aufgebaut wird.

    Einen HTTP Server brauche ich zumindest im Transcoder, damit der Browser die Files lesen kann. Die Einfachheit der cpp-httplib hat mich dazu gebracht, alles darauf aufzubauen, allerdings bin ich gerade nicht so begeistert.

    Ich habe schon mit dem Gedanken gespielt, die Lib auszutauschen, aber das kostet wieder Zeit.

    Ich hätte mich da wohl etwas präziser ausdrücken sollen.

    Die von mir gelisteten Plugins sind die, bei denen ich noch Funktionalität im MainThreadHook gefunden habe. Es gibt aber viele andere Plugins, die MainThreadHook noch im Header haben, aber dazu nur einen leeren Prozedurbody ohne Funktionalität. Ich denke das wird noch aus newplugin stammen. Das entfernen ist ziemliche Fleißarbeit.

    ps: Solange niemand - außer mir - den Header so geändert hat void MainThreadHook() override; dann wird das entfernen des Aufrufs aus dem VDR die Funktionalität des Plugins nicht beeinflussen. Die obige Änderung erzeugt dann auch nur einen Compile-Fehler ;)

    Nachdem VDR 2.7.4 den MainThreadHook als deprecated markiert hat, bin ich mal alle Plugin aus VDR*ELEC durchgegangen und habe nur noch wenige Plugins gefunden, die den Hook noch aktiv verwenden:

    Code
    dbus2vdr
    epgsearch
    fritzbox
    restfulapi
    softhdodroid
    streamdev
    suspendoutput

    Insgesamt sind 88 Plugins vorhanden. Plugins, die nicht integriert sind, wurden keinem Check unterzogen.

    jojo61

    Mit CE22 bekomme ich leider weder Bild noch Ton. Ich wüsste nicht, was genau im Log verdächtig ist. Aber vielleicht fällt dir ja etwas auf. Ob die letzten Zeilen mit dem IRQRatio überhaupt etwas mit dem Problem zu tun haben?

    Display Spoiler

    Das Ganze ist reproduzierbar mit jeder Version deines Repos nach dem 17.2.

    Ich muss mir erstmal ein Backup machen und dann das Log checken. Um den Zeitraum gab es wohl Änderungen und Probleme, die scheinbar nicht in einem Bootloop enden, sondern wohl eher die GUI betreffen. Siehe hier.

    Nach dem Update startet Kodi auch nicht:
    /usr/lib/kodi/kodi.bin: error while loading shared libraries: libFLAC.so.12

    Folgende Pakete habe ich gelöscht, neu gebaut und installiert:

    Code
    ./clean-package.sh kodi
    ./clean-package.sh flac
    ./clean-package.sh pulseaudio
    ./clean-package.sh alsa

    Damit startet Kodi wieder. Allerdings habe ich immer noch kein Bild oder OSD für den VDR, obwohl dieser läuft und auch per svdrp erreichbar ist. Da bin ich aber auch überfragt.

    Wie auch immer, es muss hiermit zu tun haben

    Ich denke nicht, daß wir das Thema hier weiter vertiefen sollten. Aber ich habe die Abhängigkeit und das Plugin gelöscht und auch die Files aus den sources gelöscht, so daß sie neu heruntergeladen werden mussten.
    Und der Build - auch von CE 21 - lief einfach durch.

    CoreELEC selbst hat auch VDR, das Plugin und die Abhängigkeiten. Das ist auch der Grund, warum die Pakete alle mit "_" anfangen um keine Konflikte und unerwünschte Abhängigkeiten mit den CE Addons zu bekommen.

    MIttels tools/viewplan kann man sich den Build Plan und die Abhängigkeiten anschauen und ich kann da nichts seltsames sehen.

    Ich habe festgestellt, dass die vdropt.service bei jedem Upgrade überschrieben wird und ich mein vtuner-ng.service wieder eintragen muss. Vielleicht übersehe ich auch was, aber da wäre noch Nachbesserungspotential ;)

    Ja, das würde ich auch so sehen. Aber wer überschreibt die Files? vdrsternupgrade.sh scheint unverdächtig zu sein. Hast du das install.sh -i aufgerufen? Da gibt es tatsächlich Verbesserungspotential:

    Code
      cp -a /usr/local/system.d/* /storage/.config/system.d
      systemctl daemon-reload

    Es kommt darauf an. Ich will jetzt nicht die Dosen wieder aufschrauben, weil alles endlich drin ist.
    Es waren schon ein paar Wagos, die drin sind. Zumal bei 2 Schaltern auch L/N nach unten durchgeschliffen werden müssen. Da hilft nur malen um das endgültige Ergebnis zu ermitteln :)

    Litzen sind einfacher zu verlegen/zu verstauen, aber der Shelly hat Schraubklemmen und da wird eine kleine Endhülse notwendig sein. Der Wago 221 ist auch etwas größer als der 2273. Das ist alles eine Abwägung oder ein Test, was jetzt tatsächlich passt. Das ist auf jeden Fall Fummelarbeit.

    Ich hatte auf einmal Bedenken mit dem Multischwitch. Die Taster permanent drücken um rauf-/runterzufahren wäre ein Komfortverlust. Aber im Video funktioniert es mit dem Shelly so, wie ich es gewohnt bin. Drücken und weglaufen oder auch zwischendurch stoppen können für Zwischenstufen.