Posts by Zabrimus

    Ich konnte keine Probleme damit feststellen, und würde das gerne als 1.0.2 taggen, sobald ihr kurz angetestet habt.

    Ich habe die Änderung auf der Problem-Maschine getestet und das Plugin funktioniert perfekt. Keine Änderung der CPU-Last beim Connect, keine wesentliche Änderung bei der Nutzung und auch das Beenden der Verbindung ist unauffällig.


    Super. Ein Patch weniger :) Danke.

    Soweit ich noch weiß, hat man sich durch den Konstruktor

    Code
    cCtrlKeyboard::cCtrlKeyboard(const char* name) : cKbdRemote()

    noch einen anderen Thread eingefangen

    Code
    cKbdRemote::cKbdRemote(void)
    :cRemote("KBD")
    ,cThread("KBD remote control")

    der dann in telnet action parallel lief und der für die Last verantwortlich war, die unmittelbar bei einem reinen telnet-Connect auftrat und auch nicht mehr beendet wurde.

    Ich lese hier nur am Rande mit, aber https://github.com/Zabrimus/remotetranscode beschäftigt sich doch eigentlich mit einem ähnlichen Szenario, Streams aus dem Web im TS- Container für den VDR aufzubereiten, oder?

    Im Prinzip macht der nichts anderes. Wobei ffmpeg die Hauptarbeit macht und den Transcode zu einem TS-Stream übernimmt, der dann dem Plugin zum Abspielen vorgelegt wird. Theoretisch müsste alles was ffmpeg lesen kann, auch gesendet werden können. Aus Zeitgründen bin ich aber leider noch nicht dazu gekommen, ein wenig mehr mit dem Gesamtsystem zu spielen.

    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.