Beiträge von Zabrimus

Zitat von jojo61

So alles nun im Git. Zabrimus du kannst den Testpatch wieder rausnehmen.

Erledigt.

Zu dem switch-Script bin ich mir jetzt nicht sicher, welche Lösung bevorzugt wird bzw. allgemein und in jeder Situation funktioniert:

alsactl store/restore (mit oder ohne sleep vorher) oder das amixer set 'HDMITX Audio Source Select' Spdif

Zitat von jojo61

Und ich baue dann gleich noch mit ein den HDMITX Select auf spdif zu setzen.

Oder wird damit die Änderung im switch-script obsolet? Und es funktioniert alles ohne Änderung?

Zitat von jojo61

dein Änderung im Switchscript ist nicht vollständig

eieiei.. Ich weiß schon gar nicht mehr, wann und warum die Parameter beim ATTA reingekommen sind. Aber ich werde auf ein reines ATTA schwenken, ohne -p/-a.

Zitat von Dr. Seltsam

kannst Du rekonstruieren, woher das kommt? Man findet diese Empfehlung oftmals im Netz, aber was sie konkret bewirkt, bleibt geheimnisvoll.

Ein commit in einem anderen Projekt verweist auf einen commit für BBC TV

Ich habe gar keine Idee dazu. Aber BBC DVB-T ist hierzulande auch eher selten, oder? Ob das noch oder jemals gebraucht wurde, müsste man mal ausprobieren.

Ich sehe grade, das im Switch-Script schon ein

echo 4 > /sys/module/amvdec_h264/parameters/dec_control

vorhanden ist und die beiden anderen Änderung irgendwas mit debug zu tun haben. Ich fürchte, die Änderung wird nicht viele Auswirkungen haben, oder?

Zitat von Paulaner

Allerdings weiß ich gar nicht in welche Datei das reinkommen soll, denn diese ganze Umschaltscripte hat ja Zabrimus entwickelt.

Da müsste evtl. er mal helfen, dann wüerde ich das testen.

Wahrscheinlich hast du in der /storage/.profile den WertSWITCH_VDR_SCRIPT=/usr/local/bin/switch_vdr_softhdodroid.sh.

Das Script kannst du irgendwohin nach /storage kopieren und ändern. Und danach das /storage/.profile auf das geänderte Script anpassen.

Aktuell steht im Script das hier

/usr/local/bin/svdrpsend PLUG softhdodroid ATTA -a hw:CARD=AMLAUGESOUND,DEV=2

Ich denke, hier muss die Änderung rein die jojo61 angesprochen hat.

Zusätzlich habe ich für das neue video.c von jojo61 einen Patch erstellt und im nächsten Release wird das drin sein. Sollte es andere Probleme geben, dann müsste ich ein neues Release ohne den Patch nachschieben.

Der Patch befindet sich hier.

Zitat von wirbel

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

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

noch einen anderen Thread eingefangen

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.

Zitat von rell

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.

Zitat von Paulaner

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.

Zitat von Paulaner

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.

Zitat von jsffm

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

Zitat von jsffm

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 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:

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

Zitat von jsffm

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?

Zitat von Dr. Seltsam

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.

Zitat von Dr. Seltsam

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.

Zitat von Dr. Seltsam

aktuell baut das image nicht mehr:

Eieiei... Der Source-Cache ist gut und sehr brauchbar, aber solche Änderungen bekomme ich damit natürlich nicht mit.

Ich habe die PKG_URL für a52dec geändert und der Testcompile ging auch durch.

Danke fürs finden.

Zitat von kls

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.

Zitat von vdr_rossi

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

In der commands.conf steht nur

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.

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

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.

Zitat von vdr_rossi

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.

Zitat von MarkusE

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.

Zitat von vdr_rossi

Bei mir startet VDR gleich nach dem boot. Sehr selten starte ich Kodi...

Warum ist vdr-live nach Kodi Start nicht mehr erreichbar? VDR soll doch im Hintergrund weiterlaufen...

Also startest du initial mit VDR, wechselt dann nach Kodi und Live ist nicht erreichbar?

Läuft VDR denn noch? Siehe hier.

Ansonsten macht der Switch nur detach was Live daraus macht?

Zitat von LotharE

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.

Zitat von LotharE

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.

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

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

Das sieht mir nach einer Klasse von Chromium selbst aus.

Z.B. dies hier

bus.cc - chromium/src/dbus - Git at Google

Das klingt nach dbus. Aber was genau da schief geht oder gehen kann.... Keine Ahnung.