Beiträge von Zabrimus

    Nach dem ersten reboot hatte ich dann etwas Probleme, als ich vom VDR zu KODI gewechselt bin, da war dann KODI + VDR gleichzeitig aktiv.

    Hast du das Problem lösen können? Mir will nichts einfallen, was das verursachen könnte.

    Ist das so richtig, oder kann das weg?

    Eieiei. Nochwas zum checken. Das install.sh -C rufe ich nur noch auf, wenn neue Plugins dazukommen. Also im Moment eher sehr selten. Ist also eher etwas schwach getestet.

    Für h264 unterstütze ich den AMD direkt, hevc kann ich auch einbinden, brauche nur jemanden zum Testen, da meiner nur h264 unterstützt.

    Wenn ich mir die CPU-Last so anschaue und auch die Geschwindigkeit, dann gehe ich schon davon aus, das beides per GPU encodiert wird.


    Aktuell sieht es so aus:

    mp2 -> h264: 16-facher Speed bei 110% CPU, Aufnahme (151 min) schrumpft von 6,4 GB auf 1,9 GB.

    h264 -> hevc: 8-fach Speed bei 12% CPU, Aufnahme (71 min) schrumpft von 2,8 GB auf 812 MB.


    Der Aufruf sieht in beiden Fällen so aus:

    vt -h264_HD hevc -hwaccel vaapi

    Bei dem Encoding mit libx264 springt zum Vergleich die CPU-Last auf über 800% und der Speed sinkt leicht. Das Software-Encoding für hevc habe ich gar nicht erst probiert.


    Edit:

    Aufruf hinzugefügt

    br steht für Bitrate, ich makiere nur Dateien, deren Bitrate größer ist, -confr ist eine Kombination von --confr und -min_br

    Bitrate. Ja, da hätte ich drauf kommen können :wand Danke.

    Also würde es reichen, wenn ich nur -confr verwende, wobei ich erst einmal mal schauen muss, welche br ( ;) ) die Aufnahmen so üblicherweise haben.

    Hi,,


    ich habe da eine (oder viele) Verständnisfragen. In einem neuen Container habe ich alles mögliche installiert und habe mit dem Script gespielt. Der Ryzen 5600G kann h264/hevc per vaapi konvertieren. Klappt auch ziemlich gut und schnell.


    Bisher bekomme ich immer den Fehler, daß die index-Datei nicht gefunden wird. Ich nehme an, dazu braucht man auch noch den VDR. Muss der immer laufen oder wird der bei Bedarf gestartet?


    Der Parameter -h264_HD ist perfekt, weil bei Bedarf mpeg2 -> h264 und h264 -> hevc gewandelt wird. Super :)

    Aber die anderen neuen Parameter verstehe ich nicht:

    Code
     --confr            # mark recursiv gt min_br 
     -confr <min_br>    # mark recursiv gt min_br 
     -min_br <min_br>

    Es werden nur Aufzeichnungen markiert, die noch nicht mit meinem Script transkodiert wurden.

    Wenn ich das richtig verstehe, dann wird das Videoverzeichnis durchsucht und in allen neuen Aufnahmen die vt.conf angelegt, oder liege ich da komplett falsch?

    Wie hängt das mit den neuen Parametern zusammen? Was ist denn mit br gemeint?

    was gebe ich denn jetzt am besten für einen Befehl ein, damit erstmal nur das Paket aktualisiert wird?

    Ziel wäre, dass beim anschließenden Aufruf des build-Befehls nicht alles, was schon kompiliert ist, nochmal neu gebaut wird

    Du kannst explizit nur ein Paket bauen. Dazu musst du an dein build-Kommando nur -package <name> anhängen.

    Ansonsten wird immer nur das gebaut, was sich tatsächlich geändert hat. Durch die anderen Pakete rauscht der Build so durch.


    Mit -package <name> erhälst du allerdings kein Release tar oder ähnliches. Das wird nur beim kompletten Build gebaut.

    Jetzt kommt beim build des softhdodroid-Plugins:

    Ürgs. Die haben mich bei CE so durcheinander gebracht mit den GLES3 Headern.... Erst bauen sie das kopieren der Header ein, ich nehme meine Patches raus, dann machen die einen Revert, ich nehme meine Patches wieder rein, bekomme dann aber ein Reject. Also denke ich, der Patch wird nicht gebraucht. Aber dem ist natürlich nicht so, jedenfalls nicht überall.


    Ich bin nochmal das Repository von CE durchgegangen und jetzt sollte es hoffentlich passen.

    Welchen Wert würdest du denn wählen, wenn es einstellbar wäre?

    Dazu habe ich gar keine Meinung. Ich habe nur den (synthetischen?) Test mit 15/45 Sekunden gesehen und das bedeutet ein recompile und in dem Zuge kam bei mir die Frage auf.

    Vielleicht ist 15 sogar richtig gut und sinnvoll.

    Dann müsste dieses Script jetzt über commands.conf aufgerufen werden? Oder wie ist der Zusammenhang?

    In der commands.conf steht nur

    Code
    Start Kodi       : echo "START_PRG=kodi" > /storage/.cache/switch_kodi_vdr

    Die ganzen systemd Units und die Zusammenhänge habe ich - meine ich - in diesem Thread schon ausführlich dargelegt.

    Auf jeden Fall wird am Ende das Script /usr/local/bin/switch_kodi_vdr.sh aufgerufen und beim Wechsel von VDR auf KODI ist der Teil relevant.

    Code
    elif [ "${START_PRG}" = "kodi" ]; then
      if [ ! -z ${SWITCH_VDR_SCRIPT} ]; then
        eval ${SWITCH_VDR_SCRIPT} detach
      else
        systemctl stop vdropt
      fi
      systemctl start kodi

    Hier kommt das SWITCH_VDR_SCRIPT ins Rennen. Das wird mit dem Parameter "detach" aufgerufen.

    Und in diesem Script ist nun der Teil relevant

    Code
    elif [ "$1" = "detach" ]; then
        /usr/local/bin/svdrpsend PLUG softhdodroid DETA
        /usr/local/bin/svdrpsend REMO off
        /usr/local/bin/svdrpsend PLUG cecremote DISC
        echo rm pip0 > /sys/class/vfm/map
    fi

    Also wird softhdodroid detached, cecremote abgeschaltet, FB für VDR deaktiviert. Aber VDR selbst sollte weiterlaufen.

    habe ich auch ausgeführt. Erkenne aber keine Veränderung von /storage/.config/system.d/vdropt.service?

    Es kann sein, das dies nur ein Migrationspfad einer alten Version der Unit war. So ganz genau kann ich das nicht mehr nachvollziehen.

    Anbei der aktuelle Patch.

    Gleiche Funktion, aber jetzt in timers (was Speicher spart), und nochmal von Klaus überarbeitet.

    Besteht die Möglichkeit den Wert in das Setup zu verlagern? Als Konstante im Code ist das doch eher etwas unflexibel.

    ich habe nochmal ein reboot gemacht und jetzt passt's ;)


    Die Startzeit bis VDR ist jetzt bei ca. 11 Sek

    So besser? Jetzt muss man nur ein wenig warten, bevor man versucht eine Seite aufzurufen. Also direkt nach dem Reboot das web-Plugin starten könnte vielleicht nicht klappen. VDR ist schneller, als der Browser/Docker.


    Eine Merkwürdigkeit sehe ich noch; es scheinen zwei Docker gestartet zu werden:

    Wo kommen denn die beiden Docker Services her? Schon seltsam. Tatsächlich habe ich auch beide mir und direkt einen davon gelöscht.

    Code
    ~/.config/system.d/docker.service
    ~/.config/system.d/service.system.docker.service

    Gelöscht habe ich docker.service, weil der nicht starten konnte.

    ich hab seit ein paar Monaten VDRSternElec mit HbbTV im Einsatz und bin sehr zufrieden.

    Eine Kleinigkeit stört mich noch. Der Start des Systems dauert damit sehr lange.

    Ich habe an der systemd unit für den cefbrowser etwas geschraubt. Der Start des Systems sollte jetzt schneller gehen.


    Die einfachste Variante die neue unit zu testen, ist es, die Bestandsunit /storage/.config/system.d/cefbrowser.service mit dem Attachment auszutauschen. Vorher vielleicht noch ein Backup machen ;)


    cefbrowser.service.txt

    Nicht pvrusb2 und hdpvr verwechseln!

    Oje. Da hatte ich wohl das Falsche im Kopf. Ich habe CONFIG_VIDEO_HDPVR=m gesetzt und CONFIG_VIDEO_PVRUSB2_DVB deaktiviert.


    Aktuelle Änderungen:

    - Das komplette Release mit allen Images wird nur noch im ersten Build eines Monats erstellt. Ich überlege noch, ob es sinnvoll ist, das Intervall auf 6-8 Wochen zu erhöhen.

    - Alle anderen Releases bestehen nur noch aus den Release tar, mit denen ein Update gemacht werden kann (entweder von einem älteren VDR*ELEC Image oder von den offiziellen Images von CE/LE).

    - Das addon dvb-latest wird für CE (für LE gibt das Addon gar nicht) auch gebaut und sollte im Release verfügbar sein.


    Wenn alles gut gegangen ist und mir kein Fehler durchgerutscht ist, dann sollte das Release morgen noch vollständig mit allen Images und dem Addon sein. Falls nicht... Nunja. Dann muss ich da wieder ran. Die nächsten Releases in diesem Monat haben dann nur noch die Release tar + das Addon.

    bist Du da weitergekommen? Ich habe ./update.sh -a ausgeführt und versucht, das addon neu zu bauen. Ich kriege hier ebenfalls immer wieder

    Ja. Das war einfach nur Unachtsamkeit. Ich habe den Patch immer wieder für CE-19 erzeugen lassen, aber CE-20 bauen. Das ist natürlich Quatsch. Und bei der Meldung muss man das Log genau checken. Es kann sein, daß das Addon gebaut wird und die Meldung später dann trotzdem kommt.

    Ich habe ./update.sh -a ausgeführt

    Das aktualisiert nur die Package-Dateien in CoreELEC/LibreELEC, die nicht in den offiziellen Quellen sind (z.B. die Plugins) und hat mit den Addons nichts zu tun.

    Es wäre besser, wenn Du das rausnimmst und den pvrusb2-Treiber ohne DVB-Unterstützung baust.

    Du wolltest wahrscheinlich einfach nur ein git pull --all machen, oder?


    Es wäre besser, wenn Du das rausnimmst und den pvrusb2-Treiber ohne DVB-Unterstützung baust.

    Den Treiber habe ich durch einen Hack entfernt. Später werde ich das besser machen...

    Das ist mir klar. Aber warum wird er weder nach einem git pull noch über den update-Befehl noch während des build-Prozesses heruntergeladen?

    Das verstehe ich nicht. Das Addon-Build patcht das package.mk für das Addon selbst und während des Builds werden die Original-Sourcen herunterladen, extrahiert. Im package.mk steht dann, daß die .config für den media-build noch gepatchet werden muss.

    Also geht es einmal quer durch den Urwald um den eigentlichen Patch zu machen.


    Code
    CONFIG_VIDEO_PVRUSB2_DVB=y

    Hmm. Damit werden keine Module gebaut, sondern der Treiber landet direkt im Kernel. Ich habe das mal geändert zu

    Code
    CONFIG_VIDEO_PVRUSB2_DVB=m

    Und damit erhalte ich im zip-File des Addons

    Code
    VDRSternELEC/CoreELEC/target/addons/Amlogic-ng/20.4/arm/driver.dvb.dvb-latest/driver.dvb.dvb-latest$ find . -name "*hdp*"
    ./kernel-overlay/lib/modules/4.9.269/updates/driver.dvb.dvb-latest/hdpvr.ko


    Ansonsten bin ich dabei den Github-Workflow zu ändern, daß zumindest das dvb-latest mit gebaut und hochgeladen wird: So das Ziel. Aber das wird heute wohl nix werden, weil ich immer in irgendwelche Probleme laufe.

    Wie man im Plot schön sehen kann, passiert nach dem Start von sys-devices-virtual-net-docker0.device ca. 24 Sekunden nichts mehr, dann starten cefbrowswer und docker und der VDR


    Ist das bei Dir ähnlich?

    Kann man evtl. den VDR schon ohne Browser starten? Ich hab allerdings keine Abhängigkeit in den systemd units gefunden.

    Hast Du an den systemd units zwischenzeitlich noch was geändert, was beim normalen Update nicht automatisch übernommen wird?

    Das ist bei mir ähnlich. Ich bin aber noch nicht dazu gekommen, das näher zu analysieren. Es liegt an Docker und dem Browser? Das ist zumindest ein Ansatz.

    Der build-Prozess ist für mich in weiten Teilen immer noch ein Buch mit 7 Siegeln. Kann ich ein einzelnes addon kompilieren, ohne dass dabei auch ein komplettes image gebaut wird?

    Das geht. Allerdings ist das Erzeugen der toolchain der wirklich bremsende Faktor falls nur addons compiliert werden sollen. Daran kommt man nicht vorbei.

    Code
    ./build.sh -config CoreELEC-20-ng -addon dvb-latest --addononly

    Unter CoreELEC/target/addons (oder ähnlich) findet sich dann das installierbare addon-zip.


    In Deinem git finde ich unter releases nur images und update-files, aber keine fertig kompilierten addons. Vielleicht könntest Du zumindest für die von Dir gepatchten addons die installationsfertigen zip-Pakete auch bereitstellen?

    Ich denke schon lange darüber nach, die Files in den Releases zu reduzieren. Die ganzen Images sind z.B. nicht unbedingt notwendig, es würden die Update-tar ausreichen. Dann müsste man erst das "echte" CE/LE installieren und dann das Update machen. Meine Hoffnung ist, das die Build-/Upload Zeit stark reduziert würde.

    In dem Zusammenhang könnte ich aber das dvb-latest Addon mit bauen und hochladen lassen.


    Und dann hätte ich auch gleich noch einen Wunsch für dvb-latest: Könntest Du da bitte den Treiber hdpvr (drivers/media/usb/hdpvr) mit anknipsen? Das ist CONFIG_VIDEO_HDPVR.

    Das wollte ich mal eben machen, aber ich verstehe gerade das Build nicht. Das addon will einfach nicht neu gebaut werden weil es wohl schon angeblich irgendwo existiert und ich komme nicht dahinter woran das scheitert.